From 7fd30be84b511123c09d99ad9ed40733b5f68c37 Mon Sep 17 00:00:00 2001 From: Paolo Carlini Date: Mon, 22 Sep 2008 15:17:09 +0000 Subject: [PATCH] lwg-closed.html: Update to Revision R59. 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. From-SVN: r140552 --- libstdc++-v3/ChangeLog | 7 + libstdc++-v3/doc/html/ext/lwg-active.html | 9328 +++++++++++--------- libstdc++-v3/doc/html/ext/lwg-closed.html | 1044 ++- libstdc++-v3/doc/html/ext/lwg-defects.html | 3691 +++++++- libstdc++-v3/doc/xml/manual/intro.xml | 12 +- 5 files changed, 9317 insertions(+), 4765 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index cbb6671a5687..c4a4926b1a0c 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 27e0ed263e44..94b57c0a6aa2 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,21 +1212,80 @@ 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.

      - -

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

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

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

      @@ -5058,81 +5269,13 @@ 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:

      @@ -5574,145 +5732,6 @@ 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.

      -

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

      556. is Compare a BinaryPredicate?

      Section: 25.3 [alg.sorting] Status: Open @@ -5932,66 +5951,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 @@ -6046,58 +6005,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 @@ -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.

      @@ -6636,298 +6543,6 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open -
      -

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

      -

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

      -

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

      -

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

      -

      View all issues with Ready status.

      -

      Discussion:

      -

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

      -The current C++0X draft document (n2009.pdf) adopted this -definition in chapter 26.3.1 (under the comment // 26.3.7 values) -and 26.3.7/7. -

      -

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

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

      -Note that the return type of the cabs*() functions is not a complex -type. Thus, they are equivalent to the already well established - template<class T> T abs(const complex<T>& x); -(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft -document n2009.pdf). -

      -

      -So either the return value of fabs() is specified wrongly, or fabs() -does not behave the same as C99's cabs*(). -

      - -Possible Resolutions - -

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

      -

      -If the intention was to provide a /complex/ valued function that -calculates the magnitude of its argument, this should be -explicitly specified. In TR1, the categorization under "C -compatibility" is definitely wrong, since C99 does not provide -such a complex valued function. -

      -

      -Also, it remains questionable if such a complex valued function -is really needed, since complex<T> supports construction and -assignment from real valued arguments. There is no difference -in observable behaviour between -

      -
        complex<double> x, y;
-  y = fabs(x);
-  complex<double> z(fabs(x));
-
      -

      -and -

      -
        complex<double> x, y;
-  y = abs(x);
-  complex<double> z(abs(x));
-
      -

      -If on the other hand the intention was to provide the intended -functionality of C99, fabs() should be either declared deprecated -or (for C++0X) removed from the standard, since the functionality -is already provided by the corresponding overloads of abs(). -

      - -

      [ -Bellevue: -]

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

      Proposed resolution:

      - -

      -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: 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 @@ -7077,61 +6692,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 @@ -7239,63 +6799,6 @@ 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

      -

      View all issues with Ready status.

      -

      Discussion:

      -

      -I would respectfully request an issue be opened with the intention to -clarify the wording for size() == 0 for cshift. -

      - - -

      Proposed resolution:

      -

      -Change 26.5.2.7 [valarray.members], paragraph 10: -

      - -
      - -
      valarray<T> cshift(int n) const;
-
      - -
      -

      -This function returns an object of class valarray<T>, of -length size(), each of whose elements I is -(*this)[(I + n ) % size()]. Thus, if element zero is taken as -the leftmost element, a positive value of n shifts the elements -circularly left n places. that is a circular shift of *this. If -element zero is taken as the leftmost element, a non-negative value of -n shifts the elements circularly left n places and a -negative value of n shifts the elements circularly right --n places. -

      -
      -
      - - - -

      Rationale:

      -

      -We do not believe that there is any real ambiguity about what happens -when size() == 0, but we do believe that spelling this out as a C++ -expression causes more trouble that it solves. The expression is -certainly wrong when n < 0, since the sign of % with negative arguments -is implementation defined. -

      - - -

      [ -Kona (2007) Changed proposed wording, added rationale and set to Review. -]

      - - - - -

      629. complex insertion and locale dependence

      Section: 26.3.6 [complex.ops] Status: Ready @@ -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,98 +7334,54 @@ 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. +X [func.wrap.func.undef]

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

      -

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

      -
      -
      +
      template<class Function2> bool void operator==(const function<Function2>&);
+template<class Function2> bool void operator!=(const function<Function2>&);
+
      -

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

      @@ -8258,539 +7787,13 @@ Kona (2007): Robert volunteers to propose wording. -
      -

      672. Swappable requirements need updating

      -

      Section: 20.1.1 [utility.arg.requirements] Status: Ready - Submitter: Howard Hinnant Date: 2007-05-04

      -

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

      -

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

      -

      View all issues with Ready status.

      -

      Discussion:

      -

      -The current Swappable is: -

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

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

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

      -With the passage of rvalue reference into the language, Swappable needs to be updated to -require only MoveConstructible and MoveAssignable. This is a minimum. -

      - -

      -Additionally we may want to support proxy references such that the following code is acceptable: -

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

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

      - - - -

      Proposed resolution:

      - -

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

      - -
      - -

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

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

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

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

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

      - - - - - -
      -

      673. unique_ptr update

      -

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

      -

      View other active issues in [unique.ptr].

      -

      View all other issues in [unique.ptr].

      -

      View all issues with Ready status.

      -

      Discussion:

      -

      -Since the publication of -N1856 -there have been a few small but significant advances which should be included into -unique_ptr. There exists a -example implmenation -for all of these changes. -

      - -
        - -
      • -

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

        - -

        -This resolution also supports instantiations such as unique_ptr<void, free_deleter> -which could be very useful to the client. -

        - -
        • - -
      • -

        -Efforts have been made to better support containers and smart pointers in shared -memory contexts. One of the key hurdles in such support is not assuming that a -pointer type is actually a T*. This can easily be accomplished -for unique_ptr by having the deleter define the pointer type: -D::pointer. Furthermore this type can easily be defaulted to -T* should the deleter D choose not to define a pointer -type (example implementation -here). -This change has no run time overhead. It has no interface overhead on -authors of custom delter types. It simply allows (but not requires) -authors of custom deleter types to define a smart pointer for the -storage type of unique_ptr if they find such functionality -useful. std::default_delete is an example of a deleter which -defaults pointer to T* by simply ignoring this issue -and not including a pointer typedef. -

        -
        • - -
      • -

        -When the deleter type is a function pointer then it is unsafe to construct -a unique_ptr without specifying the function pointer in the constructor. -This case is easy to check for with a static_assert assuring that the -deleter is not a pointer type in those constructors which do not accept deleters. -

        - -
        unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
-
        - -
        • - -
      - -

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

      - - -

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

      - - -
      -
      void legacy_code(void*, std::size_t);
-
-void foo(std::size_t N)
-{
-    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
-    legacy_code(ptr.get(), N);
-}   // unique_ptr used for exception safety purposes
-
      -
      - -

      -I.e. unique_ptr<void> is a useful tool that we don't want -to disable with concepts. The only part of unique_ptr<void> we -want to disable (with concepts or by other means) are the two member functions: -

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

      Proposed resolution:

      - -

      [ -I am grateful for the generous aid of Peter Dimov and Ion Gaztańaga in helping formulate and review -the proposed resolutions below. -]

      - - -
        -
      • - -

        -Change 20.6.11.2 [unique.ptr.single]: -

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

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

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

        -Change 20.6.11.2 [unique.ptr.single]: -

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

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

        - -

        -Change 20.6.11.2.1 [unique.ptr.single.ctor]: -

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

        --23- Requires: If D is not a reference type, -construction of the deleter D from an rvalue of type E -must shall be well formed and not throw an exception. If D is a -reference type, then E must shall be the same type as D -(diagnostic required). U* unique_ptr<U,E>::pointer -must shall be implicitly convertible to T* -pointer. -

        - -

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

        - -

        -Change 20.6.11.2.3 [unique.ptr.single.asgn]: -

        - -
        -

        --8- Requires: Assignment of the deleter D from an rvalue -D must shall not throw an exception. U* -unique_ptr<U,E>::pointer must shall be implicitly -convertible to T* pointer. -

        -
        - -

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

        - -
        -
        T* pointer operator->() const;
        -... -
        T* pointer get() const;
        -
        - -

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

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

        -Change 20.6.11.3 [unique.ptr.runtime]: -

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

        -Change 20.6.11.3.1 [unique.ptr.runtime.ctor]: -

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

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

        -
        - -

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

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

        --1- Requires: Does not accept pointer types which are convertible -to T* pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

        -
        - -
        • - -
      • - -

        -Change 20.6.11.2.1 [unique.ptr.single.ctor]: -

        - -
        -
        unique_ptr();
        -
        -

        -Requires: D must shall be default constructible, and that -construction must shall not throw an exception. D must shall not be a -reference type or pointer type (diagnostic required). -

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

        -Requires: The expression D()(p) must shall be well formed. -The default constructor of D must shall not throw an exception. -D must shall not be a reference type or pointer type (diagnostic -required). -

        -
        -
        - -

        -Change 20.6.11.2.1 [unique.ptr.single.ctor]: -

        - -
        -
        unique_ptr();
        -
        -

        -Requires: D must shall be default constructible, and that -construction must shall not throw an exception. D must shall not be a -reference type or pointer type (diagnostic required). -

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

        -Requires: The expression D()(p) must shall be well formed. -The default constructor of D must shall not throw an exception. -D must shall not be a reference type or pointer type (diagnostic -required). -

        -
        -
        - -
        • - -
      - - - - - -

      675. Move assignment of containers

      -

      Section: 23.1 [container.requirements] Status: Open +

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

      +

      View all issues with Review status.

      Discussion:

      James Hopkin pointed out to me that if vector<T> move assignment is O(1) @@ -8837,27 +7840,43 @@ Change 23.1 [container.requirements]:

      - + - + - +
      Table 86: Container requirementsTable 89: Container requirements
      expressionreturn typeoperational semantics assertion/note pre/post-conditioncomplexity
      a = rv;X&All existing elements of a are either move assigned or destructedAll existing elements of a are either move assigned or destructed a shall be equal to the value that rv had before this construction constant linear in a.size()(Note C) linear
      + +

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

      [ -post Bellevute Howard adds: +post Bellevue Howard adds: ]

      @@ -8870,6 +7889,11 @@ the wording right. The intent of this issue and N2525 are not in conflict.

      +

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

      + + @@ -9511,118 +8535,9 @@ 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,8 +8831,54 @@ 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.
+
      
+
      
+
      
+
+
 
 
 
@@ -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,20 +9141,49 @@ 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.
+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:
@@ -10203,130 +9191,27 @@ 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...".
-
      
+Resolution: NAD editorial - up to Pete's judgment
 
      
 
+
      [
+Post Sophia Antipolis
+]
      
 
-
      Proposed resolution:
      
-
      
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
-
      
 
 
      
-
      shared_ptr(shared_ptr&& r);
-template<class Y> shared_ptr(shared_ptr<Y>&& r);
-
      
-
      
-
      
-Postconditions:  *this shall contain the old value of r. r
-shall be empty. r.get() == 0.
-
      
+Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
 
      
-
      
-
-
      
-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);
-
      
-
      
-
      
-Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()).
-
      
-
      
-
      
-
-
      
-
      template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
-
      
-
      
-
      
-Postconditions: If w is the return value,
-w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count().
-
      
-
      
-
      
-
-
      
-Alberto Ganesh Barbati has written an
-alternative proposal
-where he suggests (among other things) that the casts be respecified in terms of
-the aliasing constructor as follows:
-
      
-
-
      
-Change 20.6.12.2.10 [util.smartptr.shared.cast]:
-
      
-
-
      
-
      
--2- Returns: If r is empty, an empty
-shared_ptr<T>; otherwise, a shared_ptr<T>
-object that stores static_cast<T*>(r.get()) and shares ownership with
-r. shared_ptr<T>(r, static_cast<T*>(r.get()).
-
      
-
      
-
-
      
-
      
--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".
-
      
-
-
 
 
 
 
 
      
 
      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
@@ -10522,60 +9445,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
@@ -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?
      +

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

        @@ -10916,45 +9812,12 @@ 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:

        @@ -11614,103 +10529,6 @@ 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.

        -

        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.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 @@ -11720,7 +10538,7 @@ and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [uni

        View all issues with Open status.

        Discussion:

        -This issue was split from 672. 672 now just +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. @@ -11870,225 +10688,10 @@ 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:

        @@ -12159,81 +10762,10 @@ 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.

        @@ -12499,187 +11029,13 @@ 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.

        -

        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 +

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

        +

        View all issues with Review status.

        Discussion:

        Consider the following program: @@ -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 ]

        @@ -13061,69 +11344,12 @@ 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. -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. -

          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. -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. -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. -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. -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. +
            • +
          -
        @@ -13506,555 +11734,14 @@ 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].

        -

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

        -
          - -
        • [...]
          • - -
        • no erase(), pop_back() or pop_front() function throws an exception.
          • - -
        -
        - -

        -23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer -additional guarantees for deque/vector insert() and -erase() members. However, 23.1 [container.requirements]p10 -does not mention 23.1.3.1 [unord.req.except] that specifies exception -safety guarantees -for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1 -offers the following guaratee for -erase(): -

        - -
        -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.3.1 [unord.req.except], this section offers additional guarantees -for unordered containers, allowing erase() to throw if -predicate or hash function throws. -

        - -

        -In contrast, associative containers have no exception safety guarantees -section so no erase() function should throw, including -erase(k) that needs to use the predicate function to -perform its work. This means that the predicate of an associative -container is not allowed to throw. -

        - -

        -So: -

        - -
          -
        1. -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.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception -safety guarantees". -

        - -
        -

        -1 For associative containers, no clear() function throws an exception. -erase(k) does not throw an exception unless that exception is thrown by -the container's Pred object (if any). -

        - -

        -2 For associative containers, if an exception is thrown by any operation -from within an insert() function inserting a single element, the -insert() function has no effect. -

        - -

        -3 For associative containers, no swap function throws an exception -unless that exception is thrown by the copy constructor or copy -assignment operator of the container's Pred object (if any). -

        -
        - -

        -Change 23.1.3.1 [unord.req.except]p1: -

        - -
        -For unordered associative containers, no clear() function -throws an exception. No erase(k) -function does not throws an exception -unless that exception is thrown by the container's Hash or Pred object -(if any). -
        - -

        -Change 23.1 [container.requirements]p10 to add references to new sections: -

        - -
        -Unless otherwise specified (see [deque.modifiers], -and [vector.modifiers], [associative.req.except], -[unord.req.except]) all container types defined in this clause meet -the following additional requirements: -
        - -

        -Change 23.1 [container.requirements]p10 referring to swap: -

        - -
        -
          -
        • -no swap() function throws an exception unless that exception is thrown -by the copy constructor or assignment operator of the container's -Compare object (if any; see [associative.reqmts]). -
          • -
        -
        - - - - - - -
        -

        767. Forwarding and backward compatibility

        -

        Section: 23 [containers] Status: Open - Submitter: Sylvain Pion Date: 2007-12-28

        -

        View other active issues in [containers].

        -

        View all other issues in [containers].

        -

        View all issues with Open status.

        -

        Discussion:

        -

        -Playing with g++'s C++0X mode, I noticed that the following -code, which used to compile: -

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

        -now fails with the following error message: -

        - -
        .../include/c++/4.3.0/ext/new_allocator.h: In member -function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, -_Args&& ...) [with _Args = int, _Tp = char*]': -.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void -std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with -_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' -test.cpp:6: instantiated from here -.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid -conversion from 'int' to 'char*' -
        - -

        -As far as I know, g++ follows the current draft here. -

        -

        -Does the committee really intend to break compatibility for such cases? -

        - -

        [ -Sylvain adds: -]

        - - -
        -

        -I just noticed that std::pair has the same issue. -The following now fails with GCC's -std=c++0x mode: -

        - -
        #include <utility>
-
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
-
        - -

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

        -
        - -

        [ -Related to 756 -]

        - - -

        [ -Bellevue: -]

        - - -
        -

        -Motivation is to handle the old-style int-zero-valued NULL pointers. -Problem: this solution requires concepts in some cases, which some users -will be slow to adopt. Some discussion of alternatives involving -prohibiting variadic forms and additional library-implementation -complexity. -

        -

        -Discussion of "perfect world" solutions, the only such solution put -forward being to retroactively prohibit use of the integer zero for a -NULL pointer. This approach was deemed unacceptable given the large -bodies of pre-existing code that do use integer zero for a NULL pointer. -

        -

        -Another approach is to change the member names. Yet another approach is -to forbid the extension in absence of concepts. -

        -

        -Resolution: These issues (756, 767, 760, 763) will be subsumed into a -paper to be produced by Alan Talbot in time for review at the 2008 -meeting in France. Once this paper is produced, these issues will be -moved to NAD. -

        -
        - - - -

        Proposed resolution:

        -

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

        - -
        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        expression return type assertion/note
        pre-/post-condition        		 container
        -a.push_front(t) - -void - -a.insert(a.begin(), t)
        -Requires: T shall be CopyConstructible. -        		 -list, deque -
        -a.push_front(rv) - -void - -a.insert(a.begin(), rv)
        -Requires: T shall be MoveConstructible. -        		 -list, deque -
        -a.push_back(t) - -void - -a.insert(a.end(), t)
        -Requires: T shall be CopyConstructible. -        		 -list, deque, vector, basic_string -
        -a.push_back(rv) - -void - -a.insert(a.end(), rv)
        -Requires: T shall be MoveConstructible. -        		 -list, deque, vector, basic_string -
        -
        - -

        -Change the synopsis in 23.2.2 [deque]: -

        - -
        void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - -

        -Change 23.2.2.3 [deque.modifiers]: -

        - -
        void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - -

        -Change the synopsis in 23.2.4 [list]: -

        - -
        void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - -

        -Change 23.2.4.3 [list.modifiers]: -

        - -
        void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - -

        -Change the synopsis in 23.2.6 [vector]: -

        - -
        void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - -

        -Change 23.2.6.4 [vector.modifiers]: -

        - -
        void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
        - - - - - - - -
        -

        768. Typos in [atomics]?

        -

        Section: 29.4.3 [atomics.types.generic] Status: Ready - Submitter: Alberto Ganesh Barbati Date: 2007-12-28

        -

        View all issues with Ready status.

        -

        Discussion:

        -

        -in the latest publicly available draft, paper -N2641, -in section 29.4.3 [atomics.types.generic], the following specialization of the template -atomic<> is provided for pointers: -

        - -
        template <class T> struct atomic<T*> : atomic_address { 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-
        - -

        -First of all, there is a typo in the non-default constructor which -should take a T* rather than a T. -

        - -

        -As you can see, the specialization redefine and therefore hide a few -methods from the base class atomic_address, namely fetch_add, fetch_sub, -operator=, operator+= and operator-=. That's good, but... what happened -to the other methods, in particular these ones: -

        - -
        void store(T*, memory_order = memory_order_seq_cst) volatile;
-T* load( memory_order = memory_order_seq_cst ) volatile;
-T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
-bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
-
        - -

        -By reading paper -N2427 "C++ Atomic Types and Operations", -I see that the -definition of the specialization atomic<T*> matches the one in the -draft, but in the example implementation the methods load(), swap() -and compare_swap() are indeed present. -

        - -

        -Strangely, the example implementation does not redefine the method -store(). It's true that a T* is always convertible to void*, but not -hiding the void* signature from the base class makes the class -error-prone to say the least: it lets you assign pointers of any type to -a T*, without any hint from the compiler. -

        - -

        -Is there a true intent to remove them from the specialization or are -they just missing from the definition because of a mistake? -

        - -

        [ -Bellevue: -]

        - - -
        -

        -The proposed revisions are accepted. -

        -

        -Further discussion: why is the ctor labeled "constexpr"? Lawrence said -this permits the object to be statically initialized, and that's -important because otherwise there would be a race condition on -initialization. -

        -
        - - -

        Proposed resolution:

        -

        -Change the synopsis in 29.4.3 [atomics.types.generic]: -

        - -
        template <class T> struct atomic<T*> : atomic_address { 
-  void store(T*, memory_order = memory_order_seq_cst) volatile;
-  T* load( memory_order = memory_order_seq_cst ) volatile;
-  T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-  bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
-  bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
-
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T*); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-
        - - - - - -

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

        -

        Section: 20.5.15.2 [func.wrap.func] Status: New +

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

        -

        View all issues with New status.

        +

        View all issues with Ready status.

        Discussion:

        -N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed +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- @@ -14065,7 +11752,7 @@ type".

        Proposed resolution:

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

        template<class R, class... ArgTypes>
@@ -14079,7 +11766,7 @@ template<class R, class... ArgTypes>

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

        function(unspecified-null-pointer-type nullptr_t);
@@ -14088,7 +11775,7 @@ function& operator=(unspecified-null-pointer-type nullptr_t<

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

        template <class R, class... ArgTypes>
@@ -14102,7 +11789,7 @@ template <class R, class... ArgTypes>

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

        function(unspecified-null-pointer-type nullptr_t);
@@ -14111,7 +11798,7 @@ function& operator=(unspecified-null-pointer-type nullptr_t<

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

        template <class R, class... ArgTypes>
@@ -14135,81 +11822,13 @@ 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.
        
-
        Discussion:
        
-
        
-It is expected that typical implementations of std::function will
-use dynamic memory allocations at least under given conditions,
-so it seems appropriate to change the current lvalue swappabilty of
-this class to rvalue swappability.
-
        
-
-
-
        Proposed resolution:
        
-
        
-In 20.5 [function.objects], header <functional> synopsis, just below of
-
        
-
-
        template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
-
        
-
-
        
-In 20.5.15.2 [func.wrap.func] class function definition, change
-
        
-
-
        void swap(function&&);
-
        
-
-
        
-In 20.5.15.2 [func.wrap.func], just below of
-
        
-
-
        template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
-
        
-
-
        
-In 20.5.15.2.2 [func.wrap.func.mod] change
-
        
-
-
        void swap(function&& other);
-
        
-
-
        
-In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
-
        
-
-
        template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);
-
        
-
-
-
-
-
-
 
        
 
        771. Impossible throws clause in [string.conversions]
        
-
        Section: 21.4 [string.conversions] Status: Review
+
        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 Review status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 The new to_string and to_wstring functions described in 21.4 [string.conversions]
@@ -14272,11 +11891,11 @@ string to_string(long double val);
 
 
        
 
        772.  Impossible return clause in [string.conversions]
        
-
        Section: 21.4 [string.conversions] Status: New
+
        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 New status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring
@@ -14431,199 +12050,13 @@ Wording provided in
 
 
 
-
        
-
        775. Tuple indexing should be unsigned?
        
-
        Section: 20.3.1.4 [tuple.helper] Status: Ready
- Submitter: Alisdair Meredith Date: 2008-01-16
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-The tuple element access API identifies the element in the sequence
-using signed integers, and then goes on to enforce the requirement that
-I be >= 0.  There is a much easier way to do this - declare I as
-unsigned.
-
        
-
        
-In fact the proposal is to use std::size_t, matching the type used in the tuple_size API.
-
        
-
        
-A second suggestion is that it is hard to imagine an API that deduces
-and index at compile time and returns a reference throwing an exception.
-Add a specific Throws: Nothing paragraph to each element
-access API.
-
        
-
        
-In addition to tuple, update the API applies to
-pair and array, and should be updated
-accordingly.
-
        
-
-
        
-A third observation is that the return type of the get
-functions for std::pair is pseudo-code, but it is not
-clearly marked as such.  There is actually no need for pseudo-code as
-the return type can be specified precisely with a call to
-tuple_element.  This is already done for
-std::tuple, and std::array does not have a
-problem as all elements are of type T.
-
        
-
-
-
        Proposed resolution:
        
-
        
-Update header <utility> synopsis in 20.2 [utility]
-
        
-
        // 20.2.3, tuple-like access to pair:
-template <class T> class tuple_size;
-template <intsize_t I, class T> class tuple_element;
-
-template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
-
-template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
-
        
-
        
-Update 20.2.3 [pairs] Pairs
-
        
-
        template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&);
-
        
-
        
-24 Return type: If I == 0 then P is T1, if I == 1 then P is T2, and otherwise the program is ill-formed.
-
        
-
        
-25 Returns: If I == 0 returns p.first, otherwise if I == 1 returns p.second, and otherwise the program is ill-formed.
-
        
-
        
-Throws: Nothing.
-
        
-
-
-
        
-Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below:
-
        
-
        template <intsize_t I, class T> class tuple_element; // undefined
-template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
-
-// 20.3.1.4, element access:
-template <intsize_t I, class... Types>
-  typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
-template <intsize_t I, class ... types>
-  typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
-
        
-
-
        
-Update 20.3.1.4 [tuple.helper] Tuple helper classes
-
        
-
        template <intsize_t I, class... Types>
-class tuple_element<I, tuple<Types...> > {
-public:
-  typedef TI type;
-};
        
-
        
-1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
-
        
-
        
-2 Type: TI is the type of the Ith element of Types, where indexing is zero-based.
-
        
-
        
-Update 20.3.1.5 [tuple.elem] Element access
-
        
-
        template <intsize_t I, class... types >
-typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
-
        
-1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
-
        
-2 Returns: A reference to the Ith element of t, where indexing is zero-based.
-
        
-Throws: Nothing.
-
        template <intsize_t I, class... types>
-typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
-
        
-
        
-3 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds.
-
        
-
        
-4 Returns: A const reference to the Ith element of t, where indexing is zero-based.
-
        
-
        
-Throws: Nothing.
-
        
-
-
-
        
-Update header <array> synopsis in 20.2 [utility]
-
        
-
        template <class T> class tuple_size; // forward declaration
-template <intsize_t I, class T> class tuple_element; // forward declaration
-template <class T, size_t N>
-  struct tuple_size<array<T, N> >;
-template <intsize_t I, class T, size_t N>
-  struct tuple_element<I, array<T, N> >;
-template <intsize_t I, class T, size_t N>
-  T& get(array<T, N>&);
-template <intsize_t I, class T, size_t N>
-  const T& get(const array<T, N>&);
-
        
-
-
        
-Update 23.2.1.6 [array.tuple] Tuple interface to class template array
-
        
-
        tuple_element<size_t I, array<T, N> >::type
-
        
-
        
-3 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
-
        
-
        
-4 Value: The type T.
-
        
-
        template <intsize_t I, class T, size_t N> T& get(array<T, N>& a);
-
        
-
        
-5 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
-
        
-
        
-Returns: A reference to the Ith element of a, where indexing is zero-based.
-
        
-
        
-Throws: Nothing.
-
        
-
        template <intsize_t I, class T, size_t N> const T& get(const array<T, N>& a);
-
        
-
        
-6 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
-
        
-
        
-7 Returns: A const reference to the Ith element of a, where indexing is zero-based.
-
        
-
        
-Throws: Nothing.
-
        
-
-
-
        [
-Bellevue: Note also that the phrase "The program is ill-formed if I is
-out of bounds" in the requires clauses are probably unnecessary, and
-could be removed at the editor's discretion. Also std:: qualification
-for pair is also unnecessary.
-]
        
-
-
-
-
 
        
 
        776. Undescribed assign function of std::array
        
-
        Section: 23.2.1 [array] Status: Review
+
        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 Review status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 The class template array synopsis in 23.2.1 [array]/3 declares a member
@@ -14711,136 +12144,12 @@ Set state to Review given substitution of "fill" for "assign".
 
 
 
-
        
-
        777. Atomics Library Issue
        
-
        Section: 29.4.4 [atomics.types.operations] Status: Ready
- Submitter: Lawrence Crowl Date: 2008-01-21
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-The load functions are defined as
-
        
-
-
        C atomic_load(volatile A* object);
-C atomic_load_explicit(volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) volatile;
-
        
-
-
        
-which prevents their use in const contexts.
-
        
-
-
        [
-post Bellevue Peter adds:
-]
        
-
-
-
        
-
        
-Issue 777 suggests making atomic_load operate on const objects. There is a
-subtle point here. Atomic loads do not generally write to the object, except
-potentially for the memory_order_seq_cst constraint. Depending on the
-architecture, a dummy write with the same value may be required to be issued
-by the atomic load to maintain sequential consistency. This, in turn, may
-make the following code:
-
        
-
-
        const atomic_int x{};
-
-int main()
-{
-  x.load();
-}
-
        
-
-
        
-dump core under a straightforward implementation that puts const objects in
-a read-only section.
-
        
-
        
-There are ways to sidestep the problem, but it needs to be considered.
-
        
-
        
-The tradeoff is between making the data member of the atomic types
-mutable and requiring the user to explicitly mark atomic members as
-mutable, as is already the case with mutexes.
-
        
-
        
-
-
-
-
        Proposed resolution:
        
-
        
-Add the const qualifier to *object and *this.
-
        
-
-
        C atomic_load(const volatile A* object);
-C atomic_load_explicit(const volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) const volatile;
-
        
-
-
-
-
-
-
-
        
-
        778. std::bitset does not have any constructor taking a string literal
        
-
        Section: 23.3.5.1 [bitset.cons] Status: Ready
- Submitter: Thorsten Ottosen Date: 2008-01-24
        
-
        View other active issues in [bitset.cons].
        
-
        View all other issues in [bitset.cons].
        
-
        View all issues with Ready status.
        
-
        Duplicate of: 116
        
-
        Discussion:
        
-
        
-A small issue with std::bitset: it does not have any constructor
-taking a string literal, which is clumsy and looks like an oversigt when
-we tried to enable uniform use of string and const char* in the library.
-
        
-
-
        
-Suggestion: Add
-
        
-
-
        explicit bitset( const char* str );
-
        
-
-
        
-to std::bitset.
-
        
-
-
-
        Proposed resolution:
        
-
        
-Add to synopsis in 23.3.5 [template.bitset]
-
        
-
-
        explicit bitset( const char* str );
-
        
-
-
        
-Add to synopsis in 23.3.5.1 [bitset.cons]
-
        
-
-
        explicit bitset( const char* str );
-
        
-
        
-Effects: Constructs a bitset as if bitset(string(str)).
-
        
-
        
-
-
-
-
-
-
 
        
 
        779. Resolution of #283 incomplete
        
-
        Section: 25.2.8 [alg.remove] Status: New
+
        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 New status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 The resolution of 283 did not resolve similar necessary changes for algorithm
@@ -14851,7 +12160,7 @@ which seems to be an oversight.
 
 
        Proposed resolution:
        
 
        
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
 
        
 
 
        
@@ -14860,17 +12169,6 @@ and [result,result + (last - first)) shall not overlap. The expres
 valid.
 
        
 
-
        
-or
-
        
-
-
        
-Requires: Type T is EqualityComparable (31). The ranges [first,last)
-and [result,result + (last - first)) shall not overlap.
-The result of the expression *first shall
-be writable to the output iterator.
-
        
-
 
 
 
@@ -14957,336 +12255,6 @@ other parts of <algorithm> show, just a matter of consistency]
 
 
 
-
        
-
        781. std::complex should add missing C99 functions
        
-
        Section: 26.3.7 [complex.value.ops] Status: Ready
- Submitter: Daniel Krügler Date: 2008-01-26
        
-
        View other active issues in [complex.value.ops].
        
-
        View all other issues in [complex.value.ops].
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-A comparision of the N2461 header <complex> synopsis ([complex.synopsis])
-with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
-some complex functions that are missing in C++. These are:
-
        
-
-
          
-
        1. 
-7.3.9.4: (required elements of the C99 library)
          
-The cproj functions
-
          2. 
-
        2. 
-7.26.1: (optional elements of the C99 library)
          
-
          cerf    cerfc    cexp2
-cexpm1  clog10   clog1p
-clog2   clgamma  ctgamma
-
          
-
          3. 
-
        
-
-
        
-I propose that at least the required cproj overloads are provided as equivalent
-C++ functions. This addition is easy to do in one sentence (delegation to C99
-function).
-
        
-
-
        
-Please note also that the current entry polar
-in 26.3.9 [cmplx.over]/1
-should be removed from the mentioned overload list. It does not make sense to require that a
-function already expecting scalar arguments
-should cast these arguments into corresponding
-complex<T> arguments, which are not accepted by
-this function.
-
        
-
-
-
        Proposed resolution:
        
-
        
-In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
-
        
-
-
        template<class T> complex<T> conj(const complex<T>&);
-template<class T> complex<T> proj(const complex<T>&);
-template<class T> complex<T> fabs(const complex<T>&);
-
        
-
-
        
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
-
        
-
-
        
-
        template<class T> complex<T> proj(const complex<T>& x);
-
        
-
        
-
-Effects: Behaves the same as C99 function cproj, defined in
-subclause 7.3.9.4."
-
        
-
        
-
-
        
-In 26.3.9 [cmplx.over]/1, add one further entry proj to
-the overload list.
-
        
-
-
        
-
        
-The following function templates shall have additional overloads:
-
        
-
        arg           norm 
-conj          polar proj
-imag          real
-
        
-
        
-
-
-
-
-
-
-
        
-
        782. Extended seed_seq constructor is useless
        
-
        Section: 26.4.7.1 [rand.util.seedseq] Status: Ready
- Submitter: Daniel Krügler Date: 2008-01-27
        
-
        View other active issues in [rand.util.seedseq].
        
-
        View all other issues in [rand.util.seedseq].
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-Part of the resolution of n2423, issue 8 was the proposal to
-extend the seed_seq constructor accepting an input range
-as follows (which is now part of N2461):
-
        
-
-
        template<class InputIterator,
-size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-seed_seq(InputIterator begin, InputIterator end);
-
        
-
-
        
-First, the expression iterator_traits<InputIterator>::value_type
-is invalid due to missing typename keyword, which is easy to
-fix.
-
        
-
-
        
-Second (and worse), while the language now supports default
-template arguments of function templates, this customization
-point via the second size_t template parameter is of no advantage,
-because u can never be deduced, and worse - because it is a
-constructor function template - it can also never be explicitly
-provided (14.8.1 [temp.arg.explicit]/7).
-
        
-
-
        
-The question arises, which advantages result from a compile-time
-knowledge of u versus a run time knowledge? If run time knowledge
-suffices, this parameter should be provided as normal function
-default argument [Resolution marked (A)], if compile-time knowledge
-is important, this could be done via a tagging template or more
-user-friendly via a standardized helper generator function
-(make_seed_seq), which allows this [Resolution marked (B)].
-
        
-
-
        [
-Bellevue:
-]
        
-
-
-
        
-
        
-Fermilab does not have a strong opinion. Would prefer to go with
-solution A. Bill agrees that solution A is a lot simpler and does the
-job.
-
        
-
        
-Proposed Resolution: Accept Solution A.
-
        
-
        
-
-
        
-Issue 803 claims to make this issue moot.
-
        
-
-
-
-
        Proposed resolution:
        
-
          
-
        1. 
-
          
-In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
-
          
-
-
          class seed_seq 
-{ 
-public:
-   ...
-   template<class InputIterator,
-      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-          seed_seq(InputIterator begin, InputIterator end,
-          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);
-   ...
-};
-
          
-
-
          
-and do a similar replacement in the member description between
-p.3 and p.4.
-
          
-
          2. 
-
-
        2. 
-
          
-In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
-member description between p.3 and p.4 replace:
-
          
-
-
          template<class InputIterator,
-  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-	  seed_seq(InputIterator begin, InputIterator end);
-template<class InputIterator, size_t u>
-seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
-
          
-
-
          
-In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
-class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
-after the class seed_seq definition add:
-
          
-
-
          template<size_t u, class InputIterator>
-  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-
          
-
-
          
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
-
          
-
-
          
-
          
-The first constructor behaves as if it would provide an
-integral constant expression u of type size_t of value
-numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits.
-
          
-
          
-The second constructor uses an implementation-defined mechanism
-to provide an integral constant expression u of type size_t and
-is called by the function make_seed_seq.
-
          
-
          
-
-
          
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
-
          
-
-
          
-
          template<size_t u, class InputIterator>
-   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-
          
-
          
-
          
-where u is used to construct an object s of implementation-defined type.
-
          
-
          
-Returns: seed_seq(begin, end, s);
-
          
-
          
-
          
-
-
          3. 
-
        
-
-
-
-
-
-
-
        
-
        783. thread::id reuse
        
-
        Section: 30.2.1.1 [thread.thread.id] Status: Ready
- Submitter: Hans Boehm Date: 2008-02-01
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-The current working paper 
-(N2497,
-integrated just before Bellevue) is
-not completely clear whether a given thread::id value may be reused once
-a thread has exited and has been joined or detached.  Posix allows
-thread ids (pthread_t values) to be reused in this case.  Although it is
-not completely clear whether this originally was the right decision, it
-is clearly the established practice, and we believe it was always the
-intent of the C++ threads API to follow Posix and allow this.  Howard
-Hinnant's example implementation implicitly relies on allowing reuse
-of ids, since it uses Posix thread ids directly.
-
        
-
-
        
-It is important to be clear on this point, since it the reuse of thread
-ids often requires extra care in client code, which would not be
-necessary if thread ids were unique across all time.  For example, a
-hash table indexed by thread id may have to be careful not to associate
-data values from an old thread with a new one that happens to reuse the
-id.  Simply removing the old entry after joining a thread may not be
-sufficient, if it creates a visible window between the join and removal
-during which a new thread with the same id could have been created and
-added to the table.
-
        
-
-
        [
-post Bellevue Peter adds:
-]
        
-
-
-
        
-
        
-There is a real issue with thread::id reuse, but I urge the LWG to
-reconsider fixing this by disallowing reuse, rather than explicitly allowing
-it. Dealing with thread id reuse is an incredibly painful exercise that
-would just force the world to reimplement a non-conflicting thread::id over
-and over.
-
        
-
        
-In addition, it would be nice if a thread::id could be manipulated
-atomically in a lock-free manner, as motivated by the recursive lock
-example:
-
        
-
-
        
-http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
-
        
-
        
-
-
-
-
        Proposed resolution:
        
-
        
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
-
        
-
-
        
-
        
-An object of type thread::id provides
-a unique identifier for each thread of execution
-and a single distinct value for all thread objects
-that do not represent a thread of execution ([thread.threads.class]).
-Each thread of execution has a thread::id
-that is not equal to the thread::id
-of other threads of execution
-and that is not equal to
-the thread::id of std::thread objects
-that do not represent threads of execution.
-The library may reuse the value of a thread::id of a
-terminated thread that can no longer be joined.
-
        
-
        
-
-
-
-
-
 
        
 
        785. Random Number Requirements in TR1
        
 
        Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New
@@ -15350,132 +12318,11 @@ functions appears to be an oversight.
 
 
 
-
        
-
        786. Thread library timed waits, UTC and monotonic clocks
        
-
        Section: X [datetime.system] Status: New
- Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03
        
-
        View all issues with New status.
        
-
        Discussion:
        
-
        
-The draft C++0x thread library requires that the time points of type
-system_time and returned by get_system_time() represent Coordinated
-Universal Time (UTC) (section X [datetime.system]). This can lead to
-surprising behavior when a library user performs a duration-based wait,
-such as condition_variable::timed_wait(). A complete explanation of the
-problem may be found in the
-Rationale for the Monotonic Clock
-section in POSIX, but in summary:
-
        
-
-
          
-
        • 
-Operations such as condition_variable::timed_wait() (and its POSIX
-equivalent, pthread_cond_timedwait()) are specified using absolute times
-to address the problem of spurious wakeups.
-
          • 
-
-
        • 
-The typical use of the timed wait operations is to perform a relative
-wait. This may be achieved by first calculating an absolute time as the
-sum of the current time and the desired duration. In fact, the C++0x
-thread library includes duration-based overloads of
-condition_variable::timed_wait() that behave as if by calling the
-corresponding absolute time overload with a time point value of
-get_system_time() + rel_time.
-
          • 
-
-
        • 
-A UTC clock may be affected by changes to the system time, such as
-synchronization with an external source, leap seconds, or manual changes
-to the clock.
-
          • 
-
-
        • 
-Should the clock change during a timed wait operation, the actual
-duration of the wait will not be the expected length. For example, a
-user may intend a timed wait of one second duration but, due to an
-adjustment of the system clock backwards by a minute, the wait instead
-takes 61 seconds.
-
          • 
-
        
-
-
        
-POSIX solves the problem by introducing a new monotonic clock, which is
-unaffected by changes to the system time. When a condition variable is
-initialized, the user may specify whether the monotonic clock is to be
-used. (It is worth noting that on POSIX systems it is not possible to
-use condition_variable::native_handle() to access this facility, since
-the desired clock type must be specified during construction of the
-condition variable object.)
-
        
-
-
        
-In the context of the C++0x thread library, there are added dimensions
-to the problem due to the need to support platforms other than POSIX:
-
        
-
-
          
-
        • 
-Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
-
          • 
-
-
        • 
-Some environments do not have a monotonic clock, but do have a UTC clock.
-
          • 
-
-
        • 
-The Microsoft Windows API's synchronization functions use relative
-timeouts based on an implied monotonic clock. A program that switches
-from the Windows API to the C++0x thread library will now find itself
-susceptible to clock changes.
-
          • 
-
        
-
-
        
-One possible minimal solution:
-
        
-
-
          
-
        • 
-Strike normative references to UTC and an epoch based on 1970-01-01.
-
          • 
-
-
        • 
-Make the semantics of system_time and get_system_time()
-implementation-defined (i.e standard library implementors may choose the
-appropriate underlying clock based on the capabilities of the target
-platform).
-
          • 
-
-
        • 
-Add a non-normative note encouraging use of a monotonic clock.
-
          • 
-
-
        • 
-Remove system_time::seconds_since_epoch().
-
          • 
-
-
        • 
-Change the constructor explicit system_time(time_t secs, nanoseconds ns
-= 0) to explicit system_time(nanoseconds ns).
-
          • 
-
        
-
-
-
-
        Proposed resolution:
        
-
        
-
        
-
-
-
-
-
 
        
 
        787. complexity of binary_search
        
-
        Section: 25.3.3.4 [binary.search] Status: New
+
        Section: 25.3.3.4 [binary.search] Status: Ready
  Submitter: Daniel Krügler Date: 2007-09-08
        
-
        View all issues with New status.
        
+
        View all issues with Ready status.
        
 
        Discussion:
        
 
        
 In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as
@@ -15499,6 +12346,18 @@ be brought in-line with 789. xor_combine_engine(result_type) should be explicit
-
        Section: 26.4.4.4 [rand.adapt.xor] Status: Ready
- Submitter: P.J. Plauger Date: 2008-02-09
        
-
        View all other issues in [rand.adapt.xor].
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-xor_combine_engine(result_type) should be explicit. (Obvious oversight.)
-
        
-
-
        [
-Bellevue:
-]
        
-
-
-
        
-Non-controversial. Bill is right, but Fermilab believes that this is
-easy to use badly and hard to use right, and so it should be removed
-entirely. Got into TR1 by well defined route, do we have permission to
-remove stuff? Should probably check with Jens, as it is believed he is
-the originator. Broad consensus that this is not a robust engine
-adapter.
-
        
-
-
-
        Proposed resolution:
        
-
        
-Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
-
        
-
        
-Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
-
        
-
-
-
-
-
-
        
-
        792. piecewise_constant_distribution is undefined for a range with just one endpoint
        
-
        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Ready
- Submitter: P.J. Plauger Date: 2008-02-09
        
-
        View other active issues in [rand.dist.samp.pconst].
        
-
        View all other issues in [rand.dist.samp.pconst].
        
-
        View all issues with Ready status.
        
-
        Discussion:
        
-
        
-piecewise_constant_distribution is undefined for a range with just one
-endpoint. (Probably should be the same as an empty range.)
-
        
-
-
-
        Proposed resolution:
        
-
        
-Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
-
        
-
-
        
-b) If firstB == lastB or the sequence w has the length zero,
-
        
-
-
-
-
-
 
        
 
        793. discrete_distribution missing constructor
        
 
        Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open
  Submitter: P.J. Plauger Date: 2008-02-09
        
+
        View other active issues in [rand.dist.samp.discrete].
        
 
        View all other issues in [rand.dist.samp.discrete].
        
 
        View all issues with Open status.
        
 
        Discussion:
        
@@ -15671,7 +12466,7 @@ b) If firstB == lastB or the sequence w has the length ze

        -(Makes it easier to fill a histogram with function vaues over a range.) +(Makes it easier to fill a histogram with function values over a range.)

        [ @@ -15686,8 +12481,133 @@ there. Where in each bin does one evaluate the function? In the middle. Need to revisit tomorrow. +

        [ +Sophia Antipolis: +]

        + + +
        +

        +Bill is not requesting this. +

        +

        +Marc Paterno: _Fn cannot return negative values at the points where the +function is sampled. It is sampled in the middle of each bin. _Fn cannot +return 0 everywhere it is sampled. +

        +

        +Jens: lambda expressions are rvalues +

        +

        +Add a library issue to provide an +initializer_list<double> constructor for +discrete_distribution. +

        +

        +Marc Paterno: dislikes reference for _Fn parameter. Make it pass-by-value (to use lambda), +use std::ref to wrap giant-state function objects. +

        +

        +Daniel: See random_shuffle, pass-by-rvalue-reference. +

        +

        +Daniel to draft wording. +

        +
        + +

        [ +Pre San Francisco, Daniel provided wording: +]

        + + +
        +The here proposed changes of the WP refer to the current state of +N2691. +During the Sophia Antipolis meeting two different proposals came up +regarding the functor argument type, either by value or by rvalue-reference. +For consistence with existing conventions (state-free algorithms and the +general_pdf_distribution c'tor signature) the author decided to propose a +function argument that is provided by value. If severe concerns exists that +stateful functions would be of dominant relevance, it should be possible to +replace the two occurrences of Func by Func&& in this proposal as part +of an editorial process. +
        + +

        Proposed resolution:

        +
          +
        1. +

          +In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just +before the member declaration +

          + +
          explicit discrete_distribution(const param_type& parm);
+
          + +

          +insert: +

          + + +
          template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
          +
          2. + +
        2. +

          +Between p.4 and p.5 insert a series of new paragraphs as part of the +new member description:: +

          +
          template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+
          + +

          +Complexity: Exactly nf invocations of fw. +

          +

          +Requires: +

          +
            +
          1. +fw shall be callable with one argument of type double, and shall +return values of a type convertible to double;
            2. + +
          2. If nf > 0, the relation xmin < xmax shall hold, and for all sample values +xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN, +and non-infinity;
            3. + +
          3. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
            4. + +
          + +

          +Effects: +

          +
            +
          1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and + consist of the single value w0 = 1.
            2. + +
          2. +

            Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin + +0.5 * deltax.

            +
            For each k = 0, . . . ,n-1, calculates:
+  xk = xcent + k * deltax
+  wk = fw(xk)
+
            +
            3. +
          3. +

            Constructs a discrete_distribution object with probabilities:

            +
            pk = wk/S  for k = 0, . . . , n-1.
+
            +
            4. +
          +
          +
          3. +
        @@ -15695,11 +12615,11 @@ Need to revisit tomorrow.

        794. piecewise_constant_distribution missing constructor

        -

        Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New +

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

        +

        View all issues with Open status.

        Discussion:

        piecewise_constant_distribution should have a constructor like: @@ -15711,100 +12631,149 @@ Need to revisit tomorrow.

        -(Makes it easier to fill a histogram with function vaues over a range. +(Makes it easier to fill a histogram with function values over a range. The two (reference 793) make a sensible replacement for general_pdf_distribution.)

        +

        [ +Sophia Antipolis: +]

        + + +
        +

        +Marc: uses variable width of bins and weight for each bin. This is not +giving enough flexibility to control both variables. +

        +

        +Add a library issue to provide an constructor taking an +initializer_list<double> and _Fn for piecewise_constant_distribution. +

        +

        +Daniel to draft wording. +

        +
        + +

        [ +Pre San Francisco, Daniel provided wording. +]

        + + +
        +The here proposed changes of the WP refer to the current state of +N2691. +For reasons explained in 793, the author decided to propose a function +argument that is provided by value. The issue proposes a c'tor signature, +that does not take advantage of the full flexibility of +piecewise_constant_distribution, +because it restricts on a constant bin width, but the use-case seems to +be popular enough to justify it's introduction. +
        + +

        Proposed resolution:

        - - - - -
        -

        798. Refactoring of binders lead to interface breakage

        -

        Section: D.8 [depr.lib.binders] Status: Ready - Submitter: Daniel Krügler Date: 2008-02-14

        -

        View all other issues in [depr.lib.binders].

        -

        View all issues with Ready status.

        -

        Discussion:

        +
          +

        1. -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. +In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, +just before the member declaration

          - -

          Proposed resolution:

          +
          explicit piecewise_constant_distribution(const param_type& parm);
+

          -Change D.8.1 [depr.lib.binder.1st]: +insert: +

          +
          template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+
          +
          2. + +
        2. +

          +Between p.4 and p.5 insert a new sequence of paragraphs nominated +below as [p5_1], [p5_2], +[p5_3], and [p5_4] as part of the new member description:

          -
          -
          template <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<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
 
          
-
 
          
 
          
--1- The constructor initializes fn op with x and value with y.
+[p5_1] Complexity: Exactly nf invocations of fw.
 
          
 
          
--2- operator() returns fnop(value,x).
+[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. 
+
          
 
          
-Change D.8.3 [depr.lib.binder.2nd]:
+[p5_3] Effects:
 
          
-
-
          
-
          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. 
+
            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. 
 
            
--1- The constructor initializes fn op with x and value with y.
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
 
            
+
            ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
+
             
+
            4. 
+
          
 
          
--2- operator() returns fnop(value,x).
-
          
+[p5_4] Remarks: In this context, the subintervals [bk, bk+1) are commonly
+ known as the bins of a histogram.
+ 
          
 
          
 
          
+
          3. +
        @@ -15894,7 +12863,7 @@ algorithm:

        801. tuple and pair trivial members

        -

        Section: 20.3 [tuple] Status: Open +

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

        @@ -16001,11 +12970,11 @@ 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 +

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

        +

        View all issues with Review status.

        Discussion:

        seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq @@ -16156,7 +13125,7 @@ seed_seq q(s, s+4);

    -Note: this proposal renders moot issues 782 and 800. +Note: this proposal renders moot issues 782 and 800.

    [ @@ -16168,6 +13137,35 @@ Bellevue: Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. +

    [ +Sophia Antipolis: +]

    + + +
    +

    +Marc Paterno wants portable behavior between 32bit and 64bit machines; +we've gone to significant trouble to support portability of engines and +their values. +

    +

    +Jens: the new algorithm looks perfectly portable +

    +

    +Marc Paterno to review off-line. +

    +

    +Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." +

    +

    +Disposition: move to review; unanimous consent. +

    +

    +(moots 782 and 800) +

    +
    + +

    Proposed resolution:

    @@ -16185,7 +13183,7 @@ Change 26.4.7.1 [rand.util.seedseq]: 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 +-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:

    @@ -16219,11 +13217,11 @@ for (InputIterator s = begin; s != end; ++s)

    804. Some problems with classes error_code/error_condition

    -

    Section: 19.4 [syserr] Status: New +

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

    +

    View all issues with Review status.

    Discussion:

    1. @@ -16274,8 +13272,203 @@ conditions (see related issue 832. +

      +

      +Part B: Technically correct, save for typo. Rendered moot by the concept proposal +(N2620) NAD (editorial). +

      +

      +Part C: We agree; this is consistent with the resolution of issue 721. +

      +

      +Howard: please ping Beman, asking him to clear away parts A and B from +the wording in the proposed resolution, so it is clear to the editor +what needs to be applied to the working paper. +

      +

      +Beman provided updated wording. Since issue 832 is not going +forward, the provided wording includes resolution of part A. +

      + + +

      Proposed resolution:

      + +

      +Resolution of part A: +

      +
      +

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

      + +
      private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
      + +

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

      + +
      +
      error_code();
+
      +
      +

      +Effects: Constructs an object of type error_code. +

      +

      +Postconditions: val_ == 0 and cat_ == &system_category. +

      +

      +Throws: Nothing. +

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

      +Effects: Constructs an object of type error_code. +

      +

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

      +

      +Throws: Nothing. +

      +
      +
      + +

      +Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: +

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

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

      +

      +Throws: Nothing. +

      +
      +
      + +

      +Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: +

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

      +Returns: *cat_. +

      +

      +Throws: Nothing. +

      +
      +
      + +

      +Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: +

      + +
      private:
+  int val_;                    // exposition only
+  const error_category&* cat_; // exposition only
+
      + +

      +Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: +

      +

      [ +(If the proposed resolution of issue 805 has already been applied, the +name posix_category will have been changed to generic_category. That has +no effect on this resolution.) +]

      + + +
      +
      error_condition();
+
      +
      +

      +Effects: Constructs an object of type error_condition. +

      +

      +Postconditions: val_ == 0 and cat_ == &posix_category. +

      +

      +Throws: Nothing. +

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

      +Effects: Constructs an object of type error_condition. +

      +

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

      +

      +Throws: Nothing. +

      +
      +
      + +

      +Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: +

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

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

      +

      +Throws: Nothing. +

      +
      +
      + +

      +Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +

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

      +Returns: *cat_. +

      +

      +Throws: Nothing. +

      +
      +
      +
      + +

      +Resolution of part C: +

      + +
      +

      In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.

      @@ -16294,104 +13487,6 @@ In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
      -

      -In 19.4.2.1 [syserr.errcode.overview]/1, class error_code synopsis, modifiers section, -replace the current operator= overload by the following: -

      - -
      -
      template <class ErrorCodeEnum> 
-  typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 
-    operator=(ErrorCodeEnum e);
-
      -
      - -

      -In the private section of the same class replace the current -data member cat_ definition by: -

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

      -In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read: -

      - -
      -
      error_code();
-
      -
      -

      -

      ...

      - -

      -Postconditions: val_ == 0 and cat_ == &system_category. -

      -
      -
      - -

      -Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read: -

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

      ...

      -

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

      -
      -
      - -

      -In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read: -

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

      -

      ...

      - -

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

      -
      -
      - -

      -In 19.4.2.3 [syserr.errcode.modifiers], change the operator= signature to read: -

      - -
      -
      template <class ErrorCodeEnum> 
-  typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 
-    operator=(ErrorCodeEnum e);
-
      -
      - -

      -In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read: -

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

      -

      ...

      - -

      -Returns: *cat_. -

      -
      -
      -

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

      @@ -16401,120 +13496,14 @@ In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.

      -

      ...

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

      Throws: Nothing.

      -

      -In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition -synopsis, constructors section, replace the template constructor -overload declaration by one with an added "::value" -

      - -
      -
      template <class ErrorConditionEnum>
-  error_condition(ErrorConditionEnum e,
-    typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type* = 0);
-
      -
      - -

      -In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition synopsis, -modifiers section, -replace the operator= overload declaration by: -

      - -
      -
      template<typename ErrorConditionEnum> 
-  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_code error_condition>::type & 
-     operator=( ErrorConditionEnum e );
-
      -
      - -

      -In the private section of the same class replace the current -data member cat_ definition by: -

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

      -In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read: -

      - -
      -
      error_condition();
-
      -
      -

      -

      ...

      - -

      -Postconditions: val_ == 0 and cat_ == &posix_category. -

      -
      -
      - -

      -In the same section, change p. 5 to read: -

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

      -

      ...

      - -

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

      -
      -
      - -

      -In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read: -

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

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

      -
      -
      - -

      -In the same section replace the current operator= overload declaration by: -

      - -
      -
      template <class ErrorConditionEnum> 
-  typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type&
-    operator=(ErrorConditionEnum e);
-
      - -

      -In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read: -

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

      -Returns: *cat_. -

      -
      -
      -

      In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.

      @@ -16524,14 +13513,15 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.

      -

      ...

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

      Throws: Nothing.

      + @@ -16540,11 +13530,11 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.

      805. posix_error::posix_errno concerns

      -

      Section: 19.4 [syserr] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      19.4 [syserr] @@ -16793,9 +13783,9 @@ 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 +

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

      -

      View all issues with New status.

      +

      View all issues with Ready status.

      Discussion:

      void unique_ptr::reset(T* p = 0) is currently specified as: @@ -16845,7 +13835,7 @@ scenario, as it definitely doesn't when p and q are separate.

      Proposed resolution:

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

      @@ -16857,7 +13847,7 @@ Change 20.6.11.2.5 [unique.ptr.single.modifiers]:

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

      @@ -16878,9 +13868,9 @@ Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:

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

      -

      Section: 20.3.1.2 [tuple.cnstr] Status: New +

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

      -

      View all issues with New status.

      +

      View all issues with Ready status.

      Discussion:

      527 Added a throws clause to bind constructors. I believe the same throws clause @@ -16890,7 +13880,7 @@ should be added to tuple except it ought to take into account move cons

      Proposed resolution:

      -Add to 20.3.1.2 [tuple.cnstr]: +Add to 20.4.1.2 [tuple.cnstr]:

      @@ -16906,11 +13896,11 @@ or assignment of one of the types in Types throws an exception.

      808. [forward] incorrect redundant specification

      -

      Section: 20.2.2 [forward] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      p4 (forward) says: @@ -16987,10 +13977,10 @@ In both cases, A2 is deduced as double, so 1.414 is forwarded to A<

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

      -

      Section: 25.2.3 [alg.swap] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      For the sake of generic programming, the header <algorithm> should provide an @@ -17277,14 +14267,14 @@ Thread-Safety in the Standard Library (Rev 1).

      813. "empty" undefined for shared_ptr

      -

      Section: 20.6.12.2 [util.smartptr.shared] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      -Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr. +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 @@ -17406,7 +14396,7 @@ Alisdair's wording is fine.

      Proposed resolution:

      -Append the following sentance to 20.6.12.2 [util.smartptr.shared] +Append the following sentance to 20.7.12.2 [util.smartptr.shared]

      The shared_ptr class template stores a pointer, usually obtained @@ -17444,15 +14434,27 @@ a pointer is said to be empty.

      815. std::function and reference_closure do not use perfect forwarding

      -

      Section: 20.5.15.2.4 [func.wrap.func.inv] Status: New +

      Section: 20.6.15.2.4 [func.wrap.func.inv] Status: Open Submitter: Alisdair Meredith Date: 2008-03-16

      -

      View all issues with New status.

      +

      View all issues with Open status.

      Discussion:

      std::function and reference_closure should use "perfect forwarding" as described in the rvalue core proposal.

      +

      [ +Sophia Antipolis: +]

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

      @@ -17464,7 +14466,7 @@ described in the rvalue core proposal.

      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 +

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

      @@ -17510,7 +14512,7 @@ Howard adds:

      817. bind needs to be moved

      -

      Section: 20.5.11.1.3 [func.bind.bind] Status: New +

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

      @@ -17607,7 +14609,7 @@ the other normative text.

      -Double-check 29.4.4 [atomics.types.operations] that each +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.)

      @@ -17618,7 +14620,7 @@ both. (It could be clearer, IMO. Solution not in current proposed resolution.)

      -And why does 29.4.4 [atomics.types.operations] p9 for "load" say: +And why does 29.4 [atomics.types.operations] p9 for "load" say:

      @@ -17632,7 +14634,7 @@ nor memory_order_acq_rel.

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

      @@ -17693,7 +14695,7 @@ those is already included in the happens before ordering. -- end note]

      -Rephrase 29.4.4 [atomics.types.operations] p12 as: +Rephrase 29.4 [atomics.types.operations] p12 as:

      @@ -17848,12 +14850,12 @@ infinite recursion. -- end note.]

      821. Minor cleanup : unique_ptr

      -

      Section: 20.6.11.3.3 [unique.ptr.runtime.modifiers] Status: New +

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

      View all issues with New status.

      Discussion:

      -Reading resolution of LWG issue 673 I noticed the following: +Reading resolution of LWG issue 673 I noticed the following:

      @@ -17877,7 +14879,7 @@ to be a stronger match than the deleted overload. Words...

      Proposed resolution:

      -Add to class template definition in 20.6.11.3 [unique.ptr.runtime] +Add to class template definition in 20.7.11.3 [unique.ptr.runtime]

      @@ -17891,7 +14893,7 @@ void swap(unique_ptr&& u);

      -Update 20.6.11.3.3 [unique.ptr.runtime.modifiers] +Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]

      @@ -17912,7 +14914,7 @@ templated overload. -- end note]

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

      @@ -18002,11 +15004,11 @@ In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible

      823. identity<void> seems broken

      -

      Section: 20.2.2 [forward] Status: New +

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

      +

      View all issues with Review status.

      Discussion:

      N2588 seems to have added an operator() member function to the @@ -18020,9 +15022,50 @@ Suggested resolution: Specialize identity<void> so as not to req the member function's presence.

      +

      [ +Sophia Antipolis: +]

      + + +
      +

      +Jens: suggests to add a requires clause to avoid specializing on void. +

      +

      +Alisdair: also consider cv-qualified void. +

      +

      +Alberto provided proposed wording. +

      +
      +

      Proposed resolution:

      +Change definition of identity in 20.2.2 [forward], paragraph 2, to: +

      + +
      template <class T>  struct identity {
+    typedef T type;
+
+    requires ReferentType<T>
+      const T& operator()(const T& x) const;
+  };
+
      +

      ...

      +
        requires ReferentType<T>
+    const T& operator()(const T& x) const;
+
      + + +

      Rationale:

      +

      +The point here is to able to write T& given T and ReferentType is +precisely the concept that guarantees so, according to N2677 +(Foundational concepts). Because of this, it seems preferable than an +explicit check for cv void using SameType/remove_cv as it was suggested +in Sophia. In particular, Daniel remarked that there may be types other +than cv void which aren't referent types (int[], perhaps?).

      @@ -18031,10 +15074,10 @@ the member function's presence.

      824. rvalue ref issue with basic_string inserter

      -

      Section: 21.3.8.9 [string.io] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      In the current working paper, the <string> header synopsis at the end of @@ -18071,20 +15114,32 @@ signatures in 21.3.8.9 [string.io] should be deleted.

      Proposed resolution:

      +Delete the first of the two signatures in 21.3.8.9 [string.io]:

      +
      template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>& os,
+              const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+   operator<<(basic_ostream<charT, traits>&& os,
+              const basic_string<charT,traits,Allocator>& str);
+
      +

      825. Missing rvalues reference stream insert/extract operators?

      -

      Section: 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8 +

      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: New +[re.submatch] Status: Open Submitter: Alisdair Meredith Date: 2008-04-10

      -

      View all issues with New status.

      +

      View all issues with Open status.

      Discussion:

      Should the following use rvalues references to stream in insert/extract @@ -18093,7 +15148,7 @@ operators?

      • 19.4.2.1 [syserr.errcode.overview]
        • -
      • 20.6.12.2.8 [util.smartptr.shared.io]
        • +
      • 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]
        • @@ -18103,55 +15158,15 @@ operators?
      • 28.9 [re.submatch]
      - -

      Proposed resolution:

      -

      -

      - - - - - -
      -

      826. Equivalent of %'d, or rather, lack thereof?

      -

      Section: 22.2.2.2 [locale.nm.put] Status: New - Submitter: Peter Dimov Date: 2008-04-07

      -

      View all issues with New status.

      -

      Discussion:

      -

      -In the spirit of printf vs iostream... -

      - -

      -POSIX printf says that %'d should insert grouping characters (and the -implication is that in the absence of ' no grouping characters are -inserted). The num_put facet, on the other hand, seems to always insert -grouping characters. Can this be considered a defect worth fixing for -C++0x? Maybe ios_base needs an additional flag? -

      -

      [ -Pablo Halpern: +Sophia Antipolis ]

      -I'm not sure it constitutes a defect, but I would be in favor of adding -another flag (and corresponding manipulator). +Agree with the idea in the issue, Alisdair to provide wording.
      -

      [ -Martin Sebor: -]

      - - -
      -I don't know if it qualifies as a defect but I agree that there -should be an easy way to control whether the thousands separator -should or shouldn't be inserted. A new flag would be in line with -the current design of iostreams (like boolalpha, showpos, or -showbase). -

      Proposed resolution:

      @@ -18164,7 +15179,7 @@ the current design of iostreams (like boolalpha, showpos, or

      827. constexpr shared_ptr::shared_ptr()?

      -

      Section: 20.6.12.2.1 [util.smartptr.shared.const] Status: New +

      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.

      @@ -18187,9 +15202,9 @@ unfair advantage of raw pointers.

      828. Static initialization for std::mutex?

      -

      Section: 30.3.1.1 [thread.mutex.class] Status: New +

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

      -

      View all issues with New status.

      +

      View all issues with Review status.

      Discussion:

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

      + + +
      +

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

      +

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

      +
      +

      Proposed resolution:

      +Change 30.3.1.1 [thread.mutex.class]:

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

      829. current_exception wording unclear about exception type

      -

      Section: 18.7.5 [propagation] Status: New +

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

      +

      View all issues with Ready status.

      Discussion:

      Consider this code:

      @@ -18284,7 +15328,7 @@ After 18.7.5 [propagation] , paragraph 7, add the indicated text:

      Returns: exception_ptr object that refers -to the currently handled exception or a copy of the currently handled +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. @@ -18296,12 +15340,6 @@ creates a new copy each time it is called. -- end note]

      -

      -Remarks: The type of the exception object -referred to by the returned exception_ptr is the most-derived -type of the currently handled exception. -

      -

      Throws: nothing.

      @@ -18316,11 +15354,10 @@ type of the currently handled exception.

      830. Incomplete list of char_traits specializations

      -

      Section: 21.1 [char.traits] Status: New +

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

      -

      View other active issues in [char.traits].

      View all other issues in [char.traits].

      -

      View all issues with New status.

      +

      View all issues with Open status.

      Discussion:

      Paragraph 4 of 21.1 [char.traits] mentions that this @@ -18342,6 +15379,21 @@ should also be added to <ios_fwd> in 27.2 [iostream.forward], and taking a char_traits parameter in that header.

      +

      [ +Sophia Antipolis: +]

      + + +
      +

      +Idea of the issue is ok. +

      +

      +Alisdair to provide wording, once that wording arrives, move to review. +

      +
      + +

      Proposed resolution:

      @@ -18361,50 +15413,13 @@ taking a char_traits parameter in that header. -

      -

      831. wrong type for not_eof()

      -

      Section: 21.1.3 [char.traits.specializations] Status: New - Submitter: Dietmar Kühl Date: 2008-04-23

      -

      View all other issues in [char.traits.specializations].

      -

      View all issues with New status.

      -

      Discussion:

      -

      - In Table 56 (Traits requirements) the not_eof() member function - is using an argument of type e which denotes an object of - type X::int_type. However, the specializations in - 21.1.3 [char.traits.specializations] all use char_type. - This would effectively mean that the argument type actually can't - represent EOF in the first place. I'm pretty sure that the type used - to be int_type which is quite obviously the only sensible - argument. -

      -

      - This issue is close to being editorial. I suspect that the proposal - changing this section to include the specializations for char16_t - and char32_t accidentally used the wrong type. -

      - - -

      Proposed resolution:

      -

      - In 21.1.3.1 [char.traits.specializations.char], - 21.1.3.2 [char.traits.specializations.char16_t], - 21.1.3.3 [char.traits.specializations.char32_t], and - [char.traits.specializations.wchar_t] correct the - argument type from char_type to int_type. -

      - - - - -

      832. Applying constexpr to System error support

      -

      Section: 19.4 [syserr] Status: New +

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

      +

      View all issues with Open status.

      Discussion:

      Initialization of objects of class error_code @@ -18444,6 +15459,35 @@ proposed resolution thus changes the private member to a pointer, which also brings it in sync with real implementations.

      +

      [ +Sophia Antipolis: +]

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

      [ +Pre-San Francisco: +]

      + + +
      +

      +Beman Dawes reports that this proposal is unimplementable, and thus NAD. +

      +

      +Implementation would require constexpr objects of classes derived +from class error_category, which has virtual functions, and that is +not allowed by the core language. This was determined when trying to +implement the proposal using a constexpr enabled compiler provided +by Gabriel Dos Reis, and subsequently verified in discussions with +Gabriel and Jens Maurer. +

      + +
      +

      Proposed resolution:

      @@ -18606,7 +15650,7 @@ Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition

      -
      constexpr error_condition(int val, const error_category&* cat);
+
      constexpr error_condition(int val, const error_category&* cat);
 
      
 
      
 Effects: Constructs an object of type error_condition.
@@ -18660,15 +15704,58 @@ paragraphs 2 and 4, change "category.equivalent("  to
 "category()->equivalent(".
 
      
 
+
      
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
+
      
+
+
      public:
+  system_error(error_code ec, const string& what_arg);
+  system_error(error_code ec);
+  system_error(int ev, const error_category&* ecat,
+      const string& what_arg);
+  system_error(int ev, const error_category&* ecat);
+
      
+
+
      
+Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
+
      
+
+
      
+
      system_error(int ev, const error_category&* ecat, const string& what_arg);
+
      
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == error_code(ev, ecat) and
+strcmp(runtime_error::what(), what_arg.c_str()) == 0.
+
      
+
      
+
+
      system_error(int ev, const error_category&* ecat);
+
      
+
      
+
      
+Effects: Constructs an object of class system_error.
+
      
+
      
+Postconditions: code() == error_code(ev, ecat) and
+strcmp(runtime_error::what(), "") == 0.
+
      
+
      
+
      
+
+
 
 
 
 
 
      
 
      833. Freestanding implementations header list needs review for C++0x
      
-
      Section: 17.4.1.3 [compliance] Status: New
+
      Section: 17.4.1.3 [compliance] Status: Open
  Submitter: Beman Dawes Date: 2008-05-14
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
 Once the C++0x standard library is feature complete, the LWG needs to
@@ -18685,12 +15772,12 @@ ensure it reflects LWG consensus.
 
 
      
 
      834. Unique_ptr::pointer requirements underspecified
      
-
      Section: 20.6.11.2 [unique.ptr.single] Status: New
+
      Section: 20.7.11.2 [unique.ptr.single] Status: Open
  Submitter: Daniel Krügler Date: 2008-05-14
      
-
      View all issues with New status.
      
+
      View all issues with Open status.
      
 
      Discussion:
      
 
      
-Issue 673 (including recent updates by 821) proposes a useful
+Issue 673 (including recent updates by 821) proposes a useful
 extension point for unique_ptr by granting support for an optional
 deleter_type::pointer to act as pointer-like replacement for element_type*
 (In the following: pointer).
@@ -18722,11 +15809,27 @@ that all of the expressions of pointer used to define semantics are req
 be well-formed and well-defined (also as back-end for 762).
 
      
 
+
      [
+Sophia Antipolis:
+]
      
+
+
+
      
+
      
+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.6.11.2 [unique.ptr.single]/p. 3:
+20.7.11.2 [unique.ptr.single]/p. 3:
 
      
 
 
      
@@ -18842,6 +15945,7 @@ calls os.flush() os.rdbuf()->pubsync().
 
      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:
      
        
      
 
@@ -19212,5 +16316,3403 @@ 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.
+
      
+
+
      
+This ability---to specify operations in terms of their equivalent in the
+root class---can be done with e.g. normal functions, but there is,
+AFAIK, no way to do it for class templates. Being able to access
+compile-time information about the type-hierachy can be very powerful,
+and I therefore also suggest traits that computes the directly derived
+class whenever that is possible.
+
      
+
+
      
+If the computation can not be done, the traits should fall back on an
+identity transformation. I expect this gives the best overall usability.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
+
      
+
+
      template< class T > struct direct_base_class;
+template< class T > struct direct_derived_class;
+template< class T > struct root_base_class;
+
      
+
+
      
+Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
+
      
+
+
      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
      TemplateConditionComments
      template< class T > struct direct_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous direct base class of T.
+If no such type exists, the member typedef type shall equal T.
      template< class T > struct direct_derived_class;T shall be a complete type.The member typedef type shall equal the unambiguous type which has T
+as an accessible unambiguous direct base class. If no such type exists, the member typedef
+type shall equal T.
      template< class T > struct root_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous most indirect base class of
+T. If no such type exists, the member typedef type shall equal T.
      
+
      
+
+
+
+
+
+
+
      
+
      850. Should shrink_to_fit apply to std::deque?
      
+
      Section: 23.2.2.2 [deque.capacity] Status: Ready
+ Submitter: Niels Dekker Date: 2008-06-05
      
+
      View other active issues in [deque.capacity].
      
+
      View all other issues in [deque.capacity].
      
+
      View all issues with Ready status.
      
+
      Discussion:
      
+
      
+Issue 755 added a shrink_to_fit function to std::vector and std::string.
+It did not yet deal with std::deque, because of the fundamental
+difference between std::deque and the other two container types. The
+need for std::deque may seem less evident, because one might think that
+for this container, the overhead is a small map, and some number of
+blocks that's bounded by a small constant.
+
      
+
      
+The container overhead can in fact be arbitrarily large (i.e. is not
+necessarily O(N) where N is the number of elements currently held by the
+deque).  As Bill Plauger noted in a reflector message, unless the map of
+block pointers is shrunk, it must hold at least maxN/B pointers where
+maxN is the maximum of N over the lifetime of the deque since its
+creation.  This is independent of how the map is implemented
+(vector-like circular buffer and all), and maxN bears no relation to N,
+the number of elements it currently holds.
+
      
+
      
+Hervé Brönnimann reports a situation where a deque of requests grew very
+large due to some temporary backup (the front request hanging), and the
+map of the deque grew quite large before getting back to normal.  Just
+to put some color on it, assuming a deque with 1K pointer elements in
+steady regime, that held, at some point in its lifetime, maxN=10M
+pointers, with one block holding 128 elements, the spine must be at
+least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
+would allow to reuse about 100K which would otherwise never be reclaimed
+in the lifetime of the deque.
+
      
+
      
+An added bonus would be that it *allows* implementations to hang on to
+empty blocks at the end (but does not care if they do or not).  A
+shrink_to_fit would take care of both shrinks, and guarantee that at
+most O(B) space is used in addition to the storage to hold the N
+elements and the N/B block pointers.
+
      
+
+
+
      Proposed resolution:
      
+
      
+To Class template deque 23.2.2 [deque] synopsis, add:
+
      
+
      void shrink_to_fit();
+
      
+
+
      
+To deque capacity 23.2.2.2 [deque.capacity], add:
+
      
+
      void shrink_to_fit();
+
      
+
+
      
+Remarks: shrink_to_fit is a non-binding request to reduce memory
+use. [Note: The request is non-binding to allow latitude for
+implementation-specific optimizations. -- end note]
+
      
+
      
+
+
+
+
+
+
      
+
      851. simplified array construction
      
+
      Section: 23.2.1 [array] Status: Review
+ Submitter: Benjamin Kosnik Date: 2008-06-05
      
+
      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.
+
      
+
+
      
+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.
+
      
+
      
+5 Throws: length_error if n > max_size().
+
      
+
      
+6 Remarks: It is guaranteed that no invalidation takes place during a  
+sequence of insert or erase operations at either end that happens  
+after a call to reserve() except to the erased elements, until the  
+time when an insertion would make max(n_f-m_f, n_b-m_b) larger than  
+capacity(), where n_f is the number of push_front, m_f of pop_front,  
+n_b of push_back, and m_b of pop_back operations since the call to  
+reserve().
+
      
+
      
+7        An implementation is free to pre-allocate buffers so as to  
+offer the additional guarantee that no exception will be thrown  
+during such a sequence other than by the element constructors.
+
      
+
      
+
      
+
+
      
+And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
+
      
+
+
      
+1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the
+deque. An insertion at either end of the deque invalidates all the iterators to the deque,
+unless provisions have been made with reserve,
+but has no effect on the validity of references to elements of the deque.
+
      
+
+
+
+
+
+
      
+
      856. Removal of aligned_union
      
+
      Section: 20.5.7 [meta.trans.other] Status: New
+ Submitter: Jens Maurer Date: 2008-06-12
      
+
      View other active issues in [meta.trans.other].
      
+
      View all other issues in [meta.trans.other].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+With the arrival of extended unions 
+(N2544),
+there is no
+known use of aligned_union that couldn't be handled by
+the "extended unions" core-language facility.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Remove the following signature from 20.5.2 [meta.type.synop]:
+
      
+
      template <std::size_t Len, class... Types> struct aligned_union;
+
      
+
+
      
+Remove the second row from table 51 in 20.5.7 [meta.trans.other],
+starting with:
+
      
+
+
      template <std::size_t Len,
+class... Types>
+struct aligned_union;
+
      
+
+
+
+
+
+
      
+
      857. condition_variable::time_wait return bool error prone
      
+
      Section: 30.4.1 [thread.condition.condvar] Status: New
+ Submitter: Beman Dawes Date: 2008-06-13
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+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.
+
      
+
      
+It might be simpler to change the return type to a scoped enum:
+
      
+
      enum class timeout { not_reached, reached };
+
      
+
+
      
+That's the same cost as returning a bool, but not subject to mistakes. Your example below would be:
+
      
+
+
      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:
      
+
      
+The first sentence of the Effects clause for undeclare_reachable seems
+to be missing some words. I can't parse
+
      
+
      
+... for all non-null p referencing the argument is no longer declared reachable...
+
      
+
      
+I take it the intent is that undeclare_reachable should be called only
+when there has been a corresponding call to declare_reachable. In
+particular, although the wording seems to allow it, I assume that code
+shouldn't call declare_reachable once then call undeclare_reachable
+twice.
+
      
+
      
+I don't know what "shall be live" in the Requires clause means.
+
      
+
      
+In the final Note for undeclare_reachable, what does "cannot be
+deallocated" mean? Is this different from "will not be able to collect"?
+
      
+
+
      
+For the wording on nesting of declare_reachable and
+undeclare_reachable, the words for locking and unlocking recursive
+mutexes probably are a good model.
+
      
+
+
+
      Proposed resolution:
      
+
      
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+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)
+
      
+
+
      
+when monotonic_clock is not required to exist?
+
      
+
+
+
      Proposed resolution:
      
+
      
+
      
+
+
+
+
+
+
      
+
      860. Floating-Point State
      
+
      Section: 26 [numerics] Status: New
+ Submitter: Lawrence Crowl Date: 2008-06-23
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+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:
      
+
      
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+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()
+
      
+
+
      
+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. 
+
      
+
      
+Both proposal choices are discussed, the preferred choice of the author is
+to apply (A).
+
      
+
+
+
      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):
+
      
+
      
+
        
+
      • 
+
        
+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: 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):
+
      
+
      
+
        
+
      • 
+
        
+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:
      
+
      
+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!
+
      
+
+
      
+This same issue also applies to:
+
      
+
+
        
+
      • set_union
        • 
+
      • set_intersection
        • 
+
      • set_difference
        • 
+
      • set_symmetric_difference
        • 
+
      • merge
        • 
+
      
+
+
+
      Proposed resolution:
      
+
      
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+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.
+
      
+
      
+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:
      
+
      
+
      
+
+
+
+
+
+
      
+
      864. Defect in atomic wording
      
+
      Section: 29.4 [atomics.types.operations] Status: New
+ Submitter: Anthony Williams Date: 2008-07-10
      
+
      View all other issues in [atomics.types.operations].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+There's an error in 29.4 [atomics.types.operations]/p9:
+
      
+
+
      
+
      C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+
      
+
      
+
      
+Requires: The order argument shall not be memory_order_acquire nor
+memory_order_acq_rel.
+
      
+
      
+
      
+
+
      
+I believe that this should state
+
      
+
      
+shall not be memory_order_release.
+
      
+
+
      
+There's also an error in 29.4 [atomics.types.operations]/p17:
+
      
+
+
      
+... When only one memory_order argument is supplied, the value of success
+is order, and
+the value of failure is order except that a value of
+memory_order_acq_rel shall be replaced by the value
+memory_order_require ...
+
      
+
      
+I believe this should state
+
      
+
      
+shall be replaced by the value memory_order_acquire ...
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 29.4 [atomics.types.operations]/p9:
+
      
+
+
      
+
      C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+
      
+
      
+
      
+Requires: The order argument shall not be memory_order_acquire
+memory_order_release nor memory_order_acq_rel.
+
      
+
      
+
      
+
+
      
+Change 29.4 [atomics.types.operations]/p17:
+
      
+
+
      
+... When only one memory_order argument is supplied, the value of success
+is order, and
+the value of failure is order except that a value of
+memory_order_acq_rel shall be replaced by the value
+memory_order_require memory_order_acquire ...
+
      
+
+
+
+
+
+
+
      
+
      865. More algorithms that throw away information
      
+
      Section: 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: New
+ Submitter: Daniel Krügler Date: 2008-07-13
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+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:
+
      
+
+
        
+
      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. 
+
      
+
      
+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. 
+
        
+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:
+
        
+
        
+Returns: first + n for fill_n.
+
        
+
        2. 
+
      2. 
+
        
+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:
+
        
+
        
+Returns: first + n for generate_n.
+
        
+
        3. 
+
      
+
+
+
+
+
+
      
+
      866. Qualification of placement new-expressions
      
+
      Section: 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] Status: New
+ Submitter: Alberto Ganesh Barbati Date: 2008-07-14
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+LWG issue 402 replaced "new" with "::new" in the placement
+new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
+given in 402 applies also to the following other contexts:
+
      
+
        
+
      • 
+
        
+in 20.7.10 [specialized.algorithms], all four algorithms unitialized_copy,
+unitialized_copy_n, unitialized_fill and unitialized_fill_n use
+the unqualified placement new-expression in some variation of the form:
+
        
+
        new  (static_cast<void*>(&*result)) typename  iterator_traits<ForwardIterator>::value_type(*first);
+
        
+
        • 
+
      • 
+
        
+in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
+
        
+
        new  (pv)  T(std::forward<Args>(args)...),
+
        
+
        • 
+
      
+
      
+I suggest to add qualification in all those places. As far as I know,
+these are all the remaining places in the whole library that explicitly
+use a placement new-expression. Should other uses come out, they should
+be qualified as well.
+
      
+
      
+As an aside, a qualified placement new-expression does not need
+additional requirements to be compiled in a constrained context. By
+adding qualification, the HasPlacementNew concept introduced recently in
+N2677 (Foundational Concepts)
+would no longer be needed by library and
+should therefore be removed.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Replace "new" with "::new" in:
+
      
+
        
+
      • 
+20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
+
        • 
+
      • 
+20.7.10.2 [uninitialized.fill]  paragraph 1
+
        • 
+
      • 
+20.7.10.3 [uninitialized.fill.n] paragraph 1
+
        • 
+
      • 
+20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
+
        • 
+
      
+
+
+
+
+
+
+
      
+
      867. Valarray and value-initialization
      
+
      Section: 26.5.2.1 [valarray.cons] Status: New
+ Submitter: Alberto Ganesh Barbati Date: 2008-07-20
      
+
      View other active issues in [valarray.cons].
      
+
      View all other issues in [valarray.cons].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+From 26.5.2.1 [valarray.cons], paragraph 2:
+
      
+
+
      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.
+
      
+
      
+
+
      
+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:
+
      
+
+
      
+The elements of the array are constructed using the default constructor for the instantiating type T.
+
      
+
      
+with
+
      
+
      
+The elements of the array are value-initialized.
+
      
+
+
      
+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).
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 26.5.2.1 [valarray.cons], paragraph 2:
+
      
+
+
      
+
      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]).
+
      
+
      
+
+
      
+Change 26.5.2.7 [valarray.members], paragraph 9:
+
      
+
+
      
+[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]
+
      
+
+
+
+
+
+
+
      
+
      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:
      
+
      
+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
        • 
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+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++;
+
      
+
+
      
+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
      
+
      
+
+
+
+
+
+
+
      
+
      870. Do unordered containers not support function pointers for predicate/hasher?
      
+
      Section: 23.1.5 [unord.req] Status: New
+ Submitter: Daniel Krügler Date: 2008-08-17
      
+
      View other active issues in [unord.req].
      
+
      View all other issues in [unord.req].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.1.4 [associative.reqmts]/2:
+
      
+
+
      
+Each associative container is parameterized on Key and an ordering
+relation Compare that
+induces a strict weak ordering (25.3) on elements of Key. [..]. The
+object of type Compare is
+called the comparison object of a container. This comparison object
+may be a pointer to
+function or an object of a type with an appropriate function call operator.[..]
+
      
+
+
      
+The corresponding wording for unordered containers is not so clear,
+but I read it to disallow
+function pointers for the hasher and I miss a clear statement for the
+equality predicate, see
+23.1.5 [unord.req]/3+4+5:
+
      
+
+
      
+
      
+Each unordered associative container is parameterized by Key, by a
+function object Hash that
+acts as a hash function for values of type Key, and by a binary
+predicate Pred that induces an
+equivalence relation on values of type Key.[..]
+
      
+
      
+A hash function is a function object that takes a single argument of
+type Key and returns a
+value of type std::size_t.
+
      
+
      
+Two values k1 and k2 of type Key are considered equal if the
+container's equality function object
+returns true when passed those values.[..]
+
      
+
      
+
+
      
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
+
      
+
+
      
+Hash shall be a unary function object type such that the expression
+hf(k) has type std::size_t.
+
      
+
+
      
+Note that 20.6 [function.objects]/1 defines as "Function objects are
+objects with an operator() defined.[..]"
+
      
+
      
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 23.1.5 [unord.req]/3, just after the second sentence which is written as
+
      
+
+
      
+Additionally, unordered_map and unordered_multimap associate an
+arbitrary mapped type T with the Key.
+
      
+
+
      
+add one further sentence:
+
      
+
+
      
+Both Hash and Pred may be pointers to function or objects of a type
+with an appropriate function call operator.
+
      
+
+
      
+[Note1: Since the detailed requirements for Pred and Hash are given in
+p.4 and p.5, it an alternative resolution
+would be to insert a new paragraph just after p.5, which contains the
+above proposed sentence]
+
      
+
      
+[Note2: I do not propose a change of above quoted element in table 97,
+because the mis-usage of the
+notion of "function object" seems already present in the standard at
+several places, even if it includes
+function pointers, see e.g. 25 [algorithms]/7. The important point is
+that in those places a statement is
+given that the actually used symbol, like "Predicate" applies for
+function pointers as well]
+
      
+
+
+
+
+
+
      
+
      871. Iota's requirements on T are too strong
      
+
      Section: 26.6.5 [numeric.iota] Status: New
+ Submitter: Daniel Krügler Date: 2008-08-20
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+According to the recent WP
+N2691,
+26.6.5 [numeric.iota]/1, the requires clause
+of std::iota says:
+
      
+
+
      
+T shall meet the requirements of CopyConstructible and Assignable types, and
+shall be convertible to ForwardIterator's value type.[..]
+
      
+
+
      
+Neither CopyConstructible nor Assignable is needed, instead MoveConstructible
+seems to be the correct choice. I guess the current wording resulted as an
+artifact from comparing it with similar numerical algorithms like accumulate.
+
      
+
+
      
+Note: If this function will be conceptualized, the here proposed
+MoveConstructible
+requirement can be removed, because this is an implied requirement of
+function arguments, see
+N2710/[temp.req.impl]/3, last bullet.
+
      
+
+
+
+
      Proposed resolution:
      
+
+
      
+Change the first sentence of 26.6.5 [numeric.iota]/1:
+
      
+
+
      
+Requires: T shall meet the requirements of
+CopyConstructible and Assignable types,
+
+be MoveConstructible (Table 34)
+
+and shall be
+convertible to ForwardIterator's value type. [..]
+
      
+
+
+
+
+
+
+
      
+
      872. move_iterator::operator[] has wrong return type
      
+
      Section: 24.4.3.3.12 [move.iter.op.index] Status: New
+ Submitter: Doug Gregor Date: 2008-08-21
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+move_iterator's operator[] is declared as:
+
      
+
+
      reference operator[](difference_type n) const;
+
      
+
+
      
+This has the same problem that reverse_iterator's operator[] used to
+have: if the underlying iterator's operator[] returns a proxy, the
+implicit conversion to value_type&& could end up referencing a temporary
+that has already been destroyed. This is essentially the same issue that
+we dealt with for reverse_iterator in DR 386.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
+move_iterator's operator[] to:
+
      
+
+
      reference unspecified operator[](difference_type n) const;
+
      
+
+
+
+
+
+
+
      
+
      873. signed integral type and unsigned integral type are not clearly defined
      
+
      Section: 3.9.1 [basic.fundamental] Status: New
+ Submitter: Travis Vitek Date: 2008-06-30
      
+
      View all issues with New status.
      
+
      Discussion:
      
+    
      
+      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.
+    
      
+
+    
      
+      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:
      
+
      
+During the Sophia Antipolis meeting it was decided to separate from 793 a
+subrequest that adds initializer list support to
+discrete_distribution, specifically,
+the issue proposed to add a c'tor taking a initializer_list<double>.
+
      
+
+
+
+
      Proposed resolution:
      
+
        
+
      1. 
+
        
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution,
+just before the member declaration
+
        
+
+
        explicit discrete_distribution(const param_type& parm);
+
        
+
+
        
+insert
+
        
+
+
        discrete_distribution(initializer_list<double> wl);
+
        
+
        2. 
+
+
      2. 
+
        
+Between p.4 and p.5 of the same section insert a new
+paragraph as part of the new member description:
+
        
+
+
        discrete_distribution(initializer_list<double> wl);
+
        
+
+
        
+Effects: Same as discrete_distribution(wl.begin(), wl.end()).
+
        
+
        
+
        3. 
+
      
+
+
+
+
+
+
      
+
      875. Missing initializer_list constructor for piecewise_constant_distribution
      
+
      Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New
+ Submitter: Daniel Krügler Date: 2008-08-22
      
+
      View other active issues in [rand.dist.samp.pconst].
      
+
      View all other issues in [rand.dist.samp.pconst].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+During the Sophia Antipolis meeting it was decided to separate from
+794 a subrequest that adds initializer list support to
+piecewise_constant_distribution, specifically, the issue proposed
+to add a c'tor taking a initializer_list<double> and a Callable to evaluate
+weight values. For consistency with the remainder of this class and
+the remainder of the initializer_list-aware library the author decided to
+change the list argument type to the template parameter RealType
+instead. For the reasoning to use Func instead of Func&& as c'tor
+function argument see issue 793.
+
      
+
+
+
      Proposed resolution:
      
+
        
+
      1. 
+
        
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution,
+just before the member declaration
+
        
+
+
        explicit piecewise_constant_distribution(const param_type& parm);
+
        
+
+
        
+insert
+
        
+
+
        template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
        
+
        2. 
+
+
      2. 
+
        
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
+
        
+
+
        template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+
        
+
+
        
+
+
        
+[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw.
+
        
+
+
        
+[p5_2] Requires:
+
        
+
+
          
+
        1. 
+fw shall be callable with one argument of type RealType, and shall
+   return values of a type convertible to double;
+
          2. 
+
        2. 
+The relation 0 < S = w0+. . .+wn-1 shall hold. 
+For all sampled values xk defined below, fw(xk) shall return a weight
+   value wk that is non-negative, non-NaN, and non-infinity;
+
          3. 
+
        3. 
+If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the
+following relations shall hold for k = 0, . . . , nf-1: bk < bk+1.
+
          4. 
+
        
+
+
        
+[p5_3] Effects:
+
        
+
+
          
+
        1. 
+
          If nf == 0,
          
+
            
+
          1. 
+lets the sequence w have length n = 1 and consist of the single
+     value w0 = 1, and
+
            2. 
+
          2. 
+lets the sequence b have length n+1 with b0 = 0 and b1 = 1.
+
            3. 
+
          
+
          2. 
+
+
        2. 
+
          Otherwise,
          
+
            
+
          1. 
+sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of
+length n+1, and
+
            2. 
+
          2. 
+
            lets the sequences w have length n and for each k = 0, . . . ,n-1,
+     calculates:
            
+
            xk = 0.5*(bk+1 + bk)
+wk = fw(xk)
+
            
+
            3. 
+
          
+
          3. 
+
+
        3. 
+
          
+Constructs a piecewise_constant_distribution object with
+the above computed sequence b as the interval boundaries
+and with the probability densities:
+
          
+
          ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
+
          
+
+
          4. 
+
        
+
+
        
+
        
+
        3. 
+
      
+
+
+
+
+
+
      
+
      876. basic_string access operations should give stronger guarantees
      
+
      Section: 21.3 [basic.string] Status: New
+ Submitter: Daniel Krügler Date: 2008-08-22
      
+
      View other active issues in [basic.string].
      
+
      View all other issues in [basic.string].
      
+
      View all issues with New status.
      
+
      Discussion:
      
+
      
+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.
+
      
+
      
+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.
+
      
+
      
+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. 
+
      
+
+
      
+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.
+
      
+
+
+
      Proposed resolution:
      
+
        
+
      1. 
+
          
+
        1. 
+
          In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
+
          
+
          
+Throws: Nothing.
+
          
+
+
          2. 
+
        2. 
+
          
+In 21.3.5 [string.access] replace p. 1 by the following 4 paragraghs:
+
          
+
+
          
+
          
+Requires: pos ≤ size().
+
          
+
          
+Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns
+a reference to a charT() that shall not be modified.
+
          
+
          
+Throws: Nothing.
+
          
+
          
+Complexity: Constant time.
+
          
+
          
+
+
          3. 
+
        3. 
+
          
+In 21.3.7.1 [string.accessors] replace the now common returns
+clause of c_str() and data() by the following three paragraphs:
+
          
+
          
+
          
+Returns: A pointer p such that p+i == &operator[](i) for each i
+in [0, size()].
+
          
+
          
+Throws: Nothing.
+
          
+
          
+Complexity: Constant time.
+
          
+
          
+
          4. 
+
        
+
        2. 
+
      2. 
+
          
+
        1. 
+
          
+In 21.3.5 [string.access] replace p.2 and p.3 by:
+
          
+
          
+
          
+Requires: pos ≤ size()
+
          
+
          
+Throws: out_of_range if pos > size().
+
          
+
          
+
          2. 
+
        
+
        3. 
+
      
+
+
+
+
+
+
+
      
+
      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:
      
+       
      
+
+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.
+
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+There are also 203 occurrences of "Throws: Nothing." scattered
+throughout the spec.
+
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+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;
+}
+
+struct SomeType {
+   SomeType (const SomeType&) throw ();
+}
      
+       
      
+       
      
+
+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):
+
+       
      
+       
      
+           
      template <> SomeType*
+uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
+{
+   for (; first != last; ++first, ++res)
+       ::new (res) SomeType (*first);
+
+   return res;
+}
      
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+For example, given the following definitions of
+class MayThrow and WontThrow and the two
+statements below:
+
+       
      
+       
      
+           
      struct MayThrow {
+   MayThrow ();
+};
+
+struct WontThrow {
+   WontThrow () throw ();
+};
+
+MayThrow  *a = new MayThrow [N];
+WontThrow *b = new WontThrow [N];
      
+
+       
      
+       
      
+
+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;
+}
      
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+Counterarguments:
+
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+         
        
+           
      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(...).
+
+       
      
+       
      
+
+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.
+
+       
      
+       
      
+
+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.
+
+      
      
+   
+   
      Proposed resolution:
      
+       
      
+
+We propose two possible solutions. Our recommendation is to adopt
+Option 1 below.
+
+       
      
+       
      
+
+Option 1:
+
+       
      
+       
      
+
+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."
+
+       
      
+       
      
+
+Option 2:
+
+       
      
+       
      
+
+For consistency, replace all occurrences of the empty exception
+specification with a "Throws: Nothing." clause.
+
+       
      
+   
+
+
+
+
      
+
      878. forward_list preconditions
      
+
      Section: 23.2.3 [forwardlist] Status: New
+ Submitter: Martin Sebor Date: 2008-08-23
      
+
      View all issues with New status.
      
+
      Discussion:
      
+       
      
+
+forward_list member functions that take
+a forward_list::iterator (denoted position in the
+function signatures) argument have the following precondition:
+
+       
      
+       
      
+
+Requires: position is dereferenceable or equal
+to before_begin().
+
+       
      
+       
      
+
+I believe what's actually intended is this:
+
+       
      
+       
      
+
+Requires: position is in the range
+[before_begin(), end()).
+
+       
      
+       
      
+
+That is, when it's dereferenceable, position must point
+into *this, not just any forward_list object.
+
+       
      
+   
+   
      Proposed resolution:
      
+       
      
+
+Change the Requires clause as follows:
+
+       
      
+       
      
+
+Requires: position is in the range
+[before_begin(), end()) dereferenceable
+or equal to before_begin().
+
+       
      
+   
+
+
 
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html
index 68bca503aa2b..a056c3ee2499 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}
 
    2. Added the following NAD issues: 790, 791, 796, 797, 799.
      3. 
 
    3. Added the following New issues: 788, 794, 802, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813.
      4. 
 
    4. Added the following Open issues: 793, 800, 801, 803.
      5. 
-
    5. Added the following Ready issues: 789, 792, 798.
      6. 
+
    6. Added the following Ready issues: 789, 792, 798.
      7. 
 
    7. Changed the following issues from NAD Future to Dup: 116.
      8. 
 
    8. Changed the following issues from NAD Future to NAD: 188, 323.
      9. 
 
    9. Changed the following issues from New to NAD: 729, 730, 731, 733, 735, 736, 737, 739, 741, 745, 748, 763, 764, 773, 784.
      10. 
@@ -85,13 +148,13 @@ del {background-color:#FFA0A0}
 
    10. Changed the following issues from Open to NAD Editorial: 529, 626.
      11. 
 
    11. Changed the following issues from Review to NAD Editorial: 645, 684.
      12. 
 
    12. Changed the following issues from NAD Future to Open: 128, 180, 190.
      13. 
-
    13. Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
      14. 
+
    14. Changed the following issues from New to Open: 617, 718, 719, 720, 724, 732, 734, 742, 747, 750, 753, 756, 760, 762, 767, 774.
      15. 
 
    15. Changed the following issues from Ready to Open: 675, 676, 688.
      16. 
-
    16. Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
      17. 
+
    17. Changed the following issues from New to Pending NAD Editorial: 709, 717, 725, 738, 754, 757.
      18. 
 
    18. Changed the following issues from Open to Pending NAD Editorial: 424, 557, 625.
      19. 
-
    19. 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.
      20. 
-
    20. Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
      21. 
-
    21. Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
      22. 
+
    22. 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.
      23. 
+
    23. Changed the following issues from Open to Ready: 387, 471, 550, 612, 629, 673.
      24. 
+
    24. Changed the following issues from Review to Ready: 518, 574, 596, 618, 638, 672, 685.
      25. 
 
    25. Changed the following issues from New to Review: 711, 728, 771, 776.
      26. 
 
    26. Changed the following issues from Open to Review: 539.
      27. 
 
    27. 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.
      28. 
@@ -108,7 +171,7 @@ del {background-color:#FFA0A0}
 
    28. 787 issues total, up by 23.
      29.
    29. Details:
    30. Details:
      31. @@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
    31. 754 issues total, up by 31.
    32. Details:
    33. Details:
      34. @@ -187,10 +250,10 @@ del {background-color:#FFA0A0}
    34. Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
    35. Changed the following issues from New to Open: 579, 631, 680.
    36. Changed the following issues from Pending WP to Open: 258.
      37. -
    37. Changed the following issues from Ready to Pending WP: 644.
      38. +
    38. Changed the following issues from Ready to Pending WP: 644.
    39. Changed the following issues from New to Ready: 577, 660.
    40. Changed the following issues from Open to Ready: 488.
      41. -
    41. Changed the following issues from Open to Review: 518.
      42. +
    42. Changed the following issues from Open to Review: 518.
    43. Changed the following issues from Ready to TRDec: 604.
    44. Changed the following issues from DR to WP: 453.
    45. Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
      46. @@ -206,7 +269,7 @@ del {background-color:#FFA0A0}
    46. 696 issues total, up by 20.
    47. Details:
    48. Details:
    49. 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 ==
@@ -9229,6 +9288,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
@@ -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:
        
@@ -11541,63 +11670,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
@@ -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]):
 
        
 
 
        
@@ -12658,12 +12730,108 @@ 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:
        @@ -12831,6 +13000,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 @@ -12948,6 +13384,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 @@ -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 013350328849..5951a9821e2e 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.
    50. Details:
    51. Details:
      52. @@ -141,16 +204,16 @@ del {background-color:#FFA0A0}
    52. 754 issues total, up by 31.
    53. Details:
    54. Details:
      55. @@ -187,10 +250,10 @@ del {background-color:#FFA0A0}
    55. Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
    56. Changed the following issues from New to Open: 579, 631, 680.
    57. Changed the following issues from Pending WP to Open: 258.
      58. -
    58. Changed the following issues from Ready to Pending WP: 644.
      59. +
    59. Changed the following issues from Ready to Pending WP: 644.
    60. Changed the following issues from New to Ready: 577, 660.
    61. Changed the following issues from Open to Ready: 488.
      62. -
    62. Changed the following issues from Open to Review: 518.
      63. +
    63. Changed the following issues from Open to Review: 518.
    64. Changed the following issues from Ready to TRDec: 604.
    65. Changed the following issues from DR to WP: 453.
    66. Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
      67. @@ -206,7 +269,7 @@ del {background-color:#FFA0A0}
    67. 696 issues total, up by 20.
    68. Details:
    69. Details:
    70. 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. @@ -4092,7 +4155,7 @@ for *r++ from T to "convertible to T".

        103. set::iterator is required to be modifiable, but this allows modification of keys

        -

        Section: 23.1.2 [associative.reqmts] Status: WP +

        Section: 23.1.4 [associative.reqmts] Status: WP Submitter: AFNOR Date: 1998-10-07

        View all other issues in [associative.reqmts].

        View all issues with WP status.

        @@ -4124,7 +4187,7 @@ goes in line with trusting user knows what he is doing.

        Other Options Evaluated:

        -

        Option A.   In 23.1.2 [associative.reqmts], paragraph 2, after +

        Option A.   In 23.1.4 [associative.reqmts], paragraph 2, after first sentence, and before "In addition,...", add one line:

        @@ -4132,7 +4195,7 @@ first sentence, and before "In addition,...", add one line:

        Modification of keys shall not change their strict weak ordering.

        -

        Option B. Add three new sentences to 23.1.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.
@@ -20652,6 +20710,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
@@ -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:
 
      
 
      
 
      
@@ -21740,6 +21867,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
@@ -22375,9 +22640,61 @@ 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.
      
@@ -22866,6 +23183,296 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
 
 
 
+
      
+
      595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified
      
+
      Section: 26.3.7 [complex.value.ops] Status: WP
+ Submitter: Stefan Große Pawig Date: 2006-09-24
      
+
      View all other issues in [complex.value.ops].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+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 -----
+
      
+
+
      
+The current C++0X draft document (n2009.pdf) adopted this
+definition in chapter 26.3.1 (under the comment // 26.3.7 values)
+and 26.3.7/7.
+
      
+
      
+But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
+n1124), the referenced subclause reads
+
      
+
+
      ----- 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 -----
+
      
+
+
      
+Note that the return type of the cabs*() functions is not a complex
+type.  Thus, they are equivalent to the already well established
+  template<class T> T abs(const complex<T>& x);
+(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
+document n2009.pdf).
+
      
+
      
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
+
      
+
+Possible Resolutions
+
+
      
+This depends on the intention behind the introduction of fabs().
+
      
+
      
+If the intention was to provide a /complex/ valued function that
+calculates the magnitude of its argument, this should be
+explicitly specified.  In TR1, the categorization under "C
+compatibility" is definitely wrong, since C99 does not provide
+such a complex valued function.
+
      
+
      
+Also, it remains questionable if such a complex valued function
+is really needed, since complex<T> supports construction and
+assignment from real valued arguments.  There is no difference
+in observable behaviour between
+
      
+
        complex<double> x, y;
+  y = fabs(x);
+  complex<double> z(fabs(x));
+
      
+
      
+and
+
      
+
        complex<double> x, y;
+  y = abs(x);
+  complex<double> z(abs(x));
+
      
+
      
+If on the other hand the intention was to provide the intended
+functionality of C99, fabs() should be either declared deprecated
+or (for C++0X) removed from the standard, since the functionality
+is already provided by the corresponding overloads of abs().
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Bill believes that abs() is a suitable overload. We should remove fabs().
+
      
+
+
+
      Proposed resolution:
      
+
+
      
+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
@@ -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:
      
@@ -23667,6 +24274,61 @@ component.
      71. +
      +

      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 @@ -23794,9 +24456,66 @@ as this is a dependent type, it should obviously be +

      +

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

      +

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

      +

      View all issues with WP status.

      +

      Discussion:

      +

      +I would respectfully request an issue be opened with the intention to +clarify the wording for size() == 0 for cshift. +

      + + +

      Proposed resolution:

      +

      +Change 26.5.2.7 [valarray.members], paragraph 10: +

      + +
      + +
      valarray<T> cshift(int n) const;
+
      + +
      +

      +This function returns an object of class valarray<T>, of +length size(), each of whose elements I is +(*this)[(I + n ) % size()]. Thus, if element zero is taken as +the leftmost element, a positive value of n shifts the elements +circularly left n places. that is a circular shift of *this. If +element zero is taken as the leftmost element, a non-negative value of +n shifts the elements circularly left n places and a +negative value of n shifts the elements circularly right +-n places. +

      +
      +
      + + + +

      Rationale:

      +

      +We do not believe that there is any real ambiguity about what happens +when size() == 0, but we do believe that spelling this out as a C++ +expression causes more trouble that it solves. The expression is +certainly wrong when n < 0, since the sign of % with negative arguments +is implementation defined. +

      + + +

      [ +Kona (2007) Changed proposed wording, added rationale and set to Review. +]

      + + + + +

      619. Longjmp wording problem

      -

      Section: 18.8 [support.runtime] Status: WP +

      Section: 18.9 [support.runtime] Status: WP Submitter: Lawrence Crowl Date: 2007-01-12

      View all issues with WP status.

      Discussion:

      @@ -23804,7 +24523,7 @@ as this is a dependent type, it should obviously be The wording for longjmp is confusing.

      -18.8 [support.runtime] -4- Other runtime support +18.9 [support.runtime] -4- Other runtime support

      The function signature longjmp(jmp_buf jbuf, int val) has more restricted @@ -23830,7 +24549,7 @@ caught only at the point of the setjmp, the behavior is undefined." In general, accept Bill Gibbons' recommendation, but add "call" to indicate that the undefined behavior comes from the dynamic call, not from its presence in the code. -In 18.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]:

      @@ -24470,6 +25190,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 @@ -24585,45 +25401,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 @@ -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;
@@ -25283,9 +26060,510 @@ four characters long, usually three letters and a space.
 
 
 
+
      
+
      672. Swappable requirements need updating
      
+
      Section: 20.1.1 [utility.arg.requirements] Status: WP
+ Submitter: Howard Hinnant Date: 2007-05-04
      
+
      View other active issues in [utility.arg.requirements].
      
+
      View all other issues in [utility.arg.requirements].
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+The current Swappable is:
+
      
+
+
      
+
+
+
+
+
+
      Table 37: Swappable requirements [swappable]
      expressionreturn typepost-condition
      swap(s,t)voidt has the value originally held by u, and u has the value originally 
+held by t
      
+
      
+The Swappable requirement is met by satisfying one or more of the following conditions:
+
      
+
        
+
      • 
+T is Swappable if T satisfies the CopyConstructible requirements (Table 34) 
+and the CopyAssignable requirements (Table 36);
+
        • 
+
      • 
+T is Swappable if a namespace scope function named swap exists in the same 
+namespace as the definition of T, such that the expression swap(t,u) is valid 
+and has the semantics described in this table.
+
        • 
+
      
+
      
+
      
+
+
      
+With the passage of rvalue reference into the language, Swappable needs to be updated to
+require only MoveConstructible and MoveAssignable.  This is a minimum.
+
      
+
+
      
+Additionally we may want to support proxy references such that the following code is acceptable:
+
      
+
+
      namespace Mine {
+
+template <class T>
+struct proxy {...};
+
+template <class T>
+struct proxied_iterator
+{
+   typedef T value_type;
+   typedef proxy<T> reference;
+   reference operator*() const;
+   ...
+};
+
+struct A
+{
+   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+   void swap(A&);
+   ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+}  // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
+
      
+
+
      
+I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class
+itself.  We do not need to anything in terms of implementation except not block their way with overly
+constrained concepts.  That is, the Swappable concept should be expanded to allow swapping
+between two different types for the case that one is binding to a user-defined swap.
+
      
+
+
+
+
      Proposed resolution:
      
+
+
      
+Change 20.1.1 [utility.arg.requirements]:
+
      
+
+
      
+
+
      
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+tables, T is a type to be supplied by a C++ program
+instantiating a template; a, b, and c are
+values of type const T; s and t are modifiable
+lvalues of type T; u is a value of type (possibly
+const) T; and rv is a non-const
+rvalue of type T.
+
      
+
+
+
+
+
+
+
+
      Table 37: Swappable requirements [swappable]
      expressionreturn typepost-condition
      swap(s,t)voidt has the value originally
+held by u, and
+u has the value originally held
+by t
      
+
      
+The Swappable requirement is met by satisfying one or more of the following conditions:
+
      
+
        
+
      • 
+T is Swappable if T satisfies the
+CopyConstructible MoveConstructible
+requirements (Table 34 33) and the CopyAssignable MoveAssignable
+requirements (Table 36 35);
+
        • 
+
      • 
+T is Swappable if a namespace scope function named
+swap exists in the same namespace as the definition of
+T, such that the expression
+swap(t,u) is valid and has the
+semantics described in this table.
+
        • 
+
      
+
      
+
      
+
+
+
+
      [
+Kona (2007): We like the change to the Swappable requirements to use
+move semantics. The issue relating to the support of proxies is
+separable from the one relating to move semantics, and it's bigger than
+just swap. We'd like to address only the move semantics changes under
+this issue, and open a separated issue (742) to handle proxies. Also, there
+may be a third issue, in that the current definition of Swappable does
+not permit rvalues to be operands to a swap operation, and Howard's
+proposed resolution would allow the right-most operand to be an rvalue,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
+]
      
+
+
+
+
+
+
      
+
      673. unique_ptr update
      
+
      Section: 20.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:
      
+
      
+Since the publication of
+N1856
+there have been a few small but significant advances which should be included into
+unique_ptr.  There exists a
+example implmenation
+for all of these changes.
+
      
+
+
        
+
+
      • 
+
        
+Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>),
+unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void>
+even if it is never used.  For example see
+LWG 541 for how this accidently
+happened to auto_ptr.  I believe the most robust way to protect unique_ptr against this
+type of failure is to augment the return type of unique_ptr<T>:operator*() with
+add_lvalue_reference<T>::type.  This means that given an instantiated unique_ptr<void>
+the act of dereferencing it will simply return void instead of causing a compile time failure.
+This is simpler than creating a unique_ptr<void> specialization which isn't robust in the
+face of cv-qualified void types.
+
        
+
+
        
+This resolution also supports instantiations such as unique_ptr<void, free_deleter>
+which could be very useful to the client.
+
        
+
+
        • 
+
+
      • 
+
        
+Efforts have been made to better support containers and smart pointers in shared
+memory contexts.  One of the key hurdles in such support is not assuming that a
+pointer type is actually a T*.  This can easily be accomplished
+for unique_ptr by having the deleter define the pointer type:
+D::pointer.  Furthermore this type can easily be defaulted to
+T* should the deleter D choose not to define a pointer
+type (example implementation
+here).
+This change has no run time overhead.  It has no interface overhead on
+authors of custom delter types.  It simply allows (but not requires)
+authors of custom deleter types to define a smart pointer for the
+storage type of unique_ptr if they find such functionality
+useful.  std::default_delete is an example of a deleter which
+defaults pointer to T* by simply ignoring this issue
+and not including a pointer typedef.
+
        
+
        • 
+
+
      • 
+
        
+When the deleter type is a function pointer then it is unsafe to construct
+a unique_ptr without specifying the function pointer in the constructor.
+This case is easy to check for with a static_assert assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
+
        
+
+
        unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
+
        
+
+
        • 
+
+
      
+
+
      [
+Kona (2007): We don't like the solution given to the first bullet in
+light of concepts. The second bullet solves the problem of supporting
+fancy pointers for one library component only. The full LWG needs to
+decide whether to solve the problem of supporting fancy pointers
+piecemeal, or whether a paper addressing the whole library is needed. We
+think that the third bullet is correct.
+]
      
+
+
+
      [
+Post Kona: Howard adds example user code related to the first bullet:
+]
      
+
+
+
      
+
      void legacy_code(void*, std::size_t);
+
+void foo(std::size_t N)
+{
+    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
+    legacy_code(ptr.get(), N);
+}   // unique_ptr used for exception safety purposes
+
      
+
      
+
+
      
+I.e. unique_ptr<void> is a useful tool that we don't want
+to disable with concepts.  The only part of unique_ptr<void> we
+want to disable (with concepts or by other means) are the two member functions:
+
      
+
+
      T& operator*() const;
+T* operator->() const;
+
      
+
+
+
+
      Proposed resolution:
      
+
+
      [
+I am grateful for the generous aid of Peter Dimov and Ion Gaztańaga in helping formulate and review
+the proposed resolutions below.
+]
      
+
+
+
        
+
      • 
+
+
        
+Change 20.7.11.2 [unique.ptr.single]:
+
        
+
+
        template <class T, class D = default_delete<T>> class unique_ptr {
+   ...
+   T& typename add_lvalue_reference<T>::type operator*() const;
+   ...
+};
+
        
+
+
        
+Change 20.7.11.2.4 [unique.ptr.single.observers]:
+
        
+
+
        T& typename add_lvalue_reference<T>::type operator*() const;
+
        
+
+
        • 
+
+
      • 
+
        
+Change 20.7.11.2 [unique.ptr.single]:
+
        
+
+
        template <class T, class D = default_delete<T>> class unique_ptr {
+public:
+  typedef implementation (see description below) pointer;
+   ...
+   explicit unique_ptr(T* pointer p);
+   ...
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   unique_ptr(T* pointer p, implementation defined (see description below) d);
+   ...
+   T* pointer operator->() const;
+   T* pointer get() const;
+   ...
+   T* pointer release();
+   void reset(T* pointer p = 0 pointer());
+};
+
        
+
+
        
+
+-3- If the type remove_reference<D>::type::pointer
+exists, then unique_ptr<T, D>::pointer is a typedef to
+remove_reference<D>::type::pointer.  Otherwise
+unique_ptr<T, D>::pointer is a typedef to T*.
+The type unique_ptr<T, D>::pointer shall be CopyConstructible
+and CopyAssignable.
+
+
        
+
+
        
+Change 20.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);
+...
+
        
+
+
        
+-23- Requires: If D is not a reference type,
+construction of the deleter D from an rvalue of type E
+must shall be well formed and not throw an exception. If D is a
+reference type, then E must shall be the same type as D
+(diagnostic required). U* unique_ptr<U,E>::pointer
+must shall be implicitly convertible to T*
+pointer.
+
        
+
+
        
+-25- Postconditions: get() == value u.get() had before
+the construction, modulo any required offset adjustments resulting from
+the cast from U*
+unique_ptr<U,E>::pointer to T*
+pointer. get_deleter() returns a reference to the
+internally stored deleter which was constructed from
+u.get_deleter().
+
        
+
+
        
+Change 20.7.11.2.3 [unique.ptr.single.asgn]:
+
        
+
+
        
+
        
+-8- Requires: Assignment of the deleter D from an rvalue
+D must shall not throw an exception. U*
+unique_ptr<U,E>::pointer must shall be implicitly
+convertible to T* pointer.
+
        
+
        
+
+
        
+Change 20.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());
        
+
        
+
+
        
+Change 20.7.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.7.11.3.1 [unique.ptr.runtime.ctor]:
+
        
+
+
        
+
        unique_ptr(T* pointer p);
+unique_ptr(T* pointer p, implementation defined d);
+unique_ptr(T* pointer p, implementation defined d);
+
        
+
+
        
+These constructors behave the same as in the primary template except
+that they do not accept pointer types which are convertible to
+T* pointer. [Note: One
+implementation technique is to create private templated overloads of
+these members. -- end note]
+
        
+
        
+
+
        
+Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+
        
+
+
        
+
        void reset(T* pointer p = 0 pointer());
+
        
+
+
        
+-1- Requires: Does not accept pointer types which are convertible
+to T* pointer (diagnostic
+required). [Note: One implementation technique is to create a private
+templated overload. -- end note]
+
        
+
        
+
+
        • 
+
+
      • 
+
+
        
+Change 20.7.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).
+
        
+
        
+
        
+
+
        • 
+
+
      
+
+
+
+
+
+
 
      
 
      674. shared_ptr interface changes for consistency with N1856
      
-
      Section: 20.6.12.2 [util.smartptr.shared] Status: WP
+
      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].
      
@@ -25301,7 +26579,7 @@ and to interoperate with unique_ptr as it does with auto_ptr.
 
      Proposed resolution:
      
 
 
      
-Change 20.6.12.2 [util.smartptr.shared] as follows:
+Change 20.7.12.2 [util.smartptr.shared] as follows:
 
      
 
 
      
@@ -25315,7 +26593,7 @@ template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>
 
      
 
 
      
-Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
+Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
 
      
 
 
      
@@ -25323,7 +26601,7 @@ Change 20.6.12.2.1 [util.smartptr.shared.const] as follows:
 
      
 
 
      
-Add to 20.6.12.2.1 [util.smartptr.shared.const]:
+Add to 20.7.12.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
@@ -25344,7 +26622,7 @@ Add to 20.6.12.2.1 [util.smartptr.shared.const]:
 
      
 
 
      
-Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
+Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
 
      
 
 
      
@@ -25352,7 +26630,7 @@ Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows:
 
      
 
 
      
-Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
+Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
 
      
 
 
      
@@ -25372,7 +26650,7 @@ Add to 20.6.12.2.3 [util.smartptr.shared.assign]:
 
 
 
      [
-Kona (2007): We may need to open an issue (743) to deal with the question of
+Kona (2007): We may need to open an issue (743) to deal with the question of
 whether shared_ptr needs an rvalue swap.
 ]
      
 
@@ -25849,9 +27127,118 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      685. reverse_iterator/move_iterator difference has invalid signatures
      
+
      Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: WP
+ Submitter: Bo Persson Date: 2007-06-10
      
+
      View all issues with WP status.
      
+
      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.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] Status: WP
+
      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.
      
@@ -25880,7 +27267,7 @@ overload resolution when the pointer types are compatible.
 
 
      Proposed resolution:
      
 
      
-In 20.6.12.2.1 [util.smartptr.shared.const], change:
+In 20.7.12.2.1 [util.smartptr.shared.const], change:
 
      
 
 
      
@@ -25891,7 +27278,7 @@ to T*.
 
      
 
 
      
-In 20.6.12.3.1 [util.smartptr.weak.const], change:
+In 20.7.12.3.1 [util.smartptr.weak.const], change:
 
      
 
 
      
@@ -25917,7 +27304,7 @@ overload resolution unless Y* shall be
 
 
      
 
      689. reference_wrapper constructor overly constrained
      
-
      Section: 20.5.5.1 [refwrap.const] Status: WP
+
      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.
      
@@ -26297,12 +27684,14 @@ 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
+
      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.4.7 [meta.trans.other].
+The current working draft has a type-trait decay in 20.5.7 [meta.trans.other].
 
      
 
 
      
@@ -26316,7 +27705,7 @@ cv-qualification, as pass-by-value does.
 
 
      Proposed resolution:
      
 
      
-In 20.4.7 [meta.trans.other] change the last sentence:
+In 20.5.7 [meta.trans.other] change the last sentence:
 
      
 
 
      
@@ -26324,7 +27713,7 @@ Otherwise the  member typedef type equals remove_cv<U
 
      
 
 
      
-In 20.3.1.3 [tuple.creation]/1 change:
+In 20.4.1.3 [tuple.creation]/1 change:
 
      
 
 
      
@@ -26354,7 +27743,7 @@ is X& if Ui equals
 
      Discussion:
      
 
      
 The current draft has make_pair() in 20.2.3 [pairs]/16
-and make_tuple() in 20.3.1.3 [tuple.creation].
+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
@@ -26394,6 +27783,146 @@ Then change the 20.2.3 [pairs]/17 to:
 
 
 
+
      
+
      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
@@ -26438,4 +27967,1812 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a
 
 
 
+
      
+
      715. minmax_element complexity is too lax
      
+
      Section: 25.3.7 [alg.min.max] Status: WP
+ Submitter: Matt Austern Date: 2007-08-30
      
+
      View all other issues in [alg.min.max].
      
+
      View all issues with WP status.
      
+
      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>&);
+
      
+
+
      
+Update 23.2.1.6 [array.tuple] Tuple interface to class template array
+
      
+
      tuple_element<size_t I, array<T, N> >::type
+
      
+
      
+3 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
      
+
      
+4 Value: The type T.
+
      
+
      template <intsize_t I, class T, size_t N> T& get(array<T, N>& a);
+
      
+
      
+5 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
      
+
      
+Returns: A reference to the Ith element of a, where indexing is zero-based.
+
      
+
      
+Throws: Nothing.
+
      
+
      template <intsize_t I, class T, size_t N> const T& get(const array<T, N>& a);
+
      
+
      
+6 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds.
+
      
+
      
+7 Returns: A const reference to the Ith element of a, where indexing is zero-based.
+
      
+
      
+Throws: Nothing.
+
      
+
+
+
      [
+Bellevue: Note also that the phrase "The program is ill-formed if I is
+out of bounds" in the requires clauses are probably unnecessary, and
+could be removed at the editor's discretion. Also std:: qualification
+for pair is also unnecessary.
+]
      
+
+
+
+
+
      
+
      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 load functions are defined as
+
      
+
+
      C atomic_load(volatile A* object);
+C atomic_load_explicit(volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) volatile;
+
      
+
+
      
+which prevents their use in const contexts.
+
      
+
+
      [
+post Bellevue Peter adds:
+]
      
+
+
+
      
+
      
+Issue 777 suggests making atomic_load operate on const objects. There is a
+subtle point here. Atomic loads do not generally write to the object, except
+potentially for the memory_order_seq_cst constraint. Depending on the
+architecture, a dummy write with the same value may be required to be issued
+by the atomic load to maintain sequential consistency. This, in turn, may
+make the following code:
+
      
+
+
      const atomic_int x{};
+
+int main()
+{
+  x.load();
+}
+
      
+
+
      
+dump core under a straightforward implementation that puts const objects in
+a read-only section.
+
      
+
      
+There are ways to sidestep the problem, but it needs to be considered.
+
      
+
      
+The tradeoff is between making the data member of the atomic types
+mutable and requiring the user to explicitly mark atomic members as
+mutable, as is already the case with mutexes.
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add the const qualifier to *object and *this.
+
      
+
+
      C atomic_load(const volatile A* object);
+C atomic_load_explicit(const volatile A* object, memory_order);
+C A::load(memory_order order = memory_order_seq_cst) const volatile;
+
      
+
+
+
+
+
+
+
      
+
      778. std::bitset does not have any constructor taking a string literal
      
+
      Section: 23.3.5.1 [bitset.cons] Status: 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:
      
+
      
+A small issue with std::bitset: it does not have any constructor
+taking a string literal, which is clumsy and looks like an oversigt when
+we tried to enable uniform use of string and const char* in the library.
+
      
+
+
      
+Suggestion: Add
+
      
+
+
      explicit bitset( const char* str );
+
      
+
+
      
+to std::bitset.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Add to synopsis in 23.3.5 [template.bitset]
+
      
+
+
      explicit bitset( const char* str );
+
      
+
+
      
+Add to synopsis in 23.3.5.1 [bitset.cons]
+
      
+
+
      explicit bitset( const char* str );
+
      
+
      
+Effects: Constructs a bitset as if bitset(string(str)).
+
      
+
      
+
+
+
+
+
+
+
      
+
      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:
      
+
      
+A comparision of the N2461 header <complex> synopsis ([complex.synopsis])
+with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
+some complex functions that are missing in C++. These are:
+
      
+
+
        
+
      1. 
+7.3.9.4: (required elements of the C99 library)
        
+The cproj functions
+
        2. 
+
      2. 
+7.26.1: (optional elements of the C99 library)
        
+
        cerf    cerfc    cexp2
+cexpm1  clog10   clog1p
+clog2   clgamma  ctgamma
+
        
+
        3. 
+
      
+
+
      
+I propose that at least the required cproj overloads are provided as equivalent
+C++ functions. This addition is easy to do in one sentence (delegation to C99
+function).
+
      
+
+
      
+Please note also that the current entry polar
+in 26.3.9 [cmplx.over]/1
+should be removed from the mentioned overload list. It does not make sense to require that a
+function already expecting scalar arguments
+should cast these arguments into corresponding
+complex<T> arguments, which are not accepted by
+this function.
+
      
+
+
+
      Proposed resolution:
      
+
      
+In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs:
+
      
+
+
      template<class T> complex<T> conj(const complex<T>&);
+template<class T> complex<T> proj(const complex<T>&);
+template<class T> complex<T> fabs(const complex<T>&);
+
      
+
+
      
+In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add:
+
      
+
+
      
+
      template<class T> complex<T> proj(const complex<T>& x);
+
      
+
      
+
+Effects: Behaves the same as C99 function cproj, defined in
+subclause 7.3.9.4."
+
      
+
      
+
+
      
+In 26.3.9 [cmplx.over]/1, add one further entry proj to
+the overload list.
+
      
+
+
      
+
      
+The following function templates shall have additional overloads:
+
      
+
      arg           norm 
+conj          polar proj
+imag          real
+
      
+
      
+
+
+
+
+
+
+
      
+
      782. Extended seed_seq constructor is useless
      
+
      Section: 26.4.7.1 [rand.util.seedseq] Status: 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:
      
+
      
+Part of the resolution of n2423, issue 8 was the proposal to
+extend the seed_seq constructor accepting an input range
+as follows (which is now part of N2461):
+
      
+
+
      template<class InputIterator,
+size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+seed_seq(InputIterator begin, InputIterator end);
+
      
+
+
      
+First, the expression iterator_traits<InputIterator>::value_type
+is invalid due to missing typename keyword, which is easy to
+fix.
+
      
+
+
      
+Second (and worse), while the language now supports default
+template arguments of function templates, this customization
+point via the second size_t template parameter is of no advantage,
+because u can never be deduced, and worse - because it is a
+constructor function template - it can also never be explicitly
+provided (14.8.1 [temp.arg.explicit]/7).
+
      
+
+
      
+The question arises, which advantages result from a compile-time
+knowledge of u versus a run time knowledge? If run time knowledge
+suffices, this parameter should be provided as normal function
+default argument [Resolution marked (A)], if compile-time knowledge
+is important, this could be done via a tagging template or more
+user-friendly via a standardized helper generator function
+(make_seed_seq), which allows this [Resolution marked (B)].
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+
      
+Fermilab does not have a strong opinion. Would prefer to go with
+solution A. Bill agrees that solution A is a lot simpler and does the
+job.
+
      
+
      
+Proposed Resolution: Accept Solution A.
+
      
+
      
+
+
      
+Issue 803 claims to make this issue moot.
+
      
+
+
+
+
      Proposed resolution:
      
+
        
+
      1. 
+
        
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace:
+
        
+
+
        class seed_seq 
+{ 
+public:
+   ...
+   template<class InputIterator,
+      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+          seed_seq(InputIterator begin, InputIterator end,
+          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);
+   ...
+};
+
        
+
+
        
+and do a similar replacement in the member description between
+p.3 and p.4.
+
        
+
        2. 
+
+
      2. 
+
        
+In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the
+member description between p.3 and p.4 replace:
+
        
+
+
        template<class InputIterator,
+  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
+	  seed_seq(InputIterator begin, InputIterator end);
+template<class InputIterator, size_t u>
+seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
+
        
+
+
        
+In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the
+class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately
+after the class seed_seq definition add:
+
        
+
+
        template<size_t u, class InputIterator>
+  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
        
+
+
        
+In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
+
        
+
+
        
+
        
+The first constructor behaves as if it would provide an
+integral constant expression u of type size_t of value
+numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits.
+
        
+
        
+The second constructor uses an implementation-defined mechanism
+to provide an integral constant expression u of type size_t and
+is called by the function make_seed_seq.
+
        
+
        
+
+
        
+In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
+
        
+
+
        
+
        template<size_t u, class InputIterator>
+   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
+
        
+
        
+
        
+where u is used to construct an object s of implementation-defined type.
+
        
+
        
+Returns: seed_seq(begin, end, s);
+
        
+
        
+
        
+
+
        3. 
+
      
+
+
+
+
+
+
+
      
+
      783. thread::id reuse
      
+
      Section: 30.2.1.1 [thread.thread.id] Status: WP
+ Submitter: Hans Boehm Date: 2008-02-01
      
+
      View all issues with WP status.
      
+
      Discussion:
      
+
      
+The current working paper 
+(N2497,
+integrated just before Bellevue) is
+not completely clear whether a given thread::id value may be reused once
+a thread has exited and has been joined or detached.  Posix allows
+thread ids (pthread_t values) to be reused in this case.  Although it is
+not completely clear whether this originally was the right decision, it
+is clearly the established practice, and we believe it was always the
+intent of the C++ threads API to follow Posix and allow this.  Howard
+Hinnant's example implementation implicitly relies on allowing reuse
+of ids, since it uses Posix thread ids directly.
+
      
+
+
      
+It is important to be clear on this point, since it the reuse of thread
+ids often requires extra care in client code, which would not be
+necessary if thread ids were unique across all time.  For example, a
+hash table indexed by thread id may have to be careful not to associate
+data values from an old thread with a new one that happens to reuse the
+id.  Simply removing the old entry after joining a thread may not be
+sufficient, if it creates a visible window between the join and removal
+during which a new thread with the same id could have been created and
+added to the table.
+
      
+
+
      [
+post Bellevue Peter adds:
+]
      
+
+
+
      
+
      
+There is a real issue with thread::id reuse, but I urge the LWG to
+reconsider fixing this by disallowing reuse, rather than explicitly allowing
+it. Dealing with thread id reuse is an incredibly painful exercise that
+would just force the world to reimplement a non-conflicting thread::id over
+and over.
+
      
+
      
+In addition, it would be nice if a thread::id could be manipulated
+atomically in a lock-free manner, as motivated by the recursive lock
+example:
+
      
+
+
      
+http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html
+
      
+
      
+
+
+
+
      Proposed resolution:
      
+
      
+Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
+
      
+
+
      
+
      
+An object of type thread::id provides
+a unique identifier for each thread of execution
+and a single distinct value for all thread objects
+that do not represent a thread of execution ([thread.threads.class]).
+Each thread of execution has a thread::id
+that is not equal to the thread::id
+of other threads of execution
+and that is not equal to
+the thread::id of std::thread objects
+that do not represent threads of execution.
+The library may reuse the value of a thread::id of a
+terminated thread that can no longer be joined.
+
      
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+xor_combine_engine(result_type) should be explicit. (Obvious oversight.)
+
      
+
+
      [
+Bellevue:
+]
      
+
+
+
      
+Non-controversial. Bill is right, but Fermilab believes that this is
+easy to use badly and hard to use right, and so it should be removed
+entirely. Got into TR1 by well defined route, do we have permission to
+remove stuff? Should probably check with Jens, as it is believed he is
+the originator. Broad consensus that this is not a robust engine
+adapter.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
+
      
+
      
+Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine.
+
      
+
+
+
+
+
+
      
+
      792. piecewise_constant_distribution is undefined for a range with just one endpoint
      
+
      Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: 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:
      
+
      
+piecewise_constant_distribution is undefined for a range with just one
+endpoint. (Probably should be the same as an empty range.)
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
+
      
+
+
      
+b) If firstB == lastB or the sequence w has the length zero,
+
      
+
+
+
+
+
+
      
+
      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:
      
+
      
+N2521
+and its earlier predecessors have moved the old binders from
+[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
+of the template parameter names (Operation -> Fn). During this
+renaming process the protected data member op was also renamed to
+fn, which seems as an unnecessary interface breakage to me - even if
+this user access point is probably rarely used.
+
      
+
+
+
      Proposed resolution:
      
+
      
+Change D.8.1 [depr.lib.binder.1st]:
+
      
+
+
      
+
      template <class Fn> 
+class binder1st 
+  : public unary_function<typename Fn::second_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::first_argument_type value; 
+public: 
+  binder1st(const Fn& x, 
+            const typename Fn::first_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::second_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::second_argument_type& x) const; 
+};
+
      
+
+
      
+
      
+-1- The constructor initializes fn op with x and value with y.
+
      
+
      
+-2- operator() returns fnop(value,x).
+
      
+
      
+
      
+
+
      
+Change D.8.3 [depr.lib.binder.2nd]:
+
      
+
+
      
+
      template <class Fn> 
+class binder2nd
+  : public unary_function<typename Fn::first_argument_type, 
+                          typename Fn::result_type> { 
+protected: 
+  Fn fn op; 
+  typename Fn::second_argument_type value; 
+public: 
+  binder2nd(const Fn& x, 
+            const typename Fn::second_argument_type& y); 
+  typename Fn::result_type 
+    operator()(const typename Fn::first_argument_type& x) const; 
+  typename Fn::result_type 
+    operator()(typename Fn::first_argument_type& x) const; 
+};
+
      
+
+
      
+
      
+-1- The constructor initializes fn op with x and value with y.
+
      
+
      
+-2- operator() returns fnop(value,x).
+
      
+
      
+
      
+
+
+
+
+
+
 
\ No newline at end of file
diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index 8cca6f398429..b64b969590f2 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.