From 6f8bfa91fcdb64cbafd8d8df9ef03939591c0270 Mon Sep 17 00:00:00 2001
From: paolo Reference ISO/IEC IS 14882:1998(E) Reference ISO/IEC IS 14882:2003(E) Also see: The purpose of this document is to record the status of issues
which have come before the Library Working Group (LWG) of the ANSI
(J16) and ISO (WG21) C++ Standards Committee. Issues represent
- potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
- are not to be used to request new features.
-
Doc. no.
-N2727=08-0237
+N2894=09-0084
Date:
-2008-08-24
+2009-06-21
Project:
@@ -29,9 +29,9 @@ del {background-color:#FFA0A0}
Howard Hinnant <howard.hinnant@gmail.com>
C++ Standard Library Active Issues List (Revision R59)
+C++ Standard Library Active Issues List (Revision R65)
-
This document contains only library issues which are actively being considered by the Library Working Group. That is, issues which have a @@ -58,11 +58,6 @@ del {background-color:#FFA0A0} official Defect Report status, other issues will be disposed of in other ways. See Issue Status.
-This document is in an experimental format designed for both - viewing via a world-wide web browser and hard-copy printing. It - is available as an HTML file for browsing or PDF file for - printing.
-Prior to Revision 14, library issues lists existed in two slightly different versions; a Committee Version and a Public Version. Beginning with Revision 14 the two versions were combined @@ -78,24 +73,160 @@ del {background-color:#FFA0A0}
For the most current official version of this document see http://www.open-std.org/jtc1/sc22/wg21/. Requests for further information about this document should include - the document number above, reference ISO/IEC 14882:1998(E), and be + the document number above, reference ISO/IEC 14882:2003(E), and be submitted to Information Technology Industry Council (ITI), 1250 Eye Street NW, Washington, DC 20005.
Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the comp.std.c++ FAQ. - Public discussion of C++ Standard related issues occurs on news:comp.std.c++.
-For committee members, files available on the committee's private - web site include the HTML version of the Standard itself. HTML - hyperlinks from this issues list to those files will only work for - committee members who have downloaded them into the same disk - directory as the issues list files.
Ready - The LWG has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the @@ -775,11 +900,15 @@ format, TC - (Technical Corrigenda) - The full +
TC1 - (Technical Corrigenda 1) - The full WG21 committee has voted to accept the Defect Report's Proposed Resolution as a Technical Corrigenda. Action on this issue is thus complete and no further action is possible under ISO rules.
+CD1 - (Committee Draft 2008) - The full + WG21 committee has voted to accept the Defect Report's Proposed + Resolution into the Fall 2008 Committee Draft.
+TRDec - (Decimal TR defect) - The
LWG has voted to accept the Defect Report's Proposed
Resolution into the Decimal TR. Action on this issue is thus
@@ -790,6 +919,13 @@ format, Active Issues
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 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
-description to rely on the definition of scanf() (which fails to
-report overflow), and conflicts with the documented behavior of
-traditional and current implementations. Users expect, when reading a character sequence that results in a
-value unrepresentable in the specified type, to have an error
-reported. The standard as written does not permit this. Further comments from Dietmar:
-I don't feel comfortable with the proposed resolution to issue 23: It
-kind of simplifies the issue to much. Here is what is going on:
-
-Currently, the behavior of numeric overflow is rather counter intuitive
-and hard to trace, so I will describe it briefly:
- Further discussion from Redmond: The basic problem is that we've defined our behavior,
-including our error-reporting behavior, in terms of C90. However,
-C90's method of reporting overflow in scanf is not technically an
-"input error". The strto_* functions are more precise. There was general consensus that failbit should be set
-upon overflow. We considered three options based on this: Straw poll: (1) 5; (2) 0; (3) 8. Discussed at Lillehammer. General outline of what we want the
- solution to look like: we want to say that overflow is an error, and
- provide a way to distinguish overflow from other kinds of errors.
- Choose candidate field the same way scanf does, but don't describe
- the rest of the process in terms of format. If a finite input field
- is too large (positive or negative) to be represented as a finite
- value, then set failbit and assign the nearest representable value.
- Bill will provide wording.
-Discussed at Toronto:
-N2327
-is in alignment with the direction we wanted to go with in Lillehammer. Bill
-to work on.
- Proposed resolution:
-Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
-
-Stage 3:
-The numeric value to be stored can be one of:
-
-The resultant numeric value is stored in val.
-
-Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
-
--6- Effects: If
-(str.flags()&ios_base::boolalpha)==0 then input
-proceeds as it would for a long except that if a value is being
-stored into val, the value is determined according to the
-following: If the value to be stored is 0 then false is stored.
-If the value is 1 then true is stored. Otherwise
-
--7- Otherwise target sequences are determined "as if" by calling the
-members falsename() and truename() of the facet
-obtained by use_facet<numpunct<charT>
->(str.getloc()). Successive characters in the range
-[in,end) (see 23.1.1) are obtained and matched
-against corresponding positions in the target sequences only as
-necessary to identify a unique match. The input iterator in is
-compared to end only when necessary to obtain a character. If Section: 23.2.6 [vector] Status: Open
- Submitter: AFNOR Date: 1998-10-07 Section: 23.3.6 [vector] Status: Tentatively NAD Future
+ Submitter: AFNOR Opened: 1998-10-07 Last modified: 2009-05-25 View all other issues in [vector]. View all issues with Open status. Discussion: vector<bool> is not a container as its reference and
pointer types are not references and pointers.
-23. Num_get overflow result
-
-
-
-
-
-
-
-
-
-The result of stage 2 processing can be one of
-The sequence of chars accumulated in stage 2 (the field) is
-converted to a numeric value by the rules of one of the functions declared
-in the header <cstdlib>:
-
-
-A sequence of chars has been accumulated in stage 2 that is
-converted (according to the rules of scanf) to a value of the
-type of val. This value is stored in val and ios_base::goodbit is
-stored in err.
-For a signed integer value, the function strtoll.
-The sequence of chars accumulated in stage 2 would have caused
-scanf to report an input failure. ios_base::failbit is
-assigned to err.
-For an unsigned integer value, the function strtoull.
-
-
-
-
-
-
-
-
-
-
-iter_type do_get(iter_type in, iter_type end, ios_base& str,
- ios_base::iostate& err, bool& val) const;
-
-
-
-err|=ios_base::failbit is performed and no value true is
-stored. and ios_base::failbit is assigned to err.
-and
-only if a target sequence is uniquely matched, val is set to the
-corresponding value. Otherwise false is stored and ios_base::failbit
-is assigned to err.
-
96. Vector<bool> is not a container
-
We need a paper for the new bit_vector class.
+[ +Batavia: +]
+ ++The LWG feels we need something closer to SGI's bitvector to ease migration +from vector<bool>. Although some of the funcitonality from +N2050 +could well be used in such a template. The concern is easing the API migration for those +users who want to continue using a bit-packed container. Alan and Beman to work. ++ +
[ +Post Summit Alisdair adds: +]
+ + +++ ++vector<bool> is now a conforming container under the revised terms of C++0x, +which supports containers of proxies. +
++Recommend NAD. +
++Two issues remain: +
++i/ premature optimization in the specification. +There is still some sentiment that deprecation is the correct way to go, +although it is still not clear what it would mean to deprecate a single +specialization of a template. +
++Recommend: Create a new issue for the discussion, leave as Open. +
++ii/ Request for a new bitvector class to guarantee the optimization, perhaps +with a better tuned interface. +
++This is a clear extension request that may be handled via a future TR. +
+
[ +Batavia (2009-05): +]
++We note that most of this issue has become moot over time, +and agree with Alisdair's recommendations. +Move to NAD Future for reconsideration of part (ii). +
Proposed resolution:
@@ -1097,23 +1087,99 @@ and N2160. + + + + + +Section: 24.6.3.5 [istreambuf.iterator::equal] Status: Open + Submitter: Nathan Myers Opened: 1998-10-15 Last modified: 2009-03-13
+View other active issues in [istreambuf.iterator::equal].
+View all other issues in [istreambuf.iterator::equal].
+View all issues with Open status.
+Discussion:
+The member istreambuf_iterator<>::equal is specified to be +unnecessarily inefficient. While this does not affect the efficiency +of conforming implementations of iostreams, because they can +"reach into" the iterators and bypass this function, it does +affect users who use istreambuf_iterators.
+ +The inefficiency results from a too-scrupulous definition, which +requires a "true" result if neither iterator is at eof. In +practice these iterators can only usefully be compared with the +"eof" value, so the extra test implied provides no benefit, +but slows down users' code.
+ +The solution is to weaken the requirement on the function to return +true only if both iterators are at eof.
+[ -Batavia: The LWG feels we need something closer to SGI's bitvector to ease migration -from vector<bool>. Although some of the funcitonality from -N2050 -could well be used in such a template. The concern is easing the API migration for those -users who want to continue using a bit-packed container. Alan and Beman to work. +Summit: +]
+ + ++Reopened by Alisdair. ++ +
[ +Post Summit Daniel adds: ]
+++ + + ++Recommend NAD. The proposed wording would violate the axioms of +concept requirement EqualityComparable axioms as part of concept InputIterator +and more specifically it would violate the explicit wording of +24.2.2 [input.iterators]/7: +
+ ++If two iterators a and b of the same type are equal, then either a +and b are both +dereferenceable or else neither is dereferenceable. ++ +
Proposed resolution:
+Replace 24.6.3.5 [istreambuf.iterator::equal], +paragraph 1,
+ +++ +-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at + end-of-stream, regardless of what streambuf object they use.
+
with
+ +++ + + +-1- Returns: true if and only if both iterators are at + end-of-stream, regardless of what streambuf object they use.
+
Rationale:
+It is not clear that this is a genuine defect. Additionally, the +LWG was reluctant to make a change that would result in +operator== not being a equivalence relation. One consequence of +this change is that an algorithm that's passed the range [i, i) +would no longer treat it as an empty range.
+Section: 27.7 [string.streams], 27.8 [file.streams] Status: Open - Submitter: Angelika Langer Date: 1999-02-22
+Section: 27.8 [string.streams], 27.9 [file.streams] Status: Open + Submitter: Angelika Langer Opened: 1999-02-22 Last modified: 2008-03-14
View all other issues in [string.streams].
View all issues with Open status.
Discussion:
@@ -1145,7 +1211,7 @@ post Bellevue: Alisdair requested to re-Open.Proposed resolution:
For stream buffers, add a function to the base class as a non-virtual function -qualified as const to 27.5.2 [streambuf]:
+qualified as const to 27.6.2 [streambuf]:openmode mode() const;
@@ -1169,454 +1235,778 @@ retained for future reference.Section: 21.3 [basic.string] Status: Ready - Submitter: Dave Abrahams Date: 1999-07-01
-View other active issues in [basic.string].
-View all other issues in [basic.string].
-View all issues with Ready status.
+Section: 22.4.1.4 [locale.codecvt] Status: Open + Submitter: Angelika Langer Opened: 1999-03-18 Last modified: 2009-03-09
+View other active issues in [locale.codecvt].
+View all other issues in [locale.codecvt].
+View all issues with Open status.
Discussion:
-It is the constness of the container which should control whether -it can be modified through a member function such as erase(), not the -constness of the iterators. The iterators only serve to give -positioning information.
- -Here's a simple and typical example problem which is currently very -difficult or impossible to solve without the change proposed -below.
- -Wrap a standard container C in a class W which allows clients to -find and read (but not modify) a subrange of (C.begin(), C.end()]. The -only modification clients are allowed to make to elements in this -subrange is to erase them from C through the use of a member function -of W.
+Section 22.4.1.4 [locale.codecvt] specifies that +ctype_byname<char> must be a specialization of the ctype_byname +template.
+ +It is common practice in the standard that specializations of class templates are only +mentioned where the interface of the specialization deviates from the interface of the +template that it is a specialization of. Otherwise, the fact whether or not a required +instantiation is an actual instantiation or a specialization is left open as an +implementation detail.
+ +Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The +fact, that ctype_byname<char> is specified as a specialization suggests that there +must be something "special" about it, but it has the exact same interface as the +ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best +redundant, at worst misleading - unless I am missing anything.
+ +Naturally, an implementation will most likely implement ctype_byname<char> as a +specialization, because the base class ctype<char> is a specialization with an +interface different from the ctype template, but that's an implementation detail and need +not be mentioned in the standard.
[ -post Bellevue, Alisdair adds: +Summit: ]
---This issue was implemented by -N2350 -for everything but basic_string. -
- --Note that the specific example in this issue (basic_string) is the one place -we forgot to amend in -N2350, -so we might open this issue for that -single container? -
+Reopened by Alisdair.
[ -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. -
-
Rationale:
+The standard as written is mildly misleading, but the correct fix +is to deal with the underlying problem in the ctype_byname base class, +not in the specialization. See issue 228.
-Proposed resolution:
--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 { - ... +
+149. Insert should return iterator to first element inserted
+Section: 23.2.3 [sequence.reqmts] Status: Open + Submitter: Andrew Koenig Opened: 1999-06-28 Last modified: 2009-05-01
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Open status.
+Discussion:
+Suppose that c and c1 are sequential containers and i is an +iterator that refers to an element of c. Then I can insert a copy of +c1's elements into c ahead of element i by executing
- 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>); +- ... +- ... +c.insert(i, c1.begin(), c1.end());- iterator erase(const_iterator const_position); - iterator erase(const_iterator first, const_iterator last); +If c is a vector, it is fairly easy for me to find out where the +newly inserted elements are, even though i is now invalid:
- }; -} -
---Update the following signatures in 21.3.6.4 [string::insert]: -
+size_t i_loc = i - c.begin(); +c.insert(i, c1.begin(), c1.end());-+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]: -
+and now the first inserted element is at c.begin()+i_loc and one
+past the last is at c.begin()+i_loc+c1.size().
+
+But what if c is a list? I can still find the location of one past the
+last inserted element, because i is still valid. To find the location
+of the first inserted element, though, I must execute something like
+iterator erase(const_iterator const_position); -iterator erase(const_iterator first, const_iterator last); -
+-for (size_t n = c1.size(); n; --n) + --i;+
Rationale:
-The issue was discussed at length. It was generally agreed that 1) -There is no major technical argument against the change (although -there is a minor argument that some obscure programs may break), and -2) Such a change would not break const correctness. The concerns about -making the change were 1) it is user detectable (although only in -boundary cases), 2) it changes a large number of signatures, and 3) it -seems more of a design issue that an out-and-out defect.
- -The LWG believes that this issue should be considered as part of a -general review of const issues for the next revision of the -standard. Also see issue 200.
+because i is now no longer a random-access iterator.
+
+Alternatively, I might write something like
+-bool first = i == c.begin(); +list<T>::iterator j = i; +if (!first) --j; +c.insert(i, c1.begin(), c1.end()); +if (first) + j = c.begin(); +else + ++j;+
Section: 25.3.7 [alg.min.max] Status: Open - Submitter: Mark Rintoul Date: 1999-08-26
-View all other issues in [alg.min.max].
-View all issues with Open status.
-Discussion:
-Both std::min and std::max are defined as template functions. This
-is very different than the definition of std::plus (and similar
-structs) which are defined as function objects which inherit
-std::binary_function.
+
which, although wretched, requires less overhead.
- This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
-a function object that inherits std::binary_function.
[ -post Bellevue: Alisdair requested to re-Open. +Summit: ]
++Reopened by Alisdair. +- -
Rationale:
-Although perhaps an unfortunate design decision, the omission is not a defect -in the current standard. A future standard may wish to consider additional -function objects.
- +[ +Post Summit Alisdair adds: +]
++++In addition to the original rationale for C++03, this change also gives a +consistent interface for all container insert operations i.e. they all +return an iterator to the (first) inserted item. +
-
-255. Why do basic_streambuf<>::pbump() and gbump() take an int?
-Section: 27.5.2 [streambuf] Status: Open - Submitter: Martin Sebor Date: 2000-08-12
-View all other issues in [streambuf].
-View all issues with Open status.
-Discussion:
-The basic_streambuf members gbump() and pbump() are specified to take an -int argument. This requirement prevents the functions from effectively -manipulating buffers larger than std::numeric_limits<int>::max() -characters. It also makes the common use case for these functions -somewhat difficult as many compilers will issue a warning when an -argument of type larger than int (such as ptrdiff_t on LLP64 -architectures) is passed to either of the function. Since it's often the -result of the subtraction of two pointers that is passed to the -functions, a cast is necessary to silence such warnings. Finally, the -usage of a native type in the functions signatures is inconsistent with -other member functions (such as sgetn() and sputn()) that manipulate the -underlying character buffer. Those functions take a streamsize argument. +Proposed wording provided.
+
Proposed resolution:
-Change the signatures of these functions in the synopsis of template -class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 -and 27.5.2.3.2, p4) to take a streamsize argument. -
+++
+Table 83 -- Sequence container requirements (in addition to container) ++ +Expression +Return type +Assertion/note pre-/post-condition ++ + ++a.insert(p,n,t) + ++ +voiditerator ++Inserts n copies of t before p. + ++ + ++a.insert(p,i,j) + ++ +voiditerator ++Each iterator in the range [i,j) shall be +dereferenced exactly once. +pre: i and j are not iterators into a. +Inserts copies of elements in [i, j) before p + ++ ++a.insert(p,il) + ++ +voiditerator ++a.insert(p, il.begin(), il.end()). + +
-Although this change has the potential of changing the ABI of the -library, the change will affect only platforms where int is different -than the definition of streamsize. However, since both functions are -typically inline (they are on all known implementations), even on such -platforms the change will not affect any user code unless it explicitly -relies on the existing type of the functions (e.g., by taking their -address). Such a possibility is IMO quite remote. +Add after p6 23.2.3 [sequence.reqmts]:
+++-6- ...
+ ++The iterator returned from a.insert(p,n,t) points to the copy of the +first element inserted into a, or p if n == 0. +
+ ++The iterator returned from a.insert(p,i,j) points to the copy of the +first element inserted into a, or p if i == j. +
+ ++The iterator returned from a.insert(p,il) points to the copy of the +first element inserted into a, or p if il is empty. +
+ +
-Alternate Suggestion from Howard Hinnant, c++std-lib-7780: +p9 23.2.6.1 [container.concepts.free] change return type from +void to iterator:
++concept RangeInsertionContainer<typename C, typename Iter> : InsertionContainer<C> { + requires InputIterator<Iter>; +voiditerator insert(C&, const_iterator position, Iter first, Iter last); +} +
-This is something of a nit, but I'm wondering if streamoff wouldn't be a -better choice than streamsize. The argument to pbump and gbump MUST be -signed. But the standard has this to say about streamsize -(27.4.1/2/Footnote): +p9 23.2.6.2 [container.concepts.member] change return type from +void to iterator:
-+- [Footnote: streamsize is used in most places where ISO C would use - size_t. Most of the uses of streamsize could use size_t, except for - the strstreambuf constructors, which require negative values. It - should probably be the signed type corresponding to size_t (which is - what Posix.2 calls ssize_t). --- end footnote] -
auto concept MemberRangeInsertionContainer<typename C, typename Iter> : MemberInsertionContainer<C> { + requires InputIterator<Iter>; +voiditerator C::insert(const_iterator position, Iter first, Iter last); +} +
-This seems a little weak for the argument to pbump and gbump. Should we -ever really get rid of strstream, this footnote might go with it, along -with the reason to make streamsize signed. +p8 23.2.6.3 [container.concepts.maps] change return type from +void to iterator, add return statement:
+-template <MemberRangeInsertionContainer C, InputIterator Iter> +concept_map RangeInsertionContainer<C, Iter> { +voiditerator insert(C& c, Container<C>::const_iterator i, Iter first, Iter last) + { return c.insert(i, first, last); } +} +
Rationale:
-The LWG believes this change is too big for now. We may wish to -reconsider this for a future revision of the standard. One -possibility is overloading pbump, rather than changing the -signature.
-[ -[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] -]
- ++p2 23.3.2 [deque] Update class definition, change return type +from void to iterator: +
++requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, initializer_list<T>); +
+23.3.2.3 [deque.modifiers] change return type from void to iterator on following declarations: +
+-requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); +
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.
-Discussion:
-The specification of the for_each algorithm does not have a -"Requires" section, which means that there are no -restrictions imposed on the function object whatsoever. In essence it -means that I can provide any function object with arbitrary side -effects and I can still expect a predictable result. In particular I -can expect that the function object is applied exactly last - first -times, which is promised in the "Complexity" section. +
+Add the following (missing) declaration
-I don't see how any implementation can give such a guarantee -without imposing requirements on the function object. -
+-requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>); +
Just as an example: consider a function object that removes -elements from the input sequence. In that case, what does the -complexity guarantee (applies f exactly last - first times) mean? +
+23.3.3 [forwardlist] Update class definition, change return type +from void to iterator:
-One can argue that this is obviously a nonsensical application and -a theoretical case, which unfortunately it isn't. I have seen -programmers shooting themselves in the foot this way, and they did not -understand that there are restrictions even if the description of the -algorithm does not say so. -
-[Lillehammer: This is more general than for_each. We don't want - the function object in transform invalidiating iterators - either. There should be a note somewhere in clause 17 (17, not 25) - saying that user code operating on a range may not invalidate - iterators unless otherwise specified. Bill will provide wording.]
++requires AllocatableElement<Alloc, T, const T&> +voiditerator insert_after(const_iterator position, initializer_list<T> il); +requires AllocatableElement<Alloc, T, const T&> +voiditerator insert_after(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> +voiditerator insert_after(const_iterator position, Iter first, Iter last); +
+p8 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator: +
+-requires AllocatableElement<Alloc, T, const T&> +voiditerator insert_after(const_iterator position, size_type n, const T& x); +
Proposed resolution:
++Add paragraph: +
++Returns: position. ++
+p10 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator: +
++template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> +voiditerator insert_after(const_iterator position, Iter first, Iter last); +
+Add paragraph: +
++Returns: position. +-
Section: 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] Status: Open - Submitter: John Potter Date: 2001-01-22
-View all other issues in [bidirectional.iterators].
-View all issues with Open status.
-Discussion:
-In section 24.1.4 [bidirectional.iterators], -Table 75 gives the return type of *r-- as convertible to T. This is -not consistent with Table 74 which gives the return type of *r++ as -T&. *r++ = t is valid while *r-- = t is invalid. +p12 23.3.3.4 [forwardlist.modifiers] change return type from void to iterator on following declarations:
++requires AllocatableElement<Alloc, T, const T&> +voiditerator insert_after(const_iterator position, initializer_list<T> il); +
-In section 24.1.5 [random.access.iterators], -Table 76 gives the return type of a[n] as convertible to T. This is -not consistent with the semantics of *(a + n) which returns T& by -Table 74. *(a + n) = t is valid while a[n] = t is invalid. +change return type from void to iterator on following declarations:
-Discussion from the Copenhagen meeting: the first part is -uncontroversial. The second part, operator[] for Random Access -Iterators, requires more thought. There are reasonable arguments on -both sides. Return by value from operator[] enables some potentially -useful iterators, e.g. a random access "iota iterator" (a.k.a -"counting iterator" or "int iterator"). There isn't any obvious way -to do this with return-by-reference, since the reference would be to a -temporary. On the other hand, reverse_iterator takes an -arbitrary Random Access Iterator as template argument, and its -operator[] returns by reference. If we decided that the return type -in Table 76 was correct, we would have to change -reverse_iterator. This change would probably affect user -code. +p2 23.3.4 [list] Update class definition, change return type from void to iterator:
++ +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); + +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, initializer_list<T>); +
-History: the contradiction between reverse_iterator and the -Random Access Iterator requirements has been present from an early -stage. In both the STL proposal adopted by the committee -(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by -Stepanov and Lee), the Random Access Iterator requirements say that -operator[]'s return value is "convertible to T". In N0527 -reverse_iterator's operator[] returns by value, but in HPL-95-11 -(R.1), and in the STL implementation that HP released to the public, -reverse_iterator's operator[] returns by reference. In 1995, the -standard was amended to reflect the contents of HPL-95-11 (R.1). The -original intent for operator[] is unclear. +23.3.4.3 [list.modifiers] change return type from void to iterator on following declarations:
++requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); +
-In the long term it may be desirable to add more fine-grained -iterator requirements, so that access method and traversal strategy -can be decoupled. (See "Improved Iterator Categories and -Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions -about issue 299 should keep this possibility in mind. +Add the following (missing) declaration
-Further discussion: I propose a compromise between John Potter's -resolution, which requires T& as the return type of -a[n], and the current wording, which requires convertible to -T. The compromise is to keep the convertible to T -for the return type of the expression a[n], but to also add -a[n] = t as a valid expression. This compromise "saves" the -common case uses of random access iterators, while at the same time -allowing iterators such as counting iterator and caching file -iterators to remain random access iterators (iterators where the -lifetime of the object returned by operator*() is tied to the -lifetime of the iterator). -
+requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>); +
-Note that the compromise resolution necessitates a change to -reverse_iterator. It would need to use a proxy to support -a[n] = t. +p2 23.3.6 [vector]
-Note also there is one kind of mutable random access iterator that -will no longer meet the new requirements. Currently, iterators that -return an r-value from operator[] meet the requirements for a -mutable random access iterartor, even though the expression a[n] = -t will only modify a temporary that goes away. With this proposed -resolution, a[n] = t will be required to have the same -operational semantics as *(a + n) = t. +Update class definition, change return type from void to iterator:
+requires AllocatableElement<Alloc, T, T&&> && MoveAssignable<T> +voiditerator insert(const_iterator position, T&& x); +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); -Proposed resolution:
+template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); + +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, initializer_list<T>); +
-In section 24.1.4 [lib.bidirectdional.iterators], change the return -type in table 75 from "convertible to T" to -T&. +23.3.6.4 [vector.modifiers] change return type from void to iterator on following declarations:
++requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> +voiditerator insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> +voiditerator insert(const_iterator position, Iter first, Iter last); +
-In section 24.1.5 [lib.random.access.iterators], change the -operational semantics for a[n] to " the r-value of -a[n] is equivalent to the r-value of *(a + -n)". Add a new row in the table for the expression a[n] = t -with a return type of convertible to T and operational semantics of -*(a + n) = t. +Add the following (missing) declaration
-[Lillehammer: Real problem, but should be addressed as part of - iterator redesign]
++requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>); +
+p1 23.3.7 [vector.bool] Update class definition, change return type from void to iterator: +
++voiditerator insert (const_iterator position, size_type n, const bool& x); +template <InputIterator Iter> + requires Convertible<Iter::reference, bool> +voiditerator insert(const_iterator position, Iter first, Iter last); +voiditerator insert(const_iterator position, initializer_list<bool> il); +
+p5 21.4 [basic.string] Update class definition, change return type from void to iterator: +
+-voiditerator insert(const_iterator p, size_type n, charT c); + +template<class InputIterator> +voiditerator insert(const_iterator p, InputIterator first, InputIterator last); + +voiditerator insert(const_iterator p, initializer_list<charT>); +
Section: 27.6 [iostream.format] Status: Open - Submitter: Martin Sebor Date: 2001-03-19
-View all other issues in [iostream.format].
-View all issues with Open status.
-Discussion:
-The descriptions of the constructors of basic_istream<>::sentry -(27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry -(27.6.2.4 [ostream::sentry]) do not explain what the functions do in -case an exception is thrown while they execute. Some current -implementations allow all exceptions to propagate, others catch them -and set ios_base::badbit instead, still others catch some but let -others propagate. +p13 21.4.6.4 [string::insert] change return type from void to iterator:
++voiditerator insert(const_iterator p, size_type n, charT c); +
-The text also mentions that the functions may call setstate(failbit) -(without actually saying on what object, but presumably the stream -argument is meant). That may have been fine for -basic_istream<>::sentry prior to issue 195, since -the function performs an input operation which may fail. However, -issue 195 amends 27.6.1.1.3 [istream::sentry], p2 to -clarify that the function should actually call setstate(failbit | -eofbit), so the sentence in p3 is redundant or even somewhat -contradictory. +Add paragraph:
++Returns: an iterator which refers to the copy of the first inserted +character, or p if n == 0. ++
-The same sentence that appears in 27.6.2.4 [ostream::sentry], p3 -doesn't seem to be very meaningful for basic_istream<>::sentry -which performs no input. It is actually rather misleading since it -would appear to guide library implementers to calling -setstate(failbit) when os.tie()->flush(), the only called function, -throws an exception (typically, it's badbit that's set in response to -such an event). +p15 21.4.6.4 [string::insert] change return type from void to iterator:
-Additional comments from Martin, who isn't comfortable with the - current proposed resolution (see c++std-lib-11530)
++ +template<class InputIterator> +voiditerator insert(const_iterator p, InputIterator first, InputIterator last); +
+Add paragraph: +
+ ++Returns: an iterator which refers to the copy of the first inserted +character, or p if first == last. ++ +
+p17 21.4.6.4 [string::insert] change return type from void to iterator: +
+ ++ +voiditerator insert(const_iterator p, initializer_list<charT> il); +
+Add paragraph: +
+ ++Returns: an iterator which refers to the copy of the first inserted +character, or p if il is empty. ++ + + +
Rationale:
+ +[ +The following was the C++98/03 rationale and does not necessarily apply to the +proposed resolution in the C++0X time frame: +]
+ + +++ + + + +The LWG believes this was an intentional design decision and so is +not a defect. It may be worth revisiting for the next standard.
+
Section: 25.5.7 [alg.min.max] Status: Open + Submitter: Mark Rintoul Opened: 1999-08-26 Last modified: 2008-03-14
+View other active issues in [alg.min.max].
+View all other issues in [alg.min.max].
+View all issues with Open status.
+Discussion:
+Both std::min and std::max are defined as template functions. This
+is very different than the definition of std::plus (and similar
+structs) which are defined as function objects which inherit
+std::binary_function.
+
+ This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
+a function object that inherits std::binary_function.
[ +post Bellevue: Alisdair requested to re-Open. +]
+ + + + +Rationale:
+Although perhaps an unfortunate design decision, the omission is not a defect +in the current standard. A future standard may wish to consider additional +function objects.
+ + + + +Section: 25.3.5 [alg.find] Status: Open + Submitter: Pablo Halpern Opened: 2000-03-06 Last modified: 2009-03-09
+View all other issues in [alg.find].
+View all issues with Open status.
+Discussion:
+The find function always searches for a value using operator== to compare the +value argument to each element in the input iterator range. This is inconsistent +with other find-related functions such as find_end and find_first_of, which +allow the caller to specify a binary predicate object to be used for determining +equality. The fact that this can be accomplished using a combination of find_if +and bind_1st or bind_2nd does not negate the desirability of a consistent, +simple, alternative interface to find.
+ +[ +Summit: +]
+ + ++Reopened by Alisdair. ++ + + +
Proposed resolution:
+++ + +In section 25.3.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> + InputIterator find(InputIterator first, InputIterator last, + const T& value, BinaryPredicate bin_pred);+Change the description of the return from:
+++Returns: The first iterator i in the range [first, last) for which the following corresponding + conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.
+to:
+++Returns: The first iterator i in the range [first, last) for which the following + corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) + != false. Return last if no such iterator is found.
+
Rationale:
+This is request for a pure extension, so it is not a defect in the +current standard. As the submitter pointed out, "this can +be accomplished using a combination of find_if and bind_1st or +bind_2nd".
+ + + + +Section: 27.6.2 [streambuf] Status: Open + Submitter: Martin Sebor Opened: 2000-08-12 Last modified: 2007-01-15
+View all other issues in [streambuf].
+View all issues with Open status.
+Discussion:
++The basic_streambuf members gbump() and pbump() are specified to take an +int argument. This requirement prevents the functions from effectively +manipulating buffers larger than std::numeric_limits<int>::max() +characters. It also makes the common use case for these functions +somewhat difficult as many compilers will issue a warning when an +argument of type larger than int (such as ptrdiff_t on LLP64 +architectures) is passed to either of the function. Since it's often the +result of the subtraction of two pointers that is passed to the +functions, a cast is necessary to silence such warnings. Finally, the +usage of a native type in the functions signatures is inconsistent with +other member functions (such as sgetn() and sputn()) that manipulate the +underlying character buffer. Those functions take a streamsize argument. +
+ + +Proposed resolution:
++Change the signatures of these functions in the synopsis of template +class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 +and 27.5.2.3.2, p4) to take a streamsize argument. +
+ ++Although this change has the potential of changing the ABI of the +library, the change will affect only platforms where int is different +than the definition of streamsize. However, since both functions are +typically inline (they are on all known implementations), even on such +platforms the change will not affect any user code unless it explicitly +relies on the existing type of the functions (e.g., by taking their +address). Such a possibility is IMO quite remote. +
+ ++Alternate Suggestion from Howard Hinnant, c++std-lib-7780: +
+ ++This is something of a nit, but I'm wondering if streamoff wouldn't be a +better choice than streamsize. The argument to pbump and gbump MUST be +signed. But the standard has this to say about streamsize +(27.4.1/2/Footnote): +
+ ++ ++ [Footnote: streamsize is used in most places where ISO C would use + size_t. Most of the uses of streamsize could use size_t, except for + the strstreambuf constructors, which require negative values. It + should probably be the signed type corresponding to size_t (which is + what Posix.2 calls ssize_t). --- end footnote] +
+This seems a little weak for the argument to pbump and gbump. Should we +ever really get rid of strstream, this footnote might go with it, along +with the reason to make streamsize signed. +
+ + +Rationale:
+The LWG believes this change is too big for now. We may wish to +reconsider this for a future revision of the standard. One +possibility is overloading pbump, rather than changing the +signature.
+[ +[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] +]
+ + + + + +Section: 25.3.4 [alg.foreach] Status: Open + Submitter: Angelika Langer Opened: 2001-01-03 Last modified: 2006-12-27
+View other active issues in [alg.foreach].
+View all other issues in [alg.foreach].
+View all issues with Open status.
+Discussion:
+The specification of the for_each algorithm does not have a +"Requires" section, which means that there are no +restrictions imposed on the function object whatsoever. In essence it +means that I can provide any function object with arbitrary side +effects and I can still expect a predictable result. In particular I +can expect that the function object is applied exactly last - first +times, which is promised in the "Complexity" section. +
+ +I don't see how any implementation can give such a guarantee +without imposing requirements on the function object. +
+ +Just as an example: consider a function object that removes +elements from the input sequence. In that case, what does the +complexity guarantee (applies f exactly last - first times) mean? +
+ +One can argue that this is obviously a nonsensical application and +a theoretical case, which unfortunately it isn't. I have seen +programmers shooting themselves in the foot this way, and they did not +understand that there are restrictions even if the description of the +algorithm does not say so. +
+[Lillehammer: This is more general than for_each. We don't want + the function object in transform invalidiating iterators + either. There should be a note somewhere in clause 17 (17, not 25) + saying that user code operating on a range may not invalidate + iterators unless otherwise specified. Bill will provide wording.]
+ + + +Proposed resolution:
+ + + + + + +Section: 27.7 [iostream.format] Status: Open + Submitter: Martin Sebor Opened: 2001-03-19 Last modified: 2006-12-27
+View all other issues in [iostream.format].
+View all issues with Open status.
+Discussion:
++The descriptions of the constructors of basic_istream<>::sentry +(27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry +(27.7.2.4 [ostream::sentry]) do not explain what the functions do in +case an exception is thrown while they execute. Some current +implementations allow all exceptions to propagate, others catch them +and set ios_base::badbit instead, still others catch some but let +others propagate. +
+ ++The text also mentions that the functions may call setstate(failbit) +(without actually saying on what object, but presumably the stream +argument is meant). That may have been fine for +basic_istream<>::sentry prior to issue 195, since +the function performs an input operation which may fail. However, +issue 195 amends 27.7.1.1.3 [istream::sentry], p2 to +clarify that the function should actually call setstate(failbit | +eofbit), so the sentence in p3 is redundant or even somewhat +contradictory. +
+ ++The same sentence that appears in 27.7.2.4 [ostream::sentry], p3 +doesn't seem to be very meaningful for basic_istream<>::sentry +which performs no input. It is actually rather misleading since it +would appear to guide library implementers to calling +setstate(failbit) when os.tie()->flush(), the only called function, +throws an exception (typically, it's badbit that's set in response to +such an event). +
+ +Additional comments from Martin, who isn't comfortable with the + current proposed resolution (see c++std-lib-11530)
The istream::sentry ctor says nothing about how the function @@ -1886,15 +2276,15 @@ committee.
Section: 27.6.1.3 [istream.unformatted] Status: Open - Submitter: Howard Hinnant Date: 2001-10-09
+Section: 27.7.1.3 [istream.unformatted] Status: Open + Submitter: Howard Hinnant Opened: 2001-10-09 Last modified: 2007-01-15
View all other issues in [istream.unformatted].
View all issues with Open status.
Discussion:
I think we have a defect.
According to lwg issue 60 which is now a dr, the -description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks +description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks like:
@@ -1972,7 +2362,7 @@ you can never seek away from the end of stream.
Proposed resolution:
-Change 27.6.1.3 [istream.unformatted] to:
+Change 27.7.1.3 [istream.unformatted] to:
-Behaves as an unformatted input function (as described in 27.6.1.3, paragraph 1), except that it does not count the number of characters @@ -2004,9 +2394,10 @@ In case of failure, the function calls setstate(failbit)
343. Unspecified library header dependencies
-Section: 21 [strings], 23 [containers], 27 [input.output] Status: Open - Submitter: Martin Sebor Date: 2001-10-09
-View all other issues in [strings].
+Section: 17 [library] Status: Open + Submitter: Martin Sebor Opened: 2001-10-09 Last modified: 2009-03-11
+View other active issues in [library].
+View all other issues in [library].
View all issues with Open status.
Discussion:
@@ -2242,8 +2633,9 @@ Hinnant: It's time we dealt with this issue for C++0X. Reopened.
382. codecvt do_in/out result
-Section: 22.2.1.4 [locale.codecvt] Status: Open - Submitter: Martin Sebor Date: 2002-08-30
+Section: 22.4.1.4 [locale.codecvt] Status: Open + Submitter: Martin Sebor Opened: 2002-08-30 Last modified: 2007-01-15
+View other active issues in [locale.codecvt].
View all other issues in [locale.codecvt].
View all issues with Open status.
Discussion:
@@ -2271,7 +2663,7 @@ the following seems less than adequately specified:
- - 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the + 22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the function: ...Stops if it encounters a character it cannot convert... This assumes that there *is* a character to convert. What happens when there is a sequence that doesn't form a @@ -2304,7 +2696,7 @@ the following seems less than adequately specified:
-Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible: +Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
"A return value of partial, if (from_next == from_end), @@ -2318,7 +2710,7 @@ If the value is partial, it's not clear to me that (from_next ==from_end) could ever hold if there isn't enough room in the destination buffer. In order for (from_next==from_end) to hold, all characters in that range must have been successfully -converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no +converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no further source characters to convert, no more room in the destination buffer can be needed.
@@ -2363,176 +2755,19 @@ partial can only occur if (from_next != from_end)?
-387. std::complex over-encapsulated
-Section: 26.3 [complex.numbers] Status: Ready - Submitter: Gabriel Dos Reis Date: 2002-11-08
-View all other issues in [complex.numbers].
-View all issues with Ready status.
+394. behavior of formatted output on failure
+Section: 27.7.2.6.1 [ostream.formatted.reqmts] Status: Open + Submitter: Martin Sebor Opened: 2002-12-27 Last modified: 2007-01-15
+View all issues with Open status.
Discussion:
-The absence of explicit description of std::complex<T> layout -makes it imposible to reuse existing software developed in traditional -languages like Fortran or C with unambigous and commonly accepted -layout assumptions. There ought to be a way for practitioners to -predict with confidence the layout of std::complex<T> whenever T -is a numerical datatype. The absence of ways to access individual -parts of a std::complex<T> object as lvalues unduly promotes -severe pessimizations. For example, the only way to change, -independently, the real and imaginary parts is to write something like +There is a contradiction in Formatted output about what bit is +supposed to be set if the formatting fails. On sentence says it's +badbit and another that it's failbit.
- -complex<T> z; -// ... -// set the real part to r -z = complex<T>(r, z.imag()); -// ... -// set the imaginary part to i -z = complex<T>(z.real(), i); ---At this point, it seems appropriate to recall that a complex number -is, in effect, just a pair of numbers with no particular invariant to -maintain. Existing practice in numerical computations has it that a -complex number datatype is usually represented by Cartesian -coordinates. Therefore the over-encapsulation put in the specification -of std::complex<> is not justified. -
- - - -Proposed resolution:
-Add the following requirements to 26.3 [complex.numbers] as 26.3/4:
--- -If z is an lvalue expression of type cv std::complex<T> then
- --
- -- the expression reinterpret_cast<cv T(&)[2]>(z) -is well-formed; and
-- reinterpret_cast<cv T(&)[2]>(z)[0]designates the -real part of z; and
-- reinterpret_cast<cv T(&)[2]>(z)[1]designates the -imaginary part of z.
--Moreover, if a is an expression of pointer type cv complex<T>* -and the expression a[i] is well-defined for an integer expression -i then: -
- --
-- reinterpret_cast<cv T*>(a)[2*i] designates the real -part of a[i]; and
-- reinterpret_cast<cv T*>(a)[2*i+1] designates the -imaginary part of a[i].
--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); -void imag(T); --Add to 26.3.4 [complex.members] -
- --- -T real() const; ---Returns: the value of the real component --void real(T val); ---Assigns val to the real component. --T imag() const; ---Returns: the value of the imaginary component --void imag(T val); ---Assigns val to the imaginary component. --[Kona: The layout guarantee is absolutely necessary for C - compatibility. However, there was disagreement about the other part - of this proposal: retrieving elements of the complex number as - lvalues. An alternative: continue to have real() and imag() return - rvalues, but add set_real() and set_imag(). Straw poll: return - lvalues - 2, add setter functions - 5. Related issue: do we want - reinterpret_cast as the interface for converting a complex to an - array of two reals, or do we want to provide a more explicit way of - doing it? Howard will try to resolve this issue for the next - meeting.]
- - -[pre-Sydney: Howard summarized the options in n1589.]
- - -[ -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 -justification for this change even without other considerations. All -existing implementations already have the layout proposed here.
- - - - - -
-394. behavior of formatted output on failure
-Section: 27.6.2.6.1 [ostream.formatted.reqmts] Status: Open - Submitter: Martin Sebor Date: 2002-12-27
-View all issues with Open status.
-Discussion:
--There is a contradiction in Formatted output about what bit is -supposed to be set if the formatting fails. On sentence says it's -badbit and another that it's failbit. -
--27.6.2.5.1, p1 says in the Common Requirements on Formatted output -functions: +27.6.2.5.1, p1 says in the Common Requirements on Formatted output +functions:
... If the generation fails, then the formatted output function does setstate(ios::failbit), which might throw an exception. @@ -2625,143 +2860,9 @@ functions should be changed as proposed below.
-396. what are characters zero and one
-Section: 23.3.5.1 [bitset.cons] Status: Ready - Submitter: Martin Sebor Date: 2003-01-05
-View all other issues in [bitset.cons].
-View all issues with Ready status.
-Discussion:
--23.3.5.1, p6 [lib.bitset.cons] talks about a generic character -having the value of 0 or 1 but there is no definition of what -that means for charT other than char and wchar_t. And even for -those two types, the values 0 and 1 are not actually what is -intended -- the values '0' and '1' are. This, along with the -converse problem in the description of to_string() in 23.3.5.2, -p33, looks like a defect remotely related to DR 303. -
--http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 -
-23.3.5.1: - -6- An element of the constructed string has value zero if the - corresponding character in str, beginning at position pos, - is 0. Otherwise, the element has the value one. --23.3.5.2: - -33- Effects: Constructs a string object of the appropriate - type and initializes it to a string of length N characters. - Each character is determined by the value of its - corresponding bit position in *this. Character position N - ?- 1 corresponds to bit position zero. Subsequent decreasing - character positions correspond to increasing bit positions. - Bit value zero becomes the character 0, bit value one becomes - the character 1. ---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:
-Change the constructor's function declaration immediately before -23.3.5.1 [bitset.cons] p3 to:
-template <class charT, class traits, class Allocator> - explicit - bitset(const basic_string<charT, traits, Allocator>& str, - typename basic_string<charT, traits, Allocator>::size_type pos = 0, - typename basic_string<charT, traits, Allocator>::size_type n = - basic_string<charT, traits, Allocator>::npos, - charT zero = charT('0'), charT one = charT('1')) --Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An -element of the constructed string has value 0 if the corresponding -character in str, beginning at position pos, -is zero. Otherwise, the element has the value 1.
- -Change the text of the second sentence in 23.3.5.1, p5 to read: - "The function then throws invalid_argument if any of the rlen - characters in str beginning at position pos is other than zero - or one. The function uses traits::eq() to compare the character - values." -
- -Change the declaration of the to_string member function - immediately before 23.3.5.2 [bitset.members] p33 to:
-template <class charT, class traits, class Allocator> - basic_string<charT, traits, Allocator> - to_string(charT zero = charT('0'), charT one = charT('1')) const; --Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit - value 0 becomes the character zero, bit value 1 becomes the - character one.
-Change 23.3.5.3 [bitset.operators] p8 to:
-Returns:
-os << x.template to_string<charT,traits,allocator<charT> >( - use_facet<ctype<charT> >(os.getloc()).widen('0'), - use_facet<ctype<charT> >(os.getloc()).widen('1')); -- - -Rationale:
-There is a real problem here: we need the character values of '0' - and '1', and we have no way to get them since strings don't have - imbued locales. In principle the "right" solution would be to - provide an extra object, either a ctype facet or a full locale, - which would be used to widen '0' and '1'. However, there was some - discomfort about using such a heavyweight mechanism. The proposed - resolution allows those users who care about this issue to get it - right.
-We fix the inserter to use the new arguments. Note that we already - fixed the analogous problem with the extractor in issue 303.
- - - -[ -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. -- - - - -
397. ostream::sentry dtor throws exceptions
-Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05
+Section: 27.7.2.4 [ostream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2007-07-25
View other active issues in [ostream::sentry].
View all other issues in [ostream::sentry].
View all issues with Open status.
@@ -2812,8 +2913,8 @@ See 41
398. effects of end-of-file on unformatted input functions
-Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05
+Section: 27.7.2.4 [ostream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2007-01-15
View other active issues in [ostream::sentry].
View all other issues in [ostream::sentry].
View all issues with Open status.
@@ -2915,10 +3016,10 @@ end-of-file):
408. Is vector<reverse_iterator<char*> > forbidden?
-Section: 24.1 [iterator.requirements] Status: Open - Submitter: Nathan Myers Date: 2003-06-03
-View other active issues in [iterator.requirements].
-View all other issues in [iterator.requirements].
+Section: 24.2 [iterator.concepts] Status: Open + Submitter: Nathan Myers Opened: 2003-06-03 Last modified: 2009-05-10
+View other active issues in [iterator.concepts].
+View all other issues in [iterator.concepts].
View all issues with Open status.
Discussion:
@@ -2927,7 +3028,7 @@ surprise has popped up. I don't think this has been discussed before.
-24.1 [iterator.requirements] says that the only operation that can be performed on "singular" +24.2 [iterator.concepts] says that the only operation that can be performed on "singular" iterator values is to assign a non-singular value to them. (It doesn't say they can be destroyed, and that's probably a defect.) Some implementations have taken this to imply that there is no need @@ -3025,7 +3126,7 @@ are default-initialized, and it should explicitly allow destroying any iterator value, singular or not, default-initialized or not.
-Related issue: 407
+[ We don't want to require all singular iterators to be copyable, because that is not the case for pointers. However, default @@ -3037,9 +3138,31 @@ wrong to impose so strict a requirement for iterators. ]
+[ +2009-05-10 Alisdair provided wording. +]
+ + ++The comments regarding destroying singular iterators have already been +resolved. That just leaves copying (with moving implied). ++Proposed resolution:
++Add to the end of Iterator concepts 24.2 [iterator.concepts] para 6 (the one +describing singular iterators) +
++Any Iterator that satisfies the DefaultConstructible concept shall +be safely copyable after value-initialization, even if it would otherwise be +singular. [Note: This guarantee is not offered for default-initialization +(8.5 [dcl.init]), although the distinction only matters for types with +trivial default constructors such as pointers. — end note] ++ @@ -3047,8 +3170,8 @@ wrong to impose so strict a requirement for iterators.
417. what does ctype::do_widen() return on failure
-Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 22.4.1.1.2 [locale.ctype.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2006-12-27
View all other issues in [locale.ctype.virtuals].
View all issues with Open status.
Discussion:
@@ -3081,8 +3204,10 @@ and iostream to reliably detect this failure.
418. exceptions thrown during iostream cleanup
-Section: 27.4.2.1.6 [ios::Init] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 27.5.2.1.6 [ios::Init] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-07-25
+View other active issues in [ios::Init].
+View all other issues in [ios::Init].
View all issues with Open status.
Discussion:
@@ -3124,16 +3249,16 @@ See 39
+
419. istream extractors not setting failbit if eofbit is already set
-Section: 27.6.1.1.3 [istream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 27.7.1.1.3 [istream::sentry] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-30
View all other issues in [istream::sentry].
View all issues with Open status.
Discussion:
-27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() +27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to -true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then +true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then says that a formatted input function endeavors to obtain the requested input if the sentry's operator bool() returns true. @@ -3213,7 +3338,7 @@ you can never seek away from the end of stream.
Proposed resolution:
-Change 27.6.1.1.3 [istream::sentry], p2 to: +Change 27.7.1.1.3 [istream::sentry], p2 to:
@@ -3232,8 +3357,8 @@ Otherwise prepares for formatted or unformatted input. ...
421. is basic_streambuf copy-constructible?
-Section: 27.5.2.1 [streambuf.cons] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 27.6.2.1 [streambuf.cons] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-15
View all other issues in [streambuf.cons].
View all issues with Open status.
Discussion:
@@ -3434,7 +3559,8 @@ basic_filebuf.
423. effects of negative streamsize in iostreams
Section: 27 [input.output] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+ Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2006-12-27View other active issues in [input.output].
View all other issues in [input.output].
View all issues with Open status.
Discussion:
@@ -3474,9 +3600,120 @@ ostream::write().
+424. normative notes
+Section: 17.5.1.2 [structure.summary] Status: Tentatively NAD Editorial + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
+ ++The text in 17.3.1.1, p1 says: +
+ +
+ +"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other +paragraphs are normative." +
+ +The library section makes heavy use of paragraphs labeled "Notes(s)," +some of which are clearly intended to be normative (see list 1), while +some others are not (see list 2). There are also those where the intent +is not so clear (see list 3). +
+ +List 1 -- Examples of (presumably) normative Notes: +
+ +20.8.6.1 [allocator.members], p3,
+20.8.6.1 [allocator.members], p10,
+21.4.2 [string.cons], p11,
+22.3.1.2 [locale.cons], p11,
+23.3.2.3 [deque.modifiers], p2,
+25.5.7 [alg.min.max], p3,
+26.4.6 [complex.ops], p15,
+27.6.2.4.3 [streambuf.virt.get], p7.
+
+ +List 2 -- Examples of (presumably) informative Notes: +
+ +18.6.1.3 [new.delete.placement], p3,
+21.4.6.6 [string::replace], p14,
+22.4.1.4.2 [locale.codecvt.virtuals], p3,
+25.3.4 [alg.foreach], p4,
+26.4.5 [complex.member.ops], p1,
+27.5.2.5 [ios.base.storage], p6.
+
+ +List 3 -- Examples of Notes that are not clearly either normative +or informative: +
+ +22.3.1.2 [locale.cons], p8,
+22.3.1.5 [locale.statics], p6,
+27.6.2.4.5 [streambuf.virt.put], p4.
+
+ +None of these lists is meant to be exhaustive. +[Definitely a real problem. The big problem is there's material + that doesn't quite fit any of the named paragraph categories + (e.g. Effects). Either we need a new kind of named + paragraph, or we need to put more material in unnamed paragraphs + jsut after the signature. We need to talk to the Project Editor + about how to do this. +]
+ + +[ +Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, +22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete +will handle editorially. +]
+ + +[ +post San Francisco: Howard: reopened, needs attention. +]
+ + +[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". +Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. +Recommend NAD.]
+ + +[ +Batavia: We feel that the references in List 2 above should be changed from Remarks +to Notes. We also feel that those items in List 3 need to be double checked for +the same change. Alan and Pete to review. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + + ++A spot-check of List 2 suggests the issue is still relevant, +and a review of List 3 still seems called-for. +
++Move to NAD Editorial. +
+Proposed resolution:
+ + + + +
427. stage 2 and rationale of DR 221
-Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2007-01-15
View other active issues in [facet.num.get.virtuals].
View all other issues in [facet.num.get.virtuals].
View all issues with Open status.
@@ -3535,8 +3772,8 @@ use char_traits<charT>.
430. valarray subset operations
-Section: 26.5.2.4 [valarray.sub] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
+Section: 26.6.2.4 [valarray.sub] Status: Open + Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-05-01
View all issues with Open status.
Discussion:
@@ -3571,7 +3808,7 @@ post-Bellevue: Bill provided wording.
Proposed resolution:
-Insert after 26.5.2.4 [valarray.sub], paragraph 1: +Insert after 26.6.2.4 [valarray.sub], paragraph 1:
@@ -3674,7 +3911,7 @@ const size_t lv[] = {2, 3}; const size_t dv[] = {7, 2}; const valarray<size_t> len(lv, 2), str(dv, 2); // v0[gslice(3, len, str)] returns -// valarray<char>("dfhkmo", 6) +// valarray<char>("dfhkmo", 6)@@ -3685,7 +3922,7 @@ designated by boolarr. For example:
valarray<char> v0("abcdefghijklmnop", 16); const bool vb[] = {false, false, true, true, false, true}; // v0[valarray<bool>(vb, 6)] returns -// valarray<char>("cdf", 3) +// valarray<char>("cdf", 3)@@ -3707,13 +3944,13 @@ const size_t vi[] = {7, 5, 2, 3, 8};
431. Swapping containers with unequal allocators
-Section: 20.1.2 [allocator.requirements], 25 [algorithms] Status: Open - Submitter: Matt Austern Date: 2003-09-20
+Section: X [allocator.requirements], 25 [algorithms] Status: Open + Submitter: Matt Austern Opened: 2003-09-20 Last modified: 2009-05-01
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with Open status.
Discussion:
-Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations +
Clause X [allocator.requirements] paragraph 4 says that implementations are permitted to supply containers that are unable to cope with allocator instances and that container implementations may assume that all instances of an allocator type compare equal. We gave @@ -3774,6 +4011,29 @@ swap allocators, else it will perform a "slow swap" using copy construction and ]
+[ +2009-04-28 Pablo adds: +]
+ ++Fixed in +N2525. +I argued for marking this Tentatively-Ready right after Bellevue, +but there was a concern that +N2525 +would break in the presence of the RVO. (That breakage had nothing to do with +swap, but never-the-less). I addressed that breakage in in +N2840 +(Summit) my means of a non-normative reference: + +++[Note: in situations where the copy constructor for a container is elided, +this function is not called. The behavior in these cases is as if +select_on_container_copy_construction returned x — end note] ++ +Proposed resolution:
@@ -3784,10 +4044,10 @@ swap allocators, else it will perform a "slow swap" using copy construction and
446. Iterator equality between different containers
-Section: 24.1 [iterator.requirements], 23.1 [container.requirements] Status: Open - Submitter: Andy Koenig Date: 2003-12-16
-View other active issues in [iterator.requirements].
-View all other issues in [iterator.requirements].
+Section: 24.2 [iterator.concepts], 23.2 [container.requirements] Status: Open + Submitter: Andy Koenig Opened: 2003-12-16 Last modified: 2008-09-30
+View other active issues in [iterator.concepts].
+View all other issues in [iterator.concepts].
View all issues with Open status.
Discussion:
@@ -3821,219 +4081,66 @@ 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 all other issues in [filebuf.members].
-View all issues with Open status.
-Duplicate of: 105
+458. 24.1.5 contains unintented limitation for operator-
+Section: 24.2.6 [random.access.iterators] Status: Tentatively NAD + Submitter: Daniel Frey Opened: 2004-02-27 Last modified: 2009-05-23
+View other active issues in [random.access.iterators].
+View all other issues in [random.access.iterators].
+View all issues with Tentatively NAD status.
Discussion:
-basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); -- -should be supplemented with the overload:
- -basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode); ---Depending on the operating system, one of these forms is fundamental and -the other requires an implementation-defined mapping to determine the -actual filename. +In 24.1.5 [lib.random.access.iterators], table 76 the operational +semantics for the expression "r -= n" are defined as "return r += -n". +This means, that the expression -n must be valid, which is not the case +for unsigned types.
-[Sydney: Yes, we want to allow wchar_t filenames. Bill will - provide wording.]
- -[ -In Toronto we noted that this is issue 5 from -N1569. +Sydney: Possibly not a real problem, since difference type is required +to be a signed integer type. However, the wording in the standard may +be less clear than we would like. ]
--How does this interact with the newly-defined character types, and how -do we avoid interface explosion considering std::string overloads that -were added? Propose another solution that is different than the -suggestion proposed by PJP. -
--Suggestion is to make a member template function for basic_string (for -char, wchar_t, u16char, u32char instantiations), and then just keep a -const char* member. -
--Goal is to do implicit conversion between character string literals to -appropriate basic_string type. Not quite sure if this is possible. -
--Implementors are free to add specific overloads for non-char character -types. -
[ -Martin adds pre-Sophia Antipolis: +Post Summit Alisdair adds: ]
-Please see issue 454: problems and solutions. ++This issue refers to a requirements table we have removed. +
++The issue might now relate to 24.2.6 [random.access.iterators] p5. +However, the rationale in the issue already recognises that the +difference_type must be signed, so this really looks NAD. +
[ -Sophia Antipolis: +Batavia (2009-05): ]
---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. +We agree with Alisdair's observations.
-The TR2 filesystem library is a more complete solution, but is not available soon. +Move to NAD.
[ -Martin adds: please reference -N2683 for -problems and solutions. -]
- - - - -Proposed resolution:
- -Change from:
--- -basic_filebuf<charT,traits>* open( - const char* s, - ios_base::openmode mode ); -- --Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)).
-to:
- --- - - -basic_filebuf<charT,traits>* open( - const char* s, - ios_base::openmode mode ); - -basic_filebuf<charT,traits>* open( - const wchar_t* ws, - ios_base::openmode mode ); -- --Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)). -For the second signature, the NTBS s is determined from the -WCBS ws in an implementation-defined manner. -
- --(NOTE: For a system that "naturally" represents a filename -as a WCBS, the NTBS s in the first signature may instead -be mapped to a WCBS; if so, it follows the same mapping -rules as the first argument to open.) -
-Rationale:
--Slightly controversial, but by a 7-1 straw poll the LWG agreed to move -this to Ready. The controversy was because the mapping between wide -names and files in a filesystem is implementation defined. The -counterargument, which most but not all LWG members accepted, is that -the mapping between narrow files names and files is also -implemenation defined.
- -[Lillehammer: Moved back to "open" status, at Beman's urging. -(1) Why just basic_filebuf, instead of also basic_fstream (and -possibly other things too). (2) Why not also constructors that take -std::basic_string? (3) We might want to wait until we see Beman's -filesystem library; we might decide that it obviates this.]
- - -[ -post Bellevue: -]
- - --- - - - - - - - --Move again to Ready. -
--There is a timing issue here. Since the filesystem library will not be -in C++0x, this should be brought forward. This solution would remain -valid in the context of the proposed filesystem. -
--This issue has been kicking around for a while, and the wchar_t addition -alone would help many users. Thus, we suggest putting this on the -reflector list with an invitation for someone to produce proposed -wording that covers basic_fstream. In the meantime, we suggest that the -proposed wording be adopted as-is. -
--If more of the Lillehammer questions come back, they should be -introduced as separate issues. -
-
-458. 24.1.5 contains unintented limitation for operator-
-Section: 24.1.5 [random.access.iterators] Status: Open - Submitter: Daniel Frey Date: 2004-02-27
-View all other issues in [random.access.iterators].
-View all issues with Open status.
-Discussion:
--In 24.1.5 [lib.random.access.iterators], table 76 the operational -semantics for the expression "r -= n" are defined as "return r += -n". -This means, that the expression -n must be valid, which is not the case -for unsigned types. -
- -[ -Sydney: Possibly not a real problem, since difference type is required -to be a signed integer type. However, the wording in the standard may -be less clear than we would like. -]
- - -Proposed resolution:
To remove this limitation, I suggest to change the operational semantics for this column to:
-+{ Distance m = n; - if (m >= 0) - while (m--) --r; - else +@@ -4045,8 +4152,8 @@ operational semantics for this column to:{ Distance m = n; + if (m >= 0) + while (m--) --r; + else while (m++) ++r; return r; }
459. Requirement for widening in stage 2 is overspecification
-Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open - Submitter: Martin Sebor Date: 2004-03-16
+Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2004-03-16 Last modified: 2006-12-27
View other active issues in [facet.num.get.virtuals].
View all other issues in [facet.num.get.virtuals].
View all issues with Open status.
@@ -4099,7 +4206,7 @@ to their narrow equivalents (i.e., the portable source characters '0' through '9'), the change does not necessarily imply that these alternate digits would be treated as ordinary digits and accepted as -part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 +part of numbers during parsing. In fact, the requirement in 22.4.1.1.2 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate digit character, wc, to an ordinary digit in the basic source character set unless the expression @@ -4139,7 +4246,8 @@ technique to perform the comparison:
463. auto_ptr usability issues
Section: D.9.1 [auto.ptr] Status: Open - Submitter: Rani Sharoni Date: 2003-12-07
+ Submitter: Rani Sharoni Opened: 2003-12-07 Last modified: 2007-11-15 +View other active issues in [auto.ptr].
View all other issues in [auto.ptr].
View all issues with Open status.
Discussion:
@@ -4540,9 +4648,76 @@ The expression delete get() is well formed.
+466. basic_string ctor should prevent null pointer error
+Section: 21.4.1 [string.require] Status: Open + Submitter: Daniel Frey Opened: 2004-06-10 Last modified: 2009-05-23
+View other active issues in [string.require].
+View all other issues in [string.require].
+View all issues with Open status.
+Discussion:
++Today, my colleagues and me wasted a lot of time. After some time, I +found the problem. It could be reduced to the following short example: +
+ +#include <string> + int main() { std::string( 0 ); } ++ +The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and +Comeau online) compile the above without errors or warnings! The +programs (at least for the GCC) resulted in a SEGV.
+ +I know that the standard explicitly states that the ctor of string +requires a char* which is not zero. STLs could easily detect the above +case with a private ctor for basic_string which takes a single 'int' +argument. This would catch the above code at compile time and would not +ambiguate any other legal ctors.
+ +[Redmond: No great enthusiasm for doing this. If we do, + however, we want to do it for all places that take charT* + pointers, not just the single-argument constructor. The other + question is whether we want to catch this at compile time (in which + case we catch the error of a literal 0, but not an expression whose + value is a null pointer), at run time, or both. + Recommend NAD. Relegate this functionality to debugging implementations.]
+ + +[ +Post Summit: Alisdair requests this be re-opened as several new language facilities are +designed to solve exactly this kind of problem. +]
+ + +[ +Batavia (2009-05): +]
+ ++We are unable to achieve consensus on an approach to a resolution. +There is some sentiment for treating this as a QOI matter. +It is also possible +that when string is brought into the concepts world, +this issue might be addressed in that context. ++ + +Proposed resolution:
++Add to the synopsis in 21.4 [basic.string] +
+ ++ + + + + +basic_string( nullptr_t ) = delete; +
471. result of what() implementation-defined
-Section: 18.6.1 [type.info] Status: Open - Submitter: Martin Sebor Date: 2004-06-28
+Section: 18.7.1 [type.info] Status: Open + Submitter: Martin Sebor Opened: 2004-06-28 Last modified: 2009-05-23
View all other issues in [type.info].
View all issues with Open status.
Discussion:
@@ -4625,16 +4800,34 @@ 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. +is intended to be supported, not coping from a derived to a base.+[ +Batavia (2009-05): +]
+++Howard supplied the following replacement wording +for paragraph 7 of the proposed resolution: +
++-7- Postcondition: what() shall return the same NTBS + as would be obtained by using static_cast + to cast the rhs to the same types as the lhs + and then calling what() on that possibly sliced object. +++Pete asks what "the same NTBS" means. +
+Proposed resolution:
-Change 18.7.1 [exception] to: +Change 18.8.1 [exception] to:
@@ -4664,8 +4857,8 @@ to all standard library-defined classes that derive from exception.+473. underspecified ctype calls
-Section: 22.2.1.1 [locale.ctype] Status: Open - Submitter: Martin Sebor Date: 2004-07-01
+Section: 22.4.1.1 [locale.ctype] Status: Open + Submitter: Martin Sebor Opened: 2004-07-01 Last modified: 2006-12-27
View all issues with Open status.
Discussion:
@@ -4747,66 +4940,9 @@ provide wording.
-484. Convertible to T
-Section: 24.1.1 [input.iterators] Status: Open - Submitter: Chris Jefferson Date: 2004-09-16
-View all other issues in [input.iterators].
-View all issues with Open status.
-Discussion:
-From comp.std.c++:
- --I note that given an input iterator a for type T, -then *a only has to be "convertable to T", not actually of type T. -
- -Firstly, I can't seem to find an exact definition of "convertable to T". -While I assume it is the obvious definition (an implicit conversion), I -can't find an exact definition. Is there one?
- -Slightly more worryingly, there doesn't seem to be any restriction on -the this type, other than it is "convertable to T". Consider two input -iterators a and b. I would personally assume that most people would -expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that -the standard requires that, and that whatever type *a is (call it U) -could have == defined on it with totally different symantics and still -be a valid inputer iterator.
- -Is this a correct reading? When using input iterators should I write -T(*a) all over the place to be sure that the object i'm using is the -class I expect?
- -This is especially a nuisance for operations that are defined to be - "convertible to bool". (This is probably allowed so that - implementations could return say an int and avoid an unnessary - conversion. However all implementations I have seen simply return a - bool anyway. Typical implemtations of STL algorithms just write - things like while(a!=b && *a!=0). But strictly - speaking, there are lots of types that are convertible to T but - that also overload the appropriate operators so this doesn't behave - as expected.
- -If we want to make code like this legal (which most people seem to - expect), then we'll need to tighten up what we mean by "convertible - to T".
- -[Lillehammer: The first part is NAD, since "convertible" is - well-defined in core. The second part is basically about pathological - overloads. It's a minor problem but a real one. So leave open for - now, hope we solve it as part of iterator redesign.]
- - - -Proposed resolution:
- - - - - -
485. output iterator insufficently constrained
-Section: 24.1.2 [output.iterators] Status: Open - Submitter: Chris Jefferson Date: 2004-10-13
+Section: 24.2.3 [output.iterators] Status: Open + Submitter: Chris Jefferson Opened: 2004-10-13 Last modified: 2006-12-27
View all other issues in [output.iterators].
View all issues with Open status.
Discussion:
@@ -4850,10 +4986,10 @@ wording (I believe) x,a,b,c could be written to in any order.
492. Invalid iterator arithmetic expressions
-Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open - Submitter: Thomas Mang Date: 2004-12-12
-View other active issues in [containers].
-View all other issues in [containers].
+Section: 17.5.1.4 [structure.specifications] Status: Open + Submitter: Thomas Mang Opened: 2004-12-12 Last modified: 2009-05-10
+View other active issues in [structure.specifications].
+View all other issues in [structure.specifications].
View all issues with Open status.
Discussion:
Various clauses other than clause 25 make use of iterator arithmetic not @@ -5024,6 +5160,16 @@ Bellevue: Keep open and ask Bill to provide wording.
[ +2009-05-09 Alisdair adds: +]
+ + ++This issue is related to 997. ++ +Proposed resolution:
@@ -5040,8 +5186,8 @@ it doesn't cover. Bill will provide wording.]
498. Requirements for partition() and stable_partition() too strong
-Section: 25.2.13 [alg.partitions] Status: Open - Submitter: Sean Parent, Joe Gottman Date: 2005-05-04
+Section: 25.4.13 [alg.partitions] Status: Open + Submitter: Sean Parent, Joe Gottman Opened: 2005-05-04 Last modified: 2009-05-01
View all issues with Open status.
Discussion:
@@ -5055,6 +5201,62 @@ and http://www.sgi.com/tech/stl/stable_partition.html).
+[ +2009-04-30 Alisdair adds: +]
+ + +++ ++Now we have concepts this is easier to express! +
++Proposed resolution: +
++Add the following signature to: +
++Header <algorithm> synopsis 25.2 [algorithms.syn]
+
+p3 Partitions 25.4.13 [alg.partitions] ++ +template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred> + requires ShuffleIterator<Iter> + && CopyConstructible<Pred> + Iter partition(Iter first, Iter last, Pred pred); ++Update p3 Partitions 25.4.13 [alg.partitions]: +
+ +++ ++Complexity:
+At most (last - first)/2 swaps. Exactly last - first +applications of the predicate +are done.+ +If Iter satisfies BidirectionalIterator, at most (last - +first)/2 swaps. Exactly last - first applications of the predicate +are done. + ++If Iter merely satisfied ForwardIterator at most (last - first) swaps +are done. Exactly (last - first) applications of the predicate are done. +
++[Editorial note: I looked for existing precedent in how we might call out +distinct overloads overloads from a set of constrained templates, but there +is not much existing practice to lean on. advance/distance were the only +algorithms I could find, and that wording is no clearer.] +
+ +Proposed resolution:
@@ -5091,7 +5293,7 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly
Partition is a "foundation" algorithm useful in many contexts (like sorting as just one example) - my motivation for extending it to include forward -iterators is slist - without this extension you can't partition an slist +iterators is foward_list - without this extension you can't partition an foward_list (without writing your own partition). Holes like this in the standard library weaken the argument for generic programming (ideally I'd be able to provide a library that would refine std::partition() to other concepts @@ -5112,8 +5314,8 @@ mailing.]
502. Proposition: Clarification of the interaction between a facet and an iterator
-Section: 22.1.1.1.1 [locale.category] Status: Open - Submitter: Christopher Conrade Zseleghovski Date: 2005-06-07
+Section: 22.3.1.1.1 [locale.category] Status: Open + Submitter: Christopher Conrade Zseleghovski Opened: 2005-06-07 Last modified: 2008-03-13
View all other issues in [locale.category].
View all issues with Open status.
Discussion:
@@ -5158,8 +5360,8 @@ Bill.
503. more on locales
-Section: 22.2 [locale.categories] Status: Open - Submitter: P.J. Plauger Date: 2005-06-20
+Section: 22.4 [locale.categories] Status: Open + Submitter: P.J. Plauger Opened: 2005-06-20 Last modified: 2008-03-13
View other active issues in [locale.categories].
View all other issues in [locale.categories].
View all issues with Open status.
@@ -5270,111 +5472,10 @@ Berlin: Bill to provide wording.
-522. Tuple doesn't define swap
-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 Ready status.
-Discussion:
--Tuple doesn't define swap(). It should. -
-[ -Berlin: Doug to provide wording. -]
- -[ -Batavia: Howard to provide wording. -]
- -[ -Toronto: Howard to provide wording (really this time). -]
- - -[ -Bellevue: Alisdair provided wording. -]
- - - - -Proposed resolution:
- --Add these signatures to 20.4 [tuple] -
- -- -template <class... Types> - void swap(tuple<Types...>& x, tuple<Types...>& y); -template <class... Types> - void swap(tuple<Types...>&& x, tuple<Types...>& y); -template <class... Types> - void swap(tuple<Types...>& x, tuple<Types...>&& y); --Add this signature to 20.4.1 [tuple.tuple] -
- -- -void swap(tuple&&); --Add the following two sections to the end of the tuple clauses -
- --- - - - - - --20.3.1.7 tuple swap [tuple.swap] -
- -void swap(tuple&& rhs); -- --- --Requires: Each type in Types shall be Swappable. -
--Effects: Calls swap for each element in *this and its corresponding element -in rhs. -
--Throws: Nothing, unless one of the element-wise swap calls throw an -exception. -
--20.3.1.8 tuple specialized algorithms [tuple.special] -
- -template <class... Types> - void swap(tuple<Types...>& x, tuple<Types...>& y); -template <class... Types> - void swap(tuple<Types...>&& x, tuple<Types...>& y); -template <class... Types> - void swap(tuple<Types...>& x, tuple<Types...>&& y); -- ----Effects: x.swap(y) -
-
523. regex case-insensitive character ranges are unimplementable as specified
Section: 28 [re] Status: Open - Submitter: Eric Niebler Date: 2005-07-01
+ Submitter: Eric Niebler Opened: 2005-07-01 Last modified: 2008-03-13 +View other active issues in [re].
View all other issues in [re].
View all issues with Open status.
Discussion:
@@ -5506,8 +5607,8 @@ Pete: Possible general problem with case insensitive ranges.
539. partial_sum and adjacent_difference should mention requirements
-Section: 26.6.3 [partial.sum] Status: Open - Submitter: Marc Schoolderman Date: 2006-02-06
+Section: 26.7.3 [partial.sum] Status: Open + Submitter: Marc Schoolderman Opened: 2006-02-06 Last modified: 2009-05-10
View all issues with Open status.
Discussion:
@@ -5678,21 +5779,48 @@ the accumulator must be the input_iterator's value_type, the w should specify it.
[ +2009-05-09 Alisdair adds: +]
-Proposed resolution:
+--Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: +Now that we have the facility, the 'best' accumulator type could probably be +deduced as:
- --The type of *first shall meet the requirements of CopyConstructible? -(20.1.3?) and Assignable (23.1?) types. The result of *i + *(i+1) or ++ + + ++std::common_type<InIter::value_type, OutIter::reference>::type ++This type would then have additional requirements of constructability and +incrementability/assignability. +
++If this extracting an accumulator type from a pair/set of iterators (with +additional requirements on that type) is a problem for multiple functions, +it might be worth extracting into a SharedAccumulator concept or similar. +
++I'll go no further in writing up wording now, until the group gives a +clearer indication of preferred direction. +
+Proposed resolution:
++Add to section 26.7.3 [partial.sum] paragraph 4 the following two sentences: +
+ ++The type of *first shall meet the requirements of CopyConstructible? +(20.1.3?) and Assignable (23.1?) types. The result of *i + *(i+1) or binary_op(*i, *(i+1)) shall be convertible to this type.-Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: +Add to section 26.7.4 [adjacent.difference] paragraph 2 the following sentence:
@@ -5708,7 +5836,7 @@ The type of *first shall meet the requirements of CopyConstructible
546. _Longlong and _ULonglong are integer types
Section: TR1 5.1.1 [tr.rand.req] Status: Open - Submitter: Matt Austern Date: 2006-01-10
+ Submitter: Matt Austern Opened: 2006-01-10 Last modified: 2007-10-09View all issues with Open status.
Discussion:
@@ -5733,70 +5861,9 @@ list, so that people may use long long as a hash key.
-556. is Compare a BinaryPredicate?
-Section: 25.3 [alg.sorting] Status: Open - Submitter: Martin Sebor Date: 2006-02-05
-View all other issues in [alg.sorting].
-View all issues with Open status.
-Discussion:
--In 25, p8 we allow BinaryPredicates to return a type that's convertible -to bool but need not actually be bool. That allows predicates to return -things like proxies and requires that implementations be careful about -what kinds of expressions they use the result of the predicate in (e.g., -the expression in if (!pred(a, b)) need not be well-formed since the -negation operator may be inaccessible or return a type that's not -convertible to bool). -
--Here's the text for reference: -
-- -- ...if an algorithm takes BinaryPredicate binary_pred as its argument - and first1 and first2 as its iterator arguments, it should work - correctly in the construct if (binary_pred(*first1, first2)){...}. -
-In 25.3, p2 we require that the Compare function object return true -of false, which would seem to preclude such proxies. The relevant text -is here: -
-- - -- Compare is used as a function object which returns true if the first - argument is less than the second, and false otherwise... -
Proposed resolution:
--I think we could fix this by rewording 25.3, p2 to read somthing like: -
-- - ---2- Compare is
used as a function object which returns -true if the first argumenta BinaryPredicate. The -return value of the function call operator applied to an object of type -Compare, when converted to type bool, yields true -if the first argument of the call is less than the second, and -false otherwise. Compare comp is used throughout for -algorithms assuming an ordering relation. It is assumed that comp -will not apply any non-constant function through the dereferenced iterator. -[ -Portland: Jack to define "convertible to bool" such that short circuiting isn't -destroyed. -]
- - - - - -
564. stringbuf seekpos underspecified
-Section: 27.7.1.4 [stringbuf.virtuals] Status: Open - Submitter: Martin Sebor Date: 2006-02-23
+Section: 27.8.1.4 [stringbuf.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2006-02-23 Last modified: 2007-10-10
View all other issues in [stringbuf.virtuals].
View all issues with Open status.
Discussion:
@@ -5857,8 +5924,8 @@ plugs the hole by specifying seekpos() in terms of seekoff().
565. xsputn inefficient
-Section: 27.5.2.4.5 [streambuf.virt.put] Status: Open - Submitter: Martin Sebor Date: 2006-02-23
+Section: 27.6.2.4.5 [streambuf.virt.put] Status: Open + Submitter: Martin Sebor Opened: 2006-02-23 Last modified: 2007-10-09
View all issues with Open status.
Discussion:
@@ -5929,9 +5996,9 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open
568. log2 overloads missing
-Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New - Submitter: Paolo Carlini Date: 2006-03-07
-View all issues with New status.
+Section: TR1 8.16.4 [tr.c99.cmath.over] Status: Tentatively NAD + Submitter: Paolo Carlini Opened: 2006-03-07 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
Discussion:
log2 is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1. @@ -5941,6 +6008,15 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
+[ +Batavia (2009-05): +]
+ ++We agree this has been fixed in the Working Draft. +Move to NAD. ++Proposed resolution:
@@ -5953,8 +6029,8 @@ Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
573. C++0x file positioning should handle modern file sizes
-Section: 27.4.3 [fpos] Status: Open - Submitter: Beman Dawes Date: 2006-04-12
+Section: 27.5.3 [fpos] Status: Open + Submitter: Beman Dawes Opened: 2006-04-12 Last modified: 2007-10-09
View all other issues in [fpos].
View all issues with Open status.
Discussion:
@@ -6007,10 +6083,10 @@ these definitions are horrible. Proposed Disposition: Open
580. unused allocator members
-Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Martin Sebor Date: 2006-06-14
-View other active issues in [allocator.requirements].
-View all other issues in [allocator.requirements].
+Section: 23.2.1 [container.requirements.general] Status: Open + Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2009-05-01
+View other active issues in [container.requirements.general].
+View all other issues in [container.requirements.general].
View all issues with Open status.
Duplicate of: 479
Discussion:
@@ -6051,12 +6127,29 @@ Batavia: We support this resolution. Martin to provide wording. pre-Oxford: Martin provided wording. ] + +[ +2009-04-28 Pablo adds: +]
+ + ++N2554 +(scoped allocators), +N2768 +(allocator concepts), and +N2810 +(allocator defects), address all of these points EXCEPT max_size(). +So, I would add a note to that affect and re-class the defect as belonging +to section 23.2.1 [container.requirements.general]. ++Proposed resolution:
-Specifically, I propose to change 23.1 [container.requirements], +Specifically, I propose to change 23.2 [container.requirements], p9 as follows:
@@ -6146,11 +6239,13 @@ post Oxford: This would be rendered NAD Editorial by acceptance of
582. specialized algorithms and volatile storage
-Section: 20.7.10.1 [uninitialized.copy] Status: Open - Submitter: Martin Sebor Date: 2006-06-14
+Section: 20.8.11.2 [uninitialized.copy] Status: Open + Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2009-03-14
View all other issues in [uninitialized.copy].
View all issues with Open status.
Discussion:
+ +Related to 1029
The specialized algorithms [lib.specialized.algorithms] are specified @@ -6271,8 +6366,8 @@ effect by means of function template overloading.
585. facet error reporting
-Section: 22.2 [locale.categories] Status: Open - Submitter: Martin Sebor, Paolo Carlini Date: 2006-06-22
+Section: 22.4 [locale.categories] Status: Open + Submitter: Martin Sebor, Paolo Carlini Opened: 2006-06-22 Last modified: 2007-10-09
View other active issues in [locale.categories].
View all other issues in [locale.categories].
View all issues with Open status.
@@ -6393,8 +6488,8 @@ Proposed Disposition: Open
588. requirements on zero sized tr1::arrays and other details
-Section: 23.2.1 [array] Status: Open - Submitter: Gennaro Prota Date: 2006-07-18
+Section: 23.3.1 [array] Status: Open + Submitter: Gennaro Prota Opened: 2006-07-18 Last modified: 2009-05-30
View other active issues in [array].
View all other issues in [array].
View all issues with Open status.
@@ -6527,6 +6622,37 @@ it relies on table 80: "size() of the largest possible container" which, again, doesn't seem to consider fixed size containers +[ +2009-05-29 Daniel adds: +]
+ + ++++
+- +
++star bullet 1 ("what's the effect of calling assign(T&) on a +zero-sized array?[..]"); +
++assign has been renamed to fill and the semantic of fill is now +defined in terms of +the free algorithm fill_n, which is well-defined for this situation. ++- +
++star bullet 3 ("it would be desiderable to have a static const data +member..."): +
++It seems that tuple_size<array<T, N> >::value as of 23.3.1.7 [array.tuple] does +provide this functionality now. ++Proposed resolution:
@@ -6546,7 +6672,7 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open
597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.
Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Daveed Vandevoorde Date: 2006-04-05
+ Submitter: Daveed Vandevoorde Opened: 2006-04-05 Last modified: 2009-05-01View other active issues in [trdec.types.types].
View all other issues in [trdec.types.types].
View all issues with Open status.
@@ -6566,16 +6692,16 @@ Here is an example:- struct S { - S(_Decimal32 const&); // Converting constructor - }; - void f(S); + struct S { + S(_Decimal32 const&); // Converting constructor + }; + void f(S); - void f(_Decimal64); + void f(_Decimal64); - void g(_Decimal32 d) { - f(d); - } + void g(_Decimal32 d) { + f(d); + }@@ -6635,7 +6761,7 @@ C-to-C++ compatibility, since neither example can be expressed in C.+
606. Decimal: allow narrowing conversions
Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Martin Sebor Date: 2006-06-15
+ Submitter: Martin Sebor Opened: 2006-06-15 Last modified: 2007-01-15View other active issues in [trdec.types.types].
View all other issues in [trdec.types.types].
View all issues with Open status.
@@ -6694,8 +6820,8 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
614. std::string allocator requirements still inconsistent
-Section: 21.3 [basic.string] Status: Open - Submitter: Bo Persson Date: 2006-12-05
+Section: 21.4 [basic.string] Status: Open + Submitter: Bo Persson Opened: 2006-12-05 Last modified: 2008-03-12
View other active issues in [basic.string].
View all other issues in [basic.string].
View all issues with Open status.
@@ -6737,7 +6863,7 @@ rules (substr, operator+, etc.). Howard to supply wording.[ Bo adds: The new container constructor which takes only a size_type is not -consistent with 23.1 [container.requirements], p9 which says in part: +consistent with 23.2 [container.requirements], p9 which says in part:
- - -All other constructors for these container types take an @@ -6766,24 +6892,24 @@ post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
617. std::array is a sequence that doesn't satisfy the sequence requirements?
-Section: 23.2.1 [array] Status: Open - Submitter: Bo Persson Date: 2006-12-30
+Section: 23.3.1 [array] Status: Open + Submitter: Bo Persson Opened: 2006-12-30 Last modified: 2008-03-14
View other active issues in [array].
View all other issues in [array].
View all issues with Open status.
Discussion:
-The <array> header is given under 23.2 [sequences]. -23.2.1 [array]/paragraph 3 says: +The <array> header is given under 23.3 [sequences]. +23.3.1 [array]/paragraph 3 says:
"Unless otherwise specified, all array operations are as described in -23.1 [container.requirements]". +23.2 [container.requirements]".
-However, array isn't mentioned at all in section 23.1 [container.requirements]. +However, array isn't mentioned at all in section 23.2 [container.requirements]. In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) -that std::array does not have in 23.2.1 [array]. +that std::array does not have in 23.3.1 [array].
Also, Table 83 "Optional sequence operations" lists several operations that @@ -6800,110 +6926,154 @@ std::array does have, but array isn't mentioned.
-629. complex
-insertion and locale dependence Section: 26.3.6 [complex.ops] Status: Ready - Submitter: Gabriel Dos Reis Date: 2007-01-28
-View all other issues in [complex.ops].
-View all issues with Ready status.
+625. mixed up Effects and Returns clauses
+Section: 17 [library] Status: Open + Submitter: Martin Sebor Opened: 2007-01-20 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
Discussion:
--is there an issue opened for (0,3) as complex number with -the French local? With the English local, the above parses as an -imaginery complex number. With the French locale it parses as a -real complex number. +
+ +Many member functions of
basic_string
are overloaded, +with some of the overloads taking astring
argument, +othersvalue_type*
, otherssize_type
, and +others stilliterators
. Often, the requirements on one of +the overloads are expressed in the form of Effects, +Throws, and in the Working Paper +(N2134) +also Remark clauses, while those on the rest of the overloads +via a reference to this overload and using a Returns clause.-Further notes/ideas from the lib-reflector, messages 17982-17984: +The difference between the two forms of specification is that per +17.5.1.4 [structure.specifications], p3, an Effects clause specifies +"actions performed by the functions," i.e., its observable +effects, while a Returns clause is "a description of the +return value(s) of a function" that does not impose any +requirements on the function's observable effects.
---Add additional entries in num_punct to cover the complex separator (French would be ';'). +Since only Notes are explicitly defined to be informative and +all other paragraphs are explicitly defined to be normative, like +Effects and Returns, the new Remark clauses also +impose normative requirements.
+-Insert a space before the comma, which should eliminate the ambiguity. +So by this strict reading of the standard there are some member +functions of
+basic_string
that are required to throw an +exception under some conditions or use specific traits members while +many other otherwise equivalent overloads, while obliged to return the +same values, aren't required to follow the exact same requirements +with regards to the observable effects.-Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. +Here's an example of this problem that was precipitated by the change +from informative Notes to normative Remarks (presumably made to +address 424):
-[ -Bellevue: -]
++In the Working Paper,
+find(string, size_type)
contains a +Remark clause (which is just a Note in the current +standard) requiring it to usetraits::eq()
. ++
-find(const charT *s, size_type pos)
is specified to +returnfind(string(s), pos)
by a Returns clause +and so it is not required to usetraits::eq()
. However, +the Working Paper has replaced the original informative Note +about the function usingtraits::length()
with a +normative requirement in the form of a Remark. Calling +traits::length()
may be suboptimal, for example when the +argument is a very long array whose initial substring doesn't appear +anywhere in*this
. ++I believe a careful review of the current Effects and +Returns clauses is needed in order to identify all such +problematic cases. In addition, a review of the Working Paper should +be done to make sure that the newly introduced normative Remark +clauses do not impose any undesirable normative requirements in place +of the original informative Notes. +-After much discussion, we agreed on the following: Add a footnote: +Here's another similar example, one that existed even prior to the +introduction of Remarks:
+-[In a locale in which comma is being used as a decimal point character, -inserting "showbase" into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] +
+insert(size_type pos, string, size_type, size_type)
is +required to throwout_of_range
ifpos > +size()
.-And move this to READY status. +
insert(size_type pos, string str)
is specified to return +insert(pos, str, 0, npos)
by a Returns clause and +so its effects whenpos > size()
are strictly speaking +unspecified. ++
-[ -Pre-Sophia Antipolis, Howard adds: +Batavia: Alan and Pete to work. ]
--Changed "showbase" to "showpoint" and changed from Ready to Review. -+[ +Bellevue: Marked as NAD Editorial. +]
+[ Post-Sophia Antipolis: +Martin indicates there is still work to be done on this issue. +Reopened. ]
+[ +Batavia (2009-05): +]
+---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. -
+Tom proposes we say that, unless specified otherwise, +it is always the caller's responsibility to verify that supplied arguments +meet the called function's requirements. +If further semantics are specified +(e.g., that the function throws under certain conditions), +then it is up to the implementer to check those conditions. +Alan feels strongly that our current use of Requires in this context +is confusing, especially now that requires is a new keyword.Proposed resolution:
-Add a footnote to 26.3.6 [complex.ops] p16:
--[In a locale in which comma is being used as a decimal point character, -inserting showpoint into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] --
630. arrays of valarray
-Section: 26.5.2.1 [valarray.cons] Status: Open - Submitter: Martin Sebor Date: 2007-01-28
+Section: 26.6.2.1 [valarray.cons] Status: Open + Submitter: Martin Sebor Opened: 2007-01-28 Last modified: 2008-06-02
View other active issues in [valarray.cons].
View all other issues in [valarray.cons].
View all issues with Open status.
Discussion:
-Section 26.1 [numeric.requirements], p1 suggests that a +Section 26.2 [numeric.requirements], p1 suggests that a
valarray
specialization on a typeT
that satisfies the requirements enumerated in the paragraph is itself a valid type on whichvalarray
may be instantiated @@ -6930,7 +7100,7 @@ Stated more generally, the problem is thatvalarray<valarray<T> >::resize(size_t)
isn't required or guaranteed to have well-defined semantics for every typeT
that satisfies all requirements in -26.1 [numeric.requirements]. +26.2 [numeric.requirements].@@ -6982,7 +7152,7 @@ If no proposed wording by June meeting, this issue should be closed NAD.
Proposed resolution:
-Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows:
@@ -7020,7 +7190,7 @@ text:-Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4: +Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
@@ -7042,7 +7212,7 @@ prefers the original proposed resolution:-Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows:
@@ -7060,7 +7230,7 @@ Change 26.5.2.2 [valarray.assign], p1 as follows:-Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after +Add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
@@ -7087,95 +7257,9 @@ which you can assign to a valarray of size 0, but not to any other
-631. conflicting requirements for BinaryPredicate
-Section: 25 [algorithms] Status: Open - Submitter: James Kanze Date: 2007-01-31
-View all other issues in [algorithms].
-View all issues with Open status.
-Discussion:
--The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for -some functions. In particular, it says that: -
- -- --[...] if an algorithm takes BinaryPredicate binary_pred -as its argument and first1 and first2 as its -iterator arguments, it should work correctly in the construct if -(binary_pred (*first1 , *first2 )){...}. -BinaryPredicate always takes the first iterator type as its -first argument, that is, in those cases when T value is -part of the signature, it should work correctly in the context of if -(binary_pred (*first1 , value)){...}. -
-In the description of upper_bound (25.3.3.2 [upper.bound]/2), however, the use is described as -"!comp(value, e)", where e is an -element of the sequence (a result of dereferencing -*first). -
- --In the description of lexicographical_compare, we have both -"*first1 < *first2" and "*first2 -< *first1" (which presumably implies "comp( -*first1, *first2 )" and "comp( *first2, -*first1 )". -
- -[ -Toronto: Moved to Open. ConceptGCC seems to get lower_bound -and upper_bound to work withoutt these changes. -]
- - - - -Proposed resolution:
--Logically, the BinaryPredicate is used as an ordering -relationship, with the semantics of "less than". Depending on the -function, it may be used to determine equality, or any of the inequality -relationships; doing this requires being able to use it with either -parameter first. I would thus suggest that the requirement be: -
- -- --[...] BinaryPredicate always takes the first iterator -value_type as one of its arguments, it is unspecified which. If -an algorithm takes BinaryPredicate binary_pred as its -argument and first1 and first2 as its -iterator arguments, it should work correctly both in the construct -if (binary_pred (*first1 , *first2 )){...} and -if (binary_pred (*first2, *first1)){...}. In -those cases when T value is part of the signature, it -should work correctly in the context of if (binary_pred -(*first1 , value)){...} and of if (binary_pred -(value, *first1)){...}. [Note: if the two -types are not identical, and neither is convertable to the other, this -may require that the BinaryPredicate be a functional object -with two overloaded operator()() functions. --end note] -
-Alternatively, one could specify an order for each function. IMHO, this -would be more work for the committee, more work for the implementors, -and of no real advantage for the user: some functions, such as -lexicographical_compare or equal_range, will still require both -functions, and it seems like a much easier rule to teach that both -functions are always required, rather than to have a complicated list of -when you only need one, and which one. -
- - - - - -
632. Time complexity of size() for std::set
-Section: 23.1 [container.requirements] Status: Open - Submitter: Lionel B Date: 2007-02-01
+Section: 23.2 [container.requirements] Status: Open + Submitter: Lionel B Opened: 2007-02-01 Last modified: 2009-05-23
View other active issues in [container.requirements].
View all other issues in [container.requirements].
View all issues with Open status.
@@ -7221,13 +7305,6 @@ for std::set is not documented... but if it is it's certainly well hidden away.Proposed resolution:
--
- -[ Kona (2007): This issue affects all the containers. We'd love to see a paper dealing with the broad issue. We think that the complexity of the @@ -7247,19 +7324,36 @@ invalidated. Alan to provide wording that toughens wording, but that does not absolutely mandate O(1).
[ +Batavia (2009-05): +]
+ ++We observed that the wording "should" (in note a) has no effect. +Howard prefers that O(1) size be mandated. +It is not clear that this issue can be resolved to everyone's satisfaction, +but Alan will provide wording nonetheless. ++ + +Proposed resolution:
++
+ +
635. domain of allocator::address
-Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-02-08
+Section: X [allocator.requirements] Status: Open + Submitter: Howard Hinnant Opened: 2007-02-08 Last modified: 2009-05-01
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with Open status.
Discussion:
-The table of allocator requirements in 20.1.2 [allocator.requirements] describes +The table of allocator requirements in X [allocator.requirements] describes allocator::address as:
+a.address(r) @@ -7299,11 +7393,31 @@ Mandating that allocator::address can only be called for values which t allocator allocated seems overly restrictive. +[ +post San Francisco: +]
+ + ++Pablo recommends NAD Editorial, solved by +N2768. ++ +[ +2009-04-28 Pablo adds: +]
+ + ++Tentatively-ready NAD Editorial as fixed by +N2768. ++Proposed resolution:
-Change 20.1.2 [allocator.requirements]: +Change X [allocator.requirements]:
@@ -7335,15 +7449,17 @@ no resolution to this issue was recorded. Moved to Open.+
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.
+Section: 20.7.16.2 [func.wrap.func] Status: Tentatively NAD + Submitter: Bo Persson Opened: 2007-02-25 Last modified: 2009-05-23
+View other active issues in [func.wrap.func].
+View all other issues in [func.wrap.func].
+View all issues with Tentatively NAD status.
Discussion:
-X [func.wrap.func.undef] +20.7.16.2 [func.wrap.func]
-The note in paragraph 2 refers to 'undefined void operators', while the +The note in paragraph 2 refers to 'undefined void operators', while the section declares a pair of operators returning bool.
@@ -7358,23 +7474,65 @@ changed from private to deleted. The two issues stepped on each other. What do type of these deleted functions to be?[ +2009-05-02 Daniel adds: +]
+ + +++ ++I suggest harmonizing this issue with similar classes. E.g. in +20.8.13.3 [util.smartptr.weak] bool return values for +
++ +template <class Y> bool operator<(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator>(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete; ++are used and basically all newer provided deleted copy assignment operators +of type X use the canonical return type X& instead of void. Since the note +mentioned in the issue description has now already been changed to +
++deleted overloads close possible hole in the type system +++it seems to be of even lesser need to perform the change. Therefore +I recommend declaring the issue as NAD. +
+[ +Batavia (2009-05): +]
+ +++We agree with Daniel's recommendation. +
++Move to NAD. +
+Proposed resolution:
-Change 20.6.15.2 [func.wrap.func] +Change 20.7.16.2 [func.wrap.func]
... private: - // X [func.wrap.func.undef], undefined operators: + // 20.7.16.2 [func.wrap.func], undefined operators: template<class Function2>boolvoid operator==(const function<Function2>&); template<class Function2>boolvoid operator!=(const function<Function2>&); };-Change X [func.wrap.func.undef] +Change 20.7.16.2 [func.wrap.func]
+template<class Function2>boolvoid operator==(const function<Function2>&); @@ -7387,8 +7545,8 @@ template<class Function2>boolvoid operator!=(const
659. istreambuf_iterator should have an operator->()
-Section: 24.5.3 [istreambuf.iterator] Status: Open - Submitter: Niels Dekker Date: 2007-03-25
+Section: 24.6.3 [istreambuf.iterator] Status: Open + Submitter: Niels Dekker Opened: 2007-03-25 Last modified: 2009-05-30
View all other issues in [istreambuf.iterator].
View all issues with Open status.
Discussion:
@@ -7433,37 +7591,6 @@ I hope that the resolution of this issue will contribute to getting a clear and consistent definition of iterator concepts. - -Proposed resolution:
--Add to the synopsis in 24.5.3 [istreambuf.iterator]: -
- -- -charT operator*() const; -pointer operator->() const; -istreambuf_iterator<charT,traits>& operator++(); --Change 24.5.3 [istreambuf.iterator], p1: -
- -- - --The class template istreambuf_iterator reads successive -characters from the streambuf for which it was constructed. -operator* provides access to the current input character, if -any. operator-> may return a proxy. Each time -operator++ is evaluated, the iterator advances to the next -input character. If the end of stream is reached -(streambuf_type::sgetc() returns traits::eof()), the -iterator becomes equal to the end of stream iterator value. The default -constructor istreambuf_iterator() and the constructor -istreambuf_iterator(0) both construct an end of stream iterator -object suitable for use as an end-of-range. -
[ Kona (2007): The proposed resolution is inconsistent because the return type of istreambuf_iterator::operator->() is specified to be pointer, @@ -7498,25 +7625,112 @@ is just: istreambuf_iterator should have an operator->()!
[ +2009-04-30 Alisdair adds: +]
++Note that operator-> is now a requirement in the InputIterator concept, so +this issue cannot be ignored or existing valid programs will break when +compiled with an 0x library. +-
+[ +2009-05-29 Alisdair adds: +]
+ + +++ + ++I agree with the observation that in principle the type 'pointer' may be a +proxy, and the words highlighting this are redundant. +
++However, in the current draught pointer is required to be exactly 'charT *' +by the derivation from std::iterator. At a minimum, the 4th parameter of +this base class template should become unspecified. That permits the +introduction of a proxy as a nested class in some further undocumented (not +even exposition-only) base. +
++It also permits the istream_iterator approach where the cached value is +stored in the iterator itself, and the iterator serves as its own proxy for +post-increment operator++ - removing the need for the existing +exposition-only nested class proxy. +
++Note that the current proxy class also has exactly the right properties to +serve as the pointer proxy too. This is likely to be a common case where an +InputIterator does not hold internal state but delegates to another class. +
++Proposed Resolution: +
++In addition to the current proposal: +
++24.6.3 [istreambuf.iterator] +
++template<class charT, class traits = char_traits<charT> > +class istreambuf_iterator + : public iterator<input_iterator_tag, charT, + typename traits::off_type,charT*unspecified, charT> { +Proposed resolution:
++Add to the synopsis in 24.6.3 [istreambuf.iterator]: +
+ ++ +charT operator*() const; +pointer operator->() const; +istreambuf_iterator<charT,traits>& operator++(); ++Change 24.6.3 [istreambuf.iterator], p1: +
+ ++ + + + + + + ++The class template istreambuf_iterator reads successive +characters from the streambuf for which it was constructed. +operator* provides access to the current input character, if +any. operator-> may return a proxy. Each time +operator++ is evaluated, the iterator advances to the next +input character. If the end of stream is reached +(streambuf_type::sgetc() returns traits::eof()), the +iterator becomes equal to the end of stream iterator value. The default +constructor istreambuf_iterator() and the constructor +istreambuf_iterator(0) both construct an end of stream iterator +object suitable for use as an end-of-range. +
667. money_get's widened minus sign
-Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16
+Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD + Submitter: Thomas Plum Opened: 2007-04-16 Last modified: 2009-05-23
View other active issues in [locale.money.get.virtuals].
View all other issues in [locale.money.get.virtuals].
-View all issues with Open status.
+View all issues with Tentatively NAD status.
Discussion:
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says: +22.4.6.1.2 [locale.money.get.virtuals], para 1 says:
@@ -7561,6 +7775,16 @@ which are translated by ct.widen(c) calls before being stored in di the widened characters are not relevant to the parsing of the subject string.-The result is returned as an integral value -stored in units or as a sequence of digits possibly preceded by a -minus sign (as produced by ct.widen(c) where c is '-' or in the range +The result is returned as an integral value +stored in units or as a sequence of digits possibly preceded by a +minus sign (as produced by ct.widen(c) where c is '-' or in the range from '0' through '9', inclusive) stored in digits.
[ +Batavia (2009-05): +]
+ ++We agree with Bill's comment above, +in line with the first of the interpretations offered in the issue. +Move to NAD. ++Proposed resolution:
@@ -7572,30 +7796,29 @@ the widened characters are not relevant to the parsing of the subject string.
668. money_get's empty minus sign
-Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16
+Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD + Submitter: Thomas Plum Opened: 2007-04-16 Last modified: 2009-05-23
View other active issues in [locale.money.get.virtuals].
View all other issues in [locale.money.get.virtuals].
-View all issues with Open status.
+View all issues with Tentatively NAD status.
Discussion:
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says: +22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
If pos or neg is empty, the sign component is -optional, and if no sign is detected, the result is given the sign +optional, and if no sign is detected, the result is given the sign that corresponds to the source of the empty string.
-The following -objection has been raised: +The following objection has been raised:
@@ -7608,52 +7831,108 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor ] +-A negative_sign of "" means "there is no -way to write a negative sign" not "any null sequence is a negative +A negative_sign of "" means "there is no +way to write a negative sign" not "any null sequence is a negative sign, so it's always there when you look for it".
+Related to 669. +
+[ +2009-05-17 Howard adds: +]
-Proposed resolution:
+ ++I disagree that a negative_sign of "" means "there is no +way to +write a negative sign". The meaning requires the sentences of +22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above +to be +taken into account:
++-3- ... If pos or neg is empty, the sign component is +optional, and if no sign is detected, the result is given the sign that +corresponds to the source of the empty string. Otherwise, the character +in the indicated position must match the first character of pos +or neg, and the result is given the corresponding sign. If the +first character of pos is equal to the first character of +neg, or if both strings are empty, the result is given a +positive sign. +++So a negative_sign of "" means "there is no way to write a +negative sign" only when positive_sign is also "". However +when negative_sign is "" and postive_sign.size() > +0, then one writes a negative value by not writing the +postive_sign in the position indicated by +money_base::sign. +For example: +
+- -pattern = {symbol, sign, value, none} +positive_sign = "+" +negative_sign = "" +$123 // a negative value, using optional sign +$+123 // a positive value +$-123 // a parse error +
-669. Equivalent postive and negative signs in money_get
-Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16
-View other active issues in [locale.money.get.virtuals].
-View all other issues in [locale.money.get.virtuals].
-View all issues with Open status.
-Discussion:
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says: +And:
-+-If the first character of pos is equal to the first character of neg, -or if both strings are empty, the result is given a positive sign. -
+pattern = {symbol, sign, value, none} +positive_sign = "" +negative_sign = "" +$123 // a positive value, no sign possible +$+123 // a parse error +$-123 // a parse error +-One interpretation is that an input sequence must match either the -positive pattern or the negative pattern, and then in either event it -is interpreted as positive. The following objections has been raised: +And (regarding 669):
-+-The input can successfully match only a positive sign, so the negative -pattern is an unsuccessful match. -
+pattern = {symbol, sign, value, none} +positive_sign = "-" +negative_sign = "-" +$123 // a parse error, sign is mandatory +$+123 // a parse error +$-123 // a positive value +-[Plum ref _222612Y34, 222612Y51b] +The text seems both unambiguous and clear to me. I recommend NAD for +both this issue and 669. However I would have no +objection to adding examples such as those above.
+[ -Bill to provide proposed wording and interpretation of existing wording. +Batavia (2009-05): ]
++@@ -7666,42 +7945,65 @@ Bill to provide proposed wording and interpretation of existing wording.+This discussion applies equally to issue 669 (q.v.). +Howard has added examples above, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +
++Alan would like to rewrite paragraph 3. +
++We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue 669 be handled identically. +
+
-670. money_base::pattern and space
-Section: 22.2.6.3 [locale.moneypunct] Status: Open - Submitter: Thomas Plum Date: 2007-04-16
-View all issues with Open status.
-Duplicate of: 836
+669. Equivalent postive and negative signs in money_get
+Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Tentatively NAD + Submitter: Thomas Plum Opened: 2007-04-16 Last modified: 2009-05-23
+View other active issues in [locale.money.get.virtuals].
+View all other issues in [locale.money.get.virtuals].
+View all issues with Tentatively NAD status.
Discussion:
- --22.2.6.3 [locale.moneypunct], para 2 says: +22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
-The value space indicates that at least one space is required at -that position. +If the first character of pos is equal to the first character of neg, +or if both strings are empty, the result is given a positive sign.
-The following objection has been raised: +One interpretation is that an input sequence must match either the +positive pattern or the negative pattern, and then in either event it +is interpreted as positive. The following objections has been raised:
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) +The input can successfully match only a positive sign, so the negative +pattern is an unsuccessful match.
-[Plum ref _22263Y22] +[Plum ref _222612Y34, 222612Y51b]
[ -Kona (2007): Bill to provide proposed wording. We agree that C++03 is -ambiguous, and that we want C++0X to say "space" means 0 or more -whitespace characters on input. +Bill to provide proposed wording and interpretation of existing wording. +]
+ + +[ +2009-05-17 See Howard's comments in related issue 668. ]
+[ +Batavia (2009-05): +]
+ +++This discussion applies equally to issue 668 (q.v.). +Howard has added examples there, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +
++We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue 668 be handled identically. +
+Proposed resolution:
@@ -7714,8 +8016,8 @@ whitespace characters on input.
671. precision of hexfloat
-Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open - Submitter: John Salmon Date: 2007-04-20
+Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: Open + Submitter: John Salmon Opened: 2007-04-20 Last modified: 2009-03-12
View all other issues in [facet.num.put.virtuals].
View all issues with Open status.
Discussion:
@@ -7729,7 +8031,7 @@ As far as I can tell, it does so via the following: 8.15 Additions to header <locale> [tr.c99.locale]-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after +In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line: floatfield == ios_base::scientific %E
@@ -7744,10 +8046,10 @@ floatfield == ios_base::fixed | ios_base::scientific %A 2 in this clause, ensure that the print functions generate hexadecimal floating-point fields with a %a or %A conversion specifier, and that the scan functions match hexadecimal floating-point fields with a %g -conversion specifier. end note] +conversion specifier. end note]-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find: +Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
For conversion from a floating-point type, if (flags & fixed) != 0 or @@ -7757,16 +8059,16 @@ conversion specification.
This would seem to imply that when floatfield == fixed|scientific, the precision of the conversion specifier is to be taken from -str.precision(). Is this really what's intended? I sincerely hope -that I'm either missing something or this is an oversight. Please +str.precision(). Is this really what's intended? I sincerely hope +that I'm either missing something or this is an oversight. Please tell me that the committee did not intend to mandate that hex floats (and doubles) should by default be printed as if by %.6a.
[ Howard: I think the fundamental issue we overlooked was that with %f, -%e, %g, the default precision was always 6. With %a the default -precision is not 6, it is infinity. So for the first time, we need to +%e, %g, the default precision was always 6. With %a the default +precision is not 6, it is infinity. So for the first time, we need to distinguish between the default value of precision, and the precision value 6. ]
@@ -7788,891 +8090,639 @@ Kona (2007): Robert volunteers to propose wording.
-675. Move assignment of containers
-Section: 23.1 [container.requirements] Status: Review - Submitter: Howard Hinnant Date: 2007-05-05
-View other active issues in [container.requirements].
-View all other issues in [container.requirements].
-View all issues with Review status.
+688. reference_wrapper, cref unsafe, allow binding to rvalues
+Section: 20.7.5.1 [refwrap.const] Status: Tentatively Ready + Submitter: Peter Dimov Opened: 2007-05-10 Last modified: 2009-05-23
+View all other issues in [refwrap.const].
+View all issues with Tentatively Ready status.
Discussion:
-James Hopkin pointed out to me that if vector<T> move assignment is O(1) -(just a swap) then containers such as vector<shared_ptr<ostream>> might have -the wrong semantics under move assignment when the source is not truly an rvalue, but a -moved-from lvalue (destructors could run late). -
- -- -vector<shared_ptr<ostream>> v1; -vector<shared_ptr<ostream>> v2; -... -v1 = v2; // #1 -v1 = std::move(v2); // #2 --Move semantics means not caring what happens to the source (v2 in this example). -It doesn't mean not caring what happens to the target (v1). In the above example -both assignments should have the same effect on v1. Any non-shared ostream's -v1 owns before the assignment should be closed, whether v1 is undergoing -copy assignment or move assignment. -
- --This implies that the semantics of move assignment of a generic container should be -clear, swap instead of just swap. An alternative which could achieve the same -effect would be to move assign each element. In either case, the complexity of move -assignment needs to be relaxed to O(v1.size()). +A reference_wrapper can be constructed from an rvalue, either by using +the constructor, or via cref (and ref in some corner cases). This leads +to a dangling reference being stored into the reference_wrapper object. +Now that we have a mechanism to detect an rvalue, we can fix them to +disallow this source of undefined behavior.
-The performance hit of this change is not nearly as drastic as it sounds. -In practice, the target of a move assignment has always just been move constructed -or move assigned from. Therefore under clear, swap semantics (in -this common use case) we are still achieving O(1) complexity. +Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+[ +2009-05-09 Alisdair adds: +]
-Proposed resolution:
++-Change 23.1 [container.requirements]: +Now that ref/cref are constained that T must be an ObjectType, I do not +believe there is any risk of binding ref to a temporary (which would rely on +deducing T to be an rvalue reference type)
- --- --
-Table 89: Container requirements -- -expression return type operational semantics -assertion/note pre/post-condition complexity -- -a = rv; X& -All existing elements of a are either move assigned or destructed -a shall be equal to the -value that rv had -before this construction - -- (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.+However, the problem for cref remains, so I recommend retaining that deleted +overload.[ -post Bellevue Howard adds: +2009-05-10 Howard adds: ]
- --This issue was voted to WP in Bellevue, but accidently got stepped on by -N2525 -which was voted to WP simulataneously. Moving back to Open for the purpose of getting -the wording right. The intent of this issue and N2525 are not in conflict. +Without:
-[ -post Sophia Antipolis Howard updated proposed wording: -]
++template <class T> void ref(const T&& t) = delete; ++I believe this program will compile: +
+#include <functional> +struct A {}; +const A source() {return A();} -
-676. Moving the unordered containers
-Section: 23.4 [unord] Status: Open - Submitter: Howard Hinnant Date: 2007-05-05
-View other active issues in [unord].
-View all other issues in [unord].
-View all issues with Open status.
-Discussion:
+int main() +{ + std::reference_wrapper<const A> r = std::ref(source()); +} +-Move semantics are missing from the unordered containers. The proposed -resolution below adds move-support consistent with -N1858 -and the current working draft. +I.e. in:
+template <ObjectType T> reference_wrapper<T> ref(T& t); +-The current proposed resolution simply lists the requirements for each function. -These might better be hoisted into the requirements table for unordered associative containers. -Futhermore a mild reorganization of the container requirements could well be in order. -This defect report is purposefully ignoring these larger issues and just focusing -on getting the unordered containers "moved". +this:
++ref(source()) ++deduces T as const A, and so: +
+-ref(const A& t) +Proposed resolution:
--Add to 23.4 [unord]: +will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler). +
++Therefore I think we still need the ref-protection. I respectfully disagree with Alisdair's +comment and am in favor of the proposed wording as it stands. Also, CWG 606 +(noted below) has now been "favorably" resolved.
--template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>&& y); +template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); +[ +Batavia (2009-05): +]
-template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); ++We agree with the proposed resolution. +Move to Tentatively Ready. +-template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>&& y); +Proposed resolution:
++In 20.7 [function.objects], add the following two signatures to the synopsis: +
-template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); +-... -template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_set<Value, Hash, Pred, Alloc>& x, - unordered_set<Value, Hash, Pred, Alloc>& y); -template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_set<Value, Hash, Pred, Alloc>& x, - unordered_set<Value, Hash, Pred, Alloc>&& y); +template <class T> void ref(const T&& t) = delete; +template <class T> void cref(const T&& t) = delete; +[ +N2292 +addresses the first part of the resolution but not the second. +]
-template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, - unordered_set<Value, Hash, Pred, Alloc>& y); -template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, - unordered_multiset<Value, Hash, Pred, Alloc>& y); +[ +Bellevue: Doug noticed problems with the current wording. +]
-template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, - unordered_multiset<Value, Hash, Pred, Alloc>&& y); -template <class Value, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, - unordered_multiset<Value, Hash, Pred, Alloc>& y); -[ +post Bellevue: Howard and Peter provided revised wording. +]
-unordered_map
--Change 23.4.1 [unord.map]: -
+[ +This resolution depends on a "favorable" resolution of CWG 606: that is, +the "special deduction rule" is disabled with the const T&& pattern. +]
-+class unordered_map -{ - ... - unordered_map(const unordered_map&); - unordered_map(unordered_map&&); - ~unordered_map(); - unordered_map& operator=(const unordered_map&); - unordered_map& operator=(unordered_map&&); - ... - // modifiers -std::pair<iterator, bool> insert(const value_type& obj); - template <class P> pair<iterator, bool> insert(P&& obj); - iterator insert(iterator hint, const value_type& obj); - template <class P> iterator insert(iterator hint, P&& obj); - const_iterator insert(const_iterator hint, const value_type& obj); - template <class P> const_iterator insert(const_iterator hint, P&& obj); - ... - void swap(unordered_map&&); - ... - mapped_type& operator[](const key_type& k); - mapped_type& operator[](key_type&& k); - ... -}; -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); -
+696.
+istream::operator>>(int&)
brokenSection: 27.7.1.2.2 [istream.formatted.arithmetic] Status: Open + Submitter: Martin Sebor Opened: 2007-06-23 Last modified: 2009-05-28
+View all other issues in [istream.formatted.arithmetic].
+View all issues with Open status.
+Discussion:
-Add to 23.4.1.1 [unord.map.cnstr]: +From message c++std-lib-17897:
- ---template <class InputIterator> - unordered_map(InputIterator f, InputIterator l, - size_type n = implementation-defined, - const hasher& hf = hasher(), - const key_equal& eql = key_equal(), - const allocator_type& a = allocator_type()); -- --- -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -
-Add to 23.4.1.2 [unord.map.elem]: +The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if" +implementation of the two arithmetic extractors that don't have a +corresponding
+num_get
interface (i.e., the +short
andint
overloads) is subtly buggy in +how it deals withEOF
, overflow, and other similar +conditions (in addition to containing a few typos). ++One problem is that if
+num_get::get()
reaches the EOF +after reading in an otherwise valid value that exceeds the limits of +the narrower type (but notLONG_MIN
or +LONG_MAX
), it will seterr
to +eofbit
. Because of the if condition testing for +(err == 0)
, the extractor won't set +failbit
(and presumably, return a bogus value to the +caller). ++Another problem with the code is that it never actually sets the +argument to the extracted value. It can't happen after the call to +
-setstate()
since the function may throw, so we need to +show when and how it's done (we can't just punt as say: "it happens +afterwards"). However, it turns out that showing how it's done isn't +quite so easy since the argument is normally left unchanged by the +facet on error except when the error is due to a misplaced thousands +separator, which causesfailbit
to be set but doesn't +prevent the facet from storing the value.- -+mapped_type& operator[](const key_type& k);+[ +Batavia (2009-05): +]
--...
--Requires: key_type shall be CopyConstructible -and mapped_type shall be DefaultConstructible. -
++We believe this part of the Standard has been recently adjusted +and that this issue was addressed during that rewrite. +
++Move to NAD. +
mapped_type& operator[](key_type&& k);- --+-Effects: If the unordered_map does not already contain an -element whose key is equivalent to k , inserts the value -std::pair<const key_type, mapped_type>(std::move(k), mapped_type()). -
- --Requires: mapped_type shall be DefaultConstructible. -
- --Returns: A reference to x.second, where x is the -(unique) element whose key is equivalent to k. -
- -[ +2009-05-28 Howard adds: +]
---Add new section [unord.map.modifiers]: +I've moved this issue from Tentatively NAD to Open.
---pair<iterator, bool> insert(const value_type& x); -template <class P> pair<iterator, bool> insert(P&& x); -iterator insert(iterator hint, const value_type& x); -template <class P> iterator insert(iterator hint, P&& x); -const_iterator insert(const_iterator hint, const value_type& x); -template <class P> const_iterator insert(const_iterator hint, P&& x); -template <class InputIterator> - void insert(InputIterator first, InputIterator last); -- --- --Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -
- --P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_map. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -
- --The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -
- --Add to 23.4.1.3 [unord.map.swap]: +The current wording of +N2857 +in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that +in parsing arithmetic types, the value is always set, but sometimes in addition +to setting failbit.
--+template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, - unordered_map<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, - unordered_map<Key, T, Hash, Pred, Alloc>& y); --+
-- +If there is a range error, the value is set to min or max, else +
+- +if there is a conversion error, the value is set to 0, else +
+- +if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else +
+- +the value is set to its error-free result. +
+unordered_multimap
++However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1. +
-Change 23.4.2 [unord.multimap]: +27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals] +(whatever we decide that behavior is) for +int and short, and currently does not. I believe that the +correct code fragment should look like:
-+ +class unordered_multimap ++typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = ios_base::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +if (lval < numeric_limits<int>::min()) { - ... - unordered_multimap(const unordered_multimap&); - unordered_multimap(unordered_multimap&&); - ~unordered_multimap(); - unordered_multimap& operator=(const unordered_multimap&); - unordered_multimap& operator=(unordered_multimap&&); - ... - // modifiers - iterator insert(const value_type& obj); - template <class P> iterator insert(P&& obj); - iterator insert(iterator hint, const value_type& obj); - template <class P> iterator insert(iterator hint, P&& obj); - const_iterator insert(const_iterator hint, const value_type& obj); - template <class P> const_iterator insert(const_iterator hint, P&& obj); - ... - void swap(unordered_multimap&&); - ... -}; - -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); - -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>&& y); - -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); + err |= ios_base::failbit; + val = numeric_limits<int>::min(); +} +else if (lval > numeric_limits<int>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::max(); +} +else + val = static_cast<int>(lval); +setstate(err);Proposed resolution:
-Add to 23.4.2.1 [unord.multimap.cnstr]: +Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
-template <class InputIterator> - unordered_multimap(InputIterator f, InputIterator l, - size_type n = implementation-defined, - const hasher& hf = hasher(), - const key_equal& eql = key_equal(), - const allocator_type& a = allocator_type()); -- -+-1- Effects: Reads characters from in, interpreting them +according to str.flags(), use_facet<ctype<charT> +>(loc), and use_facet< numpunct<charT> +>(loc), where loc is str.getloc().- -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -
If an error +occurs, val is unchanged; otherwise it is set to the resulting value.-Add new section [unord.multimap.modifiers]: +Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
-+iterator insert(const value_type& x); -template <class P> iterator insert(P&& x); -iterator insert(iterator hint, const value_type& x); -template <class P> iterator insert(iterator hint, P&& x); -const_iterator insert(const_iterator hint, const value_type& x); -template <class P> const_iterator insert(const_iterator hint, P&& x); -template <class InputIterator> - void insert(InputIterator first, InputIterator last); +operator>>(short& val);--+-Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -
- --P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_multimap. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -
++-2- The conversion occurs as if performed by the following code fragment (using the same notation as for +the preceding code fragment): +
--The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -
-typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = iostate_base::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +if (err != 0) + ; +else if (lval < numeric_limits<short>::min() + || numeric_limits<short>::max() < lval) + err = ios_base::failbit;+if (lval < numeric_limits<short>::min()) +{ + err |= ios_base::failbit; + val = numeric_limits<short>::min(); +} +else if (lval > numeric_limits<short>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<short>::max(); +} +else + val = static_cast<short>(lval); +setstate(err); +operator>>(int& val); ++--Add to 23.4.2.2 [unord.multimap.swap]: +-3- The conversion occurs as if performed by the following code fragment (using the same notation as for +the preceding code fragment):
--+template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, - unordered_multimap<Key, T, Hash, Pred, Alloc>& y); ---typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = iostate_base::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +if (err != 0) + ; +else if (lval < numeric_limits<int>::min() + || numeric_limits<int>::max() < lval) + err = ios_base::failbit;+if (lval < numeric_limits<int>::min()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::min(); +} +else if (lval > numeric_limits<int>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::max(); +} +else + val = static_cast<int>(lval); +setstate(err); +unordered_set
+-Change 23.4.3 [unord.set]: -
++class unordered_set -{ - ... - unordered_set(const unordered_set&); - unordered_set(unordered_set&&); - ~unordered_set(); - unordered_set& operator=(const unordered_set&); - unordered_set& operator=(unordered_set&&); - ... - // modifiers -std::pair<iterator, bool> insert(const value_type& obj); - pair<iterator, bool> insert(value_type&& obj); - iterator insert(iterator hint, const value_type& obj); - iterator insert(iterator hint, value_type&& obj); - const_iterator insert(const_iterator hint, const value_type& obj); - const_iterator insert(const_iterator hint, value_type&& obj); - ... - void swap(unordered_set&&); - ... -}; -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, - unordered_set<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, - unordered_set<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, - unordered_set<Key, T, Hash, Pred, Alloc>& y); -
+701. assoc laguerre poly's
+Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: Tentatively NAD + Submitter: Christopher Crawford Opened: 2007-06-30 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
+Discussion:
++I see that the definition the associated Laguerre +polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since +N1687. +However, the draft standard only specifies ranks of integer value m, +while the associated Laguerre polynomials are actually valid for real +values of m > -1. In the case of non-integer values of m, the +definition Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n) +must be used, which also holds for integer values of m. See +Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for +the integer case. In fact fractional values are most commonly used in +physics, for example to m = +/- 1/2 to describe the harmonic +oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3 +dimensions. +
-Add to 23.4.3.1 [unord.set.cnstr]: +If I am correct, the calculation of the more general case is no +more difficult, and is in fact the function implemented in the GNU +Scientific Library. I would urge you to consider upgrading the +standard, either adding extra functions for real m or switching the +current ones to double.
--template <class InputIterator> - unordered_set(InputIterator f, InputIterator l, - size_type n = implementation-defined, - const hasher& hf = hasher(), - const key_equal& eql = key_equal(), - const allocator_type& a = allocator_type()); -+[ +Batavia (2009-05): +]
-+- -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - -
++ ++We understand the issue, and have opted not to extend as recommended. +
++Move to NAD. +
Proposed resolution:
-Add new section [unord.set.modifiers]:
--+pair<iterator, bool> insert(const value_type& x); -pair<iterator, bool> insert(value_type&& x); -iterator insert(iterator hint, const value_type& x); -iterator insert(iterator hint, value_type&& x); -const_iterator insert(const_iterator hint, const value_type& x); -const_iterator insert(const_iterator hint, value_type&& x); -template <class InputIterator> - void insert(InputIterator first, InputIterator last); ---+-Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -
--The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -
-
+702. Restriction in associated Legendre functions
+Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: Tentatively NAD + Submitter: Christopher Crawford Opened: 2007-06-30 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
+Discussion:
++One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be +|x| <= 1, not x >= 0.
-[ +Batavia (2009-05): +]
+- --Add to 23.4.3.2 [unord.set.swap]: +The error has been corrected in the pending IS. +
++Move to NAD.
- ---template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, - unordered_set<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, - unordered_set<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, - unordered_set<Key, T, Hash, Pred, Alloc>& y); -unordered_multiset
+Proposed resolution:
-Change 23.4.4 [unord.multiset]:
-+class unordered_multiset -{ - ... - unordered_multiset(const unordered_multiset&); - unordered_multiset(unordered_multiset&&); - ~unordered_multiset(); - unordered_multiset& operator=(const unordered_multiset&); - unordered_multiset& operator=(unordered_multiset&&); - ... - // modifiers - iterator insert(const value_type& obj); - iterator insert(value_type&& obj); - iterator insert(iterator hint, const value_type& obj); - iterator insert(iterator hint, value_type&& obj); - const_iterator insert(const_iterator hint, const value_type& obj); - const_iterator insert(const_iterator hint, value_type&& obj); - ... - void swap(unordered_multiset&&); - ... -}; -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>& y); -
+708. Locales need to be per thread and updated for POSIX changes
+Section: 22 [localization] Status: Open + Submitter: Peter Dimov Opened: 2007-07-28 Last modified: 2008-09-17
+View other active issues in [localization].
+View all other issues in [localization].
+View all issues with Open status.
+Discussion:
-Add to 23.4.4.1 [unord.multiset.cnstr]: +The POSIX "Extended API Set Part 4,"
- ---template <class InputIterator> - unordered_multiset(InputIterator f, InputIterator l, - size_type n = implementation-defined, - const hasher& hf = hasher(), - const key_equal& eql = key_equal(), - const allocator_type& a = allocator_type()); ---- -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - +http://www.opengroup.org/sib/details.tpl?id=C065
-Add new section [unord.multiset.modifiers]: +introduces extensions to the C locale mechanism that +allow multiple concurrent locales to be used in the same application +by introducing a type locale_t that is very similar to +std::locale, and a number of _l functions that make use of it.
- ---iterator insert(const value_type& x); -iterator insert(value_type&& x); -iterator insert(iterator hint, const value_type& x); -iterator insert(iterator hint, value_type&& x); -const_iterator insert(const_iterator hint, const value_type& x); -const_iterator insert(const_iterator hint, value_type&& x); -template <class InputIterator> - void insert(InputIterator first, InputIterator last); -- -- -- --Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -
- --The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -
- --Add to 23.4.4.2 [unord.multiset.swap]: +The global locale (set by setlocale) is now specified to be per- +process. If a thread does not call uselocale, the global locale is +in effect for that thread. It can install a per-thread locale by +using uselocale. +
++There is also a nice querylocale mechanism by which one can obtain +the name (such as "de_DE") for a specific facet, even for combined +locales, with no std::locale equivalent. +
++std::locale should be harmonized with the new POSIX locale_t +mechanism and provide equivalents for uselocale and querylocale.
- --- -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>&& y); -template <class Key, class T, class Hash, class Pred, class Alloc> - void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, - unordered_multiset<Key, T, Hash, Pred, Alloc>& y); --[ -Voted to WP in Bellevue. +Kona (2007): Bill and Nick to provide wording. ]
[ -post Bellevue, Pete notes: +San Francisco: Bill and Nick still intend to provide wording, but this +is a part of the task to be addressed by the group that will look into +issue 860. ]
--+-Please remind people who are reviewing issues to check that the text -modifications match the current draft. Issue 676, for example, adds two -overloads for unordered_map::insert taking a hint. One takes a -const_iterator and returns a const_iterator, and the other takes an -iterator and returns an iterator. This was correct at the time the issue -was written, but was changed in Toronto so there is only one hint -overload, taking a const_iterator and returning an iterator. -
+ + +Proposed resolution:
-This issue is not ready. In addition to the relatively minor signature -problem I mentioned earlier, it puts requirements in the wrong places. -Instead of duplicating requirements throughout the template -specifications, it should put them in the front matter that talks about -requirements for unordered containers in general. This presentation -problem is editorial, but I'm not willing to do the extensive rewrite -that it requires. Please put it back into Open status.
-
-688. reference_wrapper, cref unsafe, allow binding to rvalues
-Section: 20.6.5.1 [refwrap.const] Status: Open - Submitter: Peter Dimov Date: 2007-05-10
-View all other issues in [refwrap.const].
+711. Contradiction in empty shared_ptr
+Section: 20.8.13.2.5 [util.smartptr.shared.obs] Status: Open + Submitter: Peter Dimov Opened: 2007-08-24 Last modified: 2008-06-18
+View all other issues in [util.smartptr.shared.obs].
View all issues with Open status.
Discussion:
-A reference_wrapper can be constructed from an rvalue, either by using -the constructor, or via cref (and ref in some corner cases). This leads -to a dangling reference being stored into the reference_wrapper object. -Now that we have a mechanism to detect an rvalue, we can fix them to -disallow this source of undefined behavior. -
- --Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. +A discussion on +comp.std.c++ +has identified a contradiction in the shared_ptr specification. +The note:
+- -+[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer. +-end note ] +
Proposed resolution:
-In 20.6 [function.objects], add the following two signatures to the synopsis: +after the aliasing constructor
-template <class T> void ref(const T&& t) = delete; -template <class T> void cref(const T&& t) = delete; ++template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);+reflects the intent of +N2351 +to, well, allow the creation of an empty shared_ptr +with a non-NULL stored pointer. +
++This is contradicted by the second sentence in the Returns clause of 20.8.13.2.5 [util.smartptr.shared.obs]: +
-[ -N2292 -addresses the first part of the resolution but not the second. -]
- ++T* get() const; ++++Returns: the stored pointer. Returns a null pointer if *this is empty. +
[ -Bellevue: Doug noticed problems with the current wording. +Bellevue: ]
-[ -post Bellevue: Howard and Peter provided revised wording. -]
- +++Adopt option 1 and move to review, not ready. +
++There was a lot of confusion about what an empty shared_ptr is (the term +isn't defined anywhere), and whether we have a good mental model for how +one behaves. We think it might be possible to deduce what the definition +should be, but the words just aren't there. We need to open an issue on +the use of this undefined term. (The resolution of that issue might +affect the resolution of issue 711.) +
++The LWG is getting more uncomfortable with the aliasing proposal (N2351) +now that we realize some of its implications, and we need to keep an eye +on it, but there isn't support for removing this feature at this time. +
+[ -This resolution depends on a "favorable" resolution of CWG 606: that is, -the "special deduction rule" is disabled with the const T&& pattern. +Sophia Antipolis: ]
- - - -
-691. const_local_iterator cbegin, cend missing from TR1
-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 Ready status.
-Discussion:
+-The last version of TR1 does not include the following member -functions -for unordered containers: +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?
- --const_local_iterator cbegin(size_type n) const; -const_local_iterator cend(size_type n) const; --which looks like an oversight to me. I've checked th TR1 issues lists -and the latest working draft of the C++0x std (N2284) and haven't -found any mention to these menfuns or to their absence. +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.
-Is this really an oversight, or am I missing something? +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:
-Add the following two rows to table 93 (unordered associative container -requirements) in section 23.1.5 [unord.req]: +In keeping the N2351 spirit and obviously my preference, change 20.8.13.2.5 [util.smartptr.shared.obs]:
--
+Unordered associative container requirements (in addition to container) -- -expression return type assertion/note pre/post-condition complexity -- -b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant -- -b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant -T* get() const; +++Returns: the stored pointer.
Returns a null pointer if *this is empty.+-Add to the synopsis in 23.4.1 [unord.map]: +Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
--const_local_iterator cbegin(size_type n) const; -const_local_iterator cend(size_type n) const; --Add to the synopsis in 23.4.2 [unord.multimap]: +Change 20.8.13.2.1 [util.smartptr.shared.const]:
-- +const_local_iterator cbegin(size_type n) const; -const_local_iterator cend(size_type n) const; -+@@ -8680,456 +8730,281 @@ const_local_iterator cend(size_type n) const;template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p); +++-Add to the synopsis in 23.4.3 [unord.set]: +Requires: If r is empty, p shall be 0.
- --const_local_iterator cbegin(size_type n) const; -const_local_iterator cend(size_type n) const; --Add to the synopsis in 23.4.4 [unord.multiset]: +
- -[ Note: this constructor allows creation of an empty shared_ptr +instance with a non-NULL stored pointer. +-- end note ]+const_local_iterator cbegin(size_type n) const; -const_local_iterator cend(size_type n) const; -
-692.
-get_money
andput_money
should be formatted I/O functionsSection: 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 Review status.
+716. Production in [re.grammar] not actually modified
+Section: 28.14 [re.grammar] Status: Open + Submitter: Stephan T. Lavavej Opened: 2007-08-31 Last modified: 2009-05-23
+View all issues with Open status.
Discussion:
-In a private email Bill Plauger notes: -
---I believe that the function that implements
+ +get_money
-[from N2072] -should behave as a formatted input function, and the function that -implementsput_money
should behave as a formatted output -function. This has implications regarding the skipping of whitespace -and the handling of errors, among other things. +TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.14 [re.grammar]/3 say:--The words don't say that right now and I'm far from convinced that -such a change is editorial. -
-Martin's response: -
-+-I agree that the manipulators should handle exceptions the same way as -formatted I/O functions do. The text in N2072 assumes so but the -Returns clause explicitly omits exception handling for the sake -of brevity. The spec should be clarified to that effect. +The following productions within the ECMAScript grammar are modified as follows:
--As for dealing with whitespace, I also agree it would make sense for -the extractors and inserters involving the new manipulators to treat -it the same way as formatted I/O. -
+ +CharacterClass :: +[ [lookahead ∉ {^}] ClassRanges ] +[ ^ ClassRanges ] +Proposed resolution:
-Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the -following text: +This definition for CharacterClass appears to be exactly identical to that in ECMA-262.
-+-Effects: The expression
in >> get_money(mon, intl)
-described below behaves as a formatted input function (as -described in 27.6.1.2.1 [istream.formatted.reqmts]). --Also change p4 of 27.6.4 [ext.manip] as follows: +Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
---Returns: An object
s
of unspecified type such that -ifin
is an object of typebasic_istream<charT, -traits>
then the expressionin >> get_money(mon, intl)
behaves as a formatted input function -that callsf(in, mon, intl)
were -called. The functionf
can be defined as... -[ -post Bellevue: +Batavia (2009-05): ]
--We recommend moving immediately to Review. We've looked at the issue and -have a consensus that the proposed resolution is correct, but want an -iostream expert to sign off. Alisdair has taken the action item to putt -this up on the reflector for possible movement by Howard to Tenatively -Ready. -- - - - -
-696.
-istream::operator>>(int&)
brokenSection: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New - Submitter: Martin Sebor Date: 2007-06-23
-View all other issues in [istream.formatted.arithmetic].
-View all issues with New status.
-Discussion:
--From message c++std-lib-17897: -
-The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if" -implementation of the two arithmetic extractors that don't have a -corresponding
-num_get
interface (i.e., the -short
andint
overloads) is subtly buggy in -how it deals withEOF
, overflow, and other similar -conditions (in addition to containing a few typos). --One problem is that if
num_get::get()
reaches the EOF -after reading in an otherwise valid value that exceeds the limits of -the narrower type (but notLONG_MIN
or -LONG_MAX
), it will seterr
to -eofbit
. Because of the if condition testing for -(err == 0)
, the extractor won't set -failbit
(and presumably, return a bogus value to the -caller). +We agree that what is specified is identical to what ECMA-262 specifies. +Pete would like to take a bit of time to assess whether we had intended, +but failed, to make a change. +It would also be useful to hear from John Maddock on the issue.-Another problem with the code is that it never actually sets the -argument to the extracted value. It can't happen after the call to -
+setstate()
since the function may throw, so we need to -show when and how it's done (we can't just punt as say: "it happens -afterwards"). However, it turns out that showing how it's done isn't -quite so easy since the argument is normally left unchanged by the -facet on error except when the error is due to a misplaced thousands -separator, which causesfailbit
to be set but doesn't -prevent the facet from storing the value. +Move to Open.Proposed resolution:
+Remove this mention of the CharacterClass production.
++ +CharacterClass :: +[ [lookahead ∉ {^}] ClassRanges ] +[ ^ ClassRanges ]+
-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 Review status.
+718. basic_string is not a sequence
+Section: 21.4 [basic.string] Status: Open + Submitter: Bo Persson Opened: 2007-08-18 Last modified: 2008-03-12
+View other active issues in [basic.string].
+View all other issues in [basic.string].
+View all issues with Open status.
Discussion:
-In 19.4.5.1 [syserr.syserr.overview] we have the class definition of -std::system_error. In contrast to all exception classes, which -are constructible with a what_arg string (see 19.1 [std.exceptions], -or ios_base::failure in 27.4.2.1.1 [ios::failure]), only overloads with with -const string& are possible. For consistency with the re-designed -remaining exception classes this class should also provide -c'tors which accept a const char* what_arg string. -
--Please note that this proposed addition makes sense even -considering the given implementation hint for what(), because -what_arg is required to be set as what_arg of the base class -runtime_error, which now has the additional c'tor overload -accepting a const char*. +Paragraph 21.4 [basic.string]/3 states:
- -Proposed resolution:
+-This proposed wording assumes issue 832 has been accepted and applied to the working paper. +The class template basic_string conforms to the requirements for a +Sequence (23.1.1) and for a Reversible Container (23.1).
+-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated: +First of all, 23.2.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.
-+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); -[ +Bellevue: +]
--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. -
++
+- emplace, for example, may not make sense for strings. Is also likely suboptimal
+- with concepts do we need to maintain string as sequence container?
+- One approach might be to say something like: string is a sequence except it doesn't have these functions
++
+General consensus is to suggest option 2.- basic_string already has push_back
+- const_iterator parameters to insert and erase should be added to basic_string
+- this leaves emplace to handle -- we have the following options: +
++
+- option 1: add it to string even though it's optional
+- option 2: make emplace optional to sequences (move from table 89 to 90)
+- option 3: say string not sequence (the proposal),
+- option 4: add an exception to basic string wording.
+system_error(int ev, const error_category* ecat, const char* what_arg); -----Effects: Constructs an object of class system_error. -
+ +Proposed resolution:
-Postconditions: code() == error_code(ev, ecat) and strcmp(runtime_error::what(), what_arg) == 0. +Remove this sentence, in recognition of the fact that basic_string is +not just a vector-light for literal types, but something quite +different, a string abstraction in its own right.
-
-701. assoc laguerre poly's
-Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New - Submitter: Christopher Crawford Date: 2007-06-30
-View all issues with New status.
+719. std::is_literal type traits should be provided
+Section: 20.6 [meta] Status: Open + Submitter: Daniel Krügler Opened: 2007-08-25 Last modified: 2009-03-14
+View other active issues in [meta].
+View all other issues in [meta].
+View all issues with Open status.
Discussion:
-I see that the definition the associated Laguerre -polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since -N1687. -However, the draft standard only specifies ranks of integer value m, -while the associated Laguerre polynomials are actually valid for real -values of m > -1. In the case of non-integer values of m, the -definition Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n) -must be used, which also holds for integer values of m. See -Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for -the integer case. In fact fractional values are most commonly used in -physics, for example to m = +/- 1/2 to describe the harmonic -oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3 -dimensions. -
--If I am correct, the calculation of the more general case is no -more difficult, and is in fact the function implemented in the GNU -Scientific Library. I would urge you to consider upgrading the -standard, either adding extra functions for real m or switching the -current ones to double. +Since the inclusion of constexpr in the standard draft N2369 we have +a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
- -Proposed resolution:
+- - - - -+-11- A type is a literal type if it is:
++
+- a scalar type; or
+- +
a class type (clause 9) with
++
+- a trivial copy constructor,
+- a trivial destructor,
+- at least one constexpr constructor other than the copy constructor,
+- no virtual base classes, and
+- all non-static data members and base classes of literal types; or
+- an array of literal type.
+
-702. Restriction in associated Legendre functions
-Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: New - Submitter: Christopher Crawford Date: 2007-06-30
-View all issues with New status.
-Discussion:
--One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be -|x| <= 1, not x >= 0.
- - -Proposed resolution:
+I strongly suggest that the standard provides a type traits for +literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
++
- - - -- To keep the traits in sync with existing types.
+- I see many reasons for programmers to use this trait in template + code to provide optimized template definitions for these types, + see below.
+- A user-provided definition of this trait is practically impossible +to write portably.
+
-704. MoveAssignable requirement for container value type overly strict
-Section: 23.1 [container.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-05-20
-View other active issues in [container.requirements].
-View all other issues in [container.requirements].
-View all issues with Open status.
-Discussion:
-The move-related changes inadvertently overwrote the intent of 276. -Issue 276 removed the requirement of CopyAssignable from -most of the member functions of node-based containers. But the move-related changes -unnecessarily introduced the MoveAssignable requirement for those members which used to -require CopyAssignable. +The special problem of reason (c) is that I don't see currently a +way to portably test the condition for literal class types:
--We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable -from some of the sequence requirements. Additionally the in-place construction -work may further reduce requirements. For purposes of an easy reference, here are the -minimum sequence requirements as I currently understand them. Those items in requirements -table in the working draft which do not appear below have been purposefully omitted for -brevity as they do not have any requirements of this nature. Some items which do not -have any requirements of this nature are included below just to confirm that they were -not omitted by mistake. -
++-+
+- at least one constexpr constructor other than the copy constructor,
+-
-Container Requirements -- X u(a) value_type must be CopyConstructible - X u(rv) array and containers with a propagate_never allocator require value_type to be MoveConstructible - a = u Sequences require value_type to be CopyConstructible and CopyAssignable. - Associative containers require value_type to be CopyConstructible. - a = rv array requires value_type to be MoveAssignable. - Sequences and Associative containers with propagate_never and propagate_on_copy_construction 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. -
--
+Sequence Requirements -- X(n) value_type must be DefaultConstructible - X(n, t) value_type must be CopyConstructible - X(i, j) If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible. - a.insert(p, t) The value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable. - a.insert(p, rv) The value_type must be MoveConstructible. - The sequences vector and deque also require the value_type to be MoveAssignable. - a.insert(p, n, t) The value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable. - a.insert(p, i, j) If the iterators return an lvalue the value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue. - If the iterators return an rvalue the value_type must be MoveConstructible. - The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue. - a.erase(p) The sequences vector and deque require the value_type to be MoveAssignable. - a.erase(q1, q2) The sequences vector and deque require the value_type to be MoveAssignable. - a.clear() - a.assign(i, j) If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable. - If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable. - a.assign(n, t) The value_type must be CopyConstructible and CopyAssignable. - a.resize(n) The value_type must be DefaultConstructible. - The sequence vector also requires the value_type to be MoveConstructible. - a.resize(n, t) The value_type must be CopyConstructible. [ +Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits. +]
+ --
--
+Optional Sequence Requirements -- a.front() - a.back() - a.push_front(t) The value_type must be CopyConstructible. - a.push_front(rv) The value_type must be MoveConstructible. - a.push_back(t) The value_type must be CopyConstructible. - a.push_back(rv) The value_type must be MoveConstructible. - a.pop_front() - a.pop_back() - a[n] - a.at[n] Proposed resolution:
+In 20.6.2 [meta.type.synop] in the group "type properties", +just below the line
--
+Associative Container Requirements -- X(i, j) If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible. - a_uniq.insert(t) The value_type must be CopyConstructible. - a_uniq.insert(rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a_eq.insert(t) The value_type must be CopyConstructible. - a_eq.insert(rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a.insert(p, t) The value_type must be CopyConstructible. - a.insert(p, rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a.insert(i, j) If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible.. template <class T> struct is_pod; ++add a new one:
--
+Unordered Associative Container Requirements -- X(i, j, n, hf, eq) If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible. - a_uniq.insert(t) The value_type must be CopyConstructible. - a_uniq.insert(rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a_eq.insert(t) The value_type must be CopyConstructible. - a_eq.insert(rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a.insert(p, t) The value_type must be CopyConstructible. - a.insert(p, rv) The key_type and the mapped_type (if it exists) must be MoveConstructible. - a.insert(i, j) If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible.. template <class T> struct is_literal; ++In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just +below the line for the is_pod property add a new line:
-
-Miscellaneous Requirements -- map[lvalue-key] The key_type must be CopyConstructible. - The mapped_type must be DefaultConstructible and MoveConstructible. + map[rvalue-key] The key_type must be MoveConstructible. - The mapped_type must be DefaultConstructible and MoveConstructible. + +Template Condition Preconditions ++ template <class T> struct is_literal; +T is a literal type (3.9) +T shall be a complete type, an +array of unknown bound, or +(possibly cv-qualified) void. +[ -Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures. -]
- - -[ -Bellevue: This should be handled as part of the concepts work. -]
- - - - -Proposed resolution:
-
-708. Locales need to be per thread and updated for POSIX changes
-Section: 22 [localization] Status: Open - Submitter: Peter Dimov Date: 2007-07-28
-View all other issues in [localization].
+721. wstring_convert inconsistensies
+Section: 22.3.3.2.2 [conversions.string] Status: Open + Submitter: Bo Persson Opened: 2007-08-27 Last modified: 2008-09-18
+View other active issues in [conversions.string].
+View all other issues in [conversions.string].
View all issues with Open status.
Discussion:
-The POSIX "Extended API Set Part 4," -
---introduces extensions to the C locale mechanism that -allow multiple concurrent locales to be used in the same application -by introducing a type locale_t that is very similar to -std::locale, and a number of _l functions that make use of it. -
--The global locale (set by setlocale) is now specified to be per- -process. If a thread does not call uselocale, the global locale is -in effect for that thread. It can install a per-thread locale by -using uselocale. -
--There is also a nice querylocale mechanism by which one can obtain -the name (such as "de_DE") for a specific facet, even for combined -locales, with no std::locale equivalent. +Paragraph 3 says that the Codecvt template parameter shall meet the +requirements of std::codecvt, even though std::codecvt itself cannot +be used (because of a protected destructor).
+-std::locale should be harmonized with the new POSIX locale_t -mechanism and provide equivalents for uselocale and querylocale. +How are we going to explain this code to beginning programmers?
++template<class I, class E, class S> +struct codecvt : std::codecvt<I, E, S> +{ + ~codecvt() + { } +}; + +void main() +{ + std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok; + + std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok; +} +[ -Kona (2007): Bill and Nick to provide wording. +San Francisco: ]
++Bill will propose a resolution. +Proposed resolution:
@@ -9141,303 +9016,289 @@ Kona (2007): Bill and Nick to provide wording.
-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.
+723. basic_regex should be moveable
+Section: 28.9 [re.regex] Status: Open + Submitter: Daniel Krügler Opened: 2007-08-29 Last modified: 2009-03-13
+View all other issues in [re.regex].
+View all issues with Open 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. -
Addresses UK 316
- -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 +According to the current state of the standard draft, the class +template basic_regex, as described in 28.9 [re.regex]/3, is +neither MoveConstructible nor MoveAssignable. +IMO it should be, because typical regex state machines tend +to have a rather large data quantum and I have seen several +use cases, where a factory function returns regex values, +which would take advantage of moveabilities.
-- - -static constexpr int_type not_eof(char_typeint_type c); -[ -Bellevue: +Sophia Antipolis: ]
-Resolution: NAD editorial - up to Pete's judgment +Needs wording for the semantics, the idea is agreed upon.[ -Post Sophia Antipolis +Post Summit Daniel updated wording to reflect new "swap rules". ]
--Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial. -- - - -
-711. Contradiction in empty shared_ptr
-Section: 20.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 Open status.
-Discussion:
+Proposed resolution:
-A discussion on -comp.std.c++ -has identified a contradiction in the shared_ptr specification. -The note: +In the class definition of basic_regex, just below 28.9 [re.regex]/3, +perform the following changes:
-- +-[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer. --end note ] -
+
- +
-after the aliasing constructor +Just after basic_regex(const basic_regex&); insert:
-template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p); +- +basic_regex(basic_regex&&);- +
-reflects the intent of -N2351 -to, well, allow the creation of an empty shared_ptr -with a non-NULL stored pointer. +Just after basic_regex& operator=(const basic_regex&); insert:
- ++basic_regex& operator=(basic_regex&&); +- +
-This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]: -
- --- -T* get() const; ----Returns: the stored pointer. Returns a null pointer if *this is empty. -
[ -Bellevue: -]
- - ---Adopt option 1 and move to review, not ready. -
--There was a lot of confusion about what an empty shared_ptr is (the term -isn't defined anywhere), and whether we have a good mental model for how -one behaves. We think it might be possible to deduce what the definition -should be, but the words just aren't there. We need to open an issue on -the use of this undefined term. (The resolution of that issue might -affect the resolution of issue 711.) +Just after basic_regex& assign(const basic_regex& that); insert:
++basic_regex& assign(basic_regex&& that); +-The LWG is getting more uncomfortable with the aliasing proposal (N2351) -now that we realize some of its implications, and we need to keep an eye -on it, but there isn't support for removing this feature at this time. +In 28.9.2 [re.regex.construct], just after p.11 add the following +new member definition:
-[ -Sophia Antipolis: -]
- - ++ +basic_regex(basic_regex&& e); +- - - --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? +Effects: Move-constructs a basic_regex instance from e.
-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. +Postconditions: flags() and mark_count() return e.flags() and +e.mark_count(), respectively, +that e had before construction, leaving +e in a valid state with an unspecified value.
-We could not agree upon a resolution to the issue; some of us thought -that Peter's description above is supporting an undesirable behavior. +Throws: nothing.
Proposed resolution:
++ -In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]: +Also in 28.9.2 [re.regex.construct], just after p.18 add the +following new member definition:
--T* get() const; ++basic_regex& operator=(basic_regex&& e);-+-Returns: the stored pointer.
Returns a null pointer if *this is empty.-+Effects: Returns the result of assign(std::move(e)).- --Alternative proposed resolution: (I won't be happy if we do this, but it's possible): -
- ++ -Change 20.7.12.2.1 [util.smartptr.shared.const]: +In 28.9.3 [re.regex.assign], just after p. 2 add the following new +member definition:
- --template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p); +- +basic_regex& assign(basic_regex&& rhs);-Requires: If r is empty, p shall be 0. +Effects: Move-assigns a basic_regex instance from rhs and returns *this.
-
+[ Note: this constructor allows creation of an empty shared_ptr -instance with a non-NULL stored pointer. --- end note ]+Postconditions: flags() and mark_count() return rhs.flags() +and rhs.mark_count(), respectively, that +rhs had before assignment, leaving rhs +in a valid state with an unspecified value. ++Throws: nothing.
-713. sort() complexity is too lax
-Section: 25.3.1.1 [sort] Status: Ready - Submitter: Matt Austern Date: 2007-08-30
-View all issues with Ready status.
+726. Missing regex_replace() overloads
+Section: 28.12.4 [re.alg.replace] Status: Open + Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2008-06-18
+View other active issues in [re.alg.replace].
+View all other issues in [re.alg.replace].
+View all issues with Open status.
Discussion:
-The complexity of sort() is specified as "Approximately N -log(N) (where N == last - first ) comparisons on the -average", with no worst case complicity specified. The intention was to -allow a median-of-three quicksort implementation, which is usually O(N -log N) but can be quadratic for pathological inputs. However, there is -no longer any reason to allow implementers the freedom to have a -worst-cast-quadratic sort algorithm. Implementers who want to use -quicksort can use a variant like David Musser's "Introsort" (Software -Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N -log N) in the worst case without incurring additional overhead in the -average case. Most C++ library implementers already do this, and there -is no reason not to guarantee it in the standard. +Two overloads of regex_replace() are currently provided:
++ +template <class OutputIterator, class BidirectionalIterator, + class traits, class charT> + OutputIterator + regex_replace(OutputIterator out, + BidirectionalIterator first, BidirectionalIterator last, + const basic_regex<charT, traits>& e, + const basic_string<charT>& fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); + +template <class traits, class charT> + basic_string<charT> + regex_replace(const basic_string<charT>& s, + const basic_regex<charT, traits>& e, + const basic_string<charT>& fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); ++
+- Overloads taking const charT * are provided for regex_match() and +regex_search(), but not regex_replace(). This is inconsistent.
+- +
+The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
+ +-const string s("kitten"); +const regex r("en"); +cout << regex_replace(s, r, "y") << endl; +Proposed resolution:
-In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266: +The compiler error message will be something like "could not deduce +template argument for 'const std::basic_string<_Elem> &' from 'const +char[1]'".
-- +-Complexity:
+ApproximatelyO(N log(N)) (where N == last - first ) -comparisonson the average.266)+Users expect that anything taking a basic_string<charT> can also take a +const charT *. In their own code, when they write a function taking +std::string (or std::wstring), they can pass a const char * (or const +wchar_t *), thanks to basic_string's implicit constructor. Because the +regex algorithms are templated on charT, they can't rely on +basic_string's implicit constructor (as the compiler error message +indicates, template argument deduction fails first).-
-266) -If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort() -(25.3.1.3) should be used.+If a user figures out what the compiler error message means, workarounds +are available - but they are all verbose. Explicit template arguments +could be given to regex_replace(), allowing basic_string's implicit +constructor to be invoked - but charT is the last template argument, not +the first, so this would be extremely verbose. Therefore, constructing +a basic_string from each C string is the simplest workaround.- +There is an efficiency consideration: constructing basic_strings can +impose performance costs that could be avoided by a library +implementation taking C strings and dealing with them directly. +(Currently, for replacement sources, C strings can be converted into +iterator pairs at the cost of verbosity, but for format strings, there +is no way to avoid constructing a basic_string.) +
+[ +Sophia Antipolis: +]
++We note that Boost already has these overloads. However, the proposed +wording is provided only for 28.12.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. +-
-714. search_n complexity is too lax
-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 Ready status.
-Discussion:
--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 -element in the range more than once. -
Proposed resolution:
-Change the complexity to "At most (last - first) applications of the corresponding predicate". +Provide additional overloads for regex_replace(): one additional +overload of the iterator-based form (taking const charT* fmt), and three +additional overloads of the convenience form (one taking const charT* +str, another taking const charT* fmt, and the third taking both const +charT* str and const charT* fmt). 28.12.4 [re.alg.replace]:
-@@ -9446,75 +9307,106 @@ template<class ForwardIterator, class Size, class T,template<class ForwardIterator, class Size, class T> - ForwardIterator - search_n(ForwardIterator first , ForwardIterator last , Size count , - const T& value ); +template <class OutputIterator, class BidirectionalIterator, + class traits, class charT> + OutputIterator + regex_replace(OutputIterator out, + BidirectionalIterator first, BidirectionalIterator last, + const basic_regex<charT, traits>& e, + const basic_string<charT>& fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); + +template <class OutputIterator, class BidirectionalIterator, + class traits, class charT> + OutputIterator + regex_replace(OutputIterator out, + BidirectionalIterator first, BidirectionalIterator last, + const basic_regex<charT, traits>& e, + const charT* fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); ++...
+template <class traits, class charT> + basic_string<charT> + regex_replace(const basic_string<charT>& s, + const basic_regex<charT, traits>& e, + const basic_string<charT>& fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); + +template <class traits, class charT> + basic_string<charT> + regex_replace(const basic_string<charT>& s, + const basic_regex<charT, traits>& e, + const charT* fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); + +template <class traits, class charT> + basic_string<charT> + regex_replace(const charT* s, + const basic_regex<charT, traits>& e, + const basic_string<charT>& fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default); -template<class ForwardIterator, class Size, class T, - class BinaryPredicate> - ForwardIterator - search_n(ForwardIterator first , ForwardIterator last , Size count , - const T& value , BinaryPredicate pred ); +template <class traits, class charT> + basic_string<charT> + regex_replace(const charT* s, + const basic_regex<charT, traits>& e, + const charT* fmt, + regex_constants::match_flag_type flags = + regex_constants::match_default);---Complexity: At most (last - first )
-* countapplications of the corresponding predicate -if count is positive, or 0 otherwise. -
-716. Production in [re.grammar] not actually modified
-Section: 28.13 [re.grammar] Status: New - Submitter: Stephan T. Lavavej Date: 2007-08-31
-View all issues with New status.
+727. regex_replace() doesn't accept basic_strings with custom traits and allocators
+Section: 28.12.4 [re.alg.replace] Status: Open + Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2009-05-23
+View other active issues in [re.alg.replace].
+View all other issues in [re.alg.replace].
+View all issues with Open status.
Discussion:
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say: +regex_match() and regex_search() take const basic_string<charT, ST, +SA>&. regex_replace() takes const basic_string<charT>&. This prevents +regex_replace() from accepting basic_strings with custom traits and +allocators.
+[ +Batavia (2009-05): +]
+--The following productions within the ECMAScript grammar are modified as follows: +Bill comments, "We need to look at the depth of this change."
- -- -CharacterClass :: -[ [lookahead ∉ {^}] ClassRanges ] -[ ^ ClassRanges ] --This definition for CharacterClass appears to be exactly identical to that in ECMA-262. +Pete remarks that we are here dealing with a convenience function +that saves a user from calling the iterato-based overload.
--Was an actual modification intended here and accidentally omitted, or was this production accidentally included? +Move to Open.
+Proposed resolution:
-Remove this mention of the CharacterClass production. +Overloads of regex_replace() taking basic_string should be additionally +templated on class ST, class SA and take const basic_string<charT, ST, +SA>&. Consistency with regex_match() and regex_search() would place +class ST, class SA as the first template arguments; compatibility with +existing code using TR1 and giving explicit template arguments to +regex_replace() would place class ST, class SA as the last template +arguments.
-- -CharacterClass :: -[ [lookahead ∉ {^}] ClassRanges ] -[ ^ ClassRanges ]-
-718. basic_string is not a sequence
-Section: 21.3 [basic.string] Status: Open - Submitter: Bo Persson Date: 2007-08-18
-View other active issues in [basic.string].
-View all other issues in [basic.string].
+747. We have 3 separate type traits to identify classes supporting no-throw operations
+Section: 20.6.4.3 [meta.unary.prop] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-03-11
+View other active issues in [meta.unary.prop].
+View all other issues in [meta.unary.prop].
View all issues with Open status.
Discussion:
-Paragraph 21.3 [basic.string]/3 states: +We have 3 separate type traits to identify classes supporting no-throw +operations, which are very useful when trying to provide exception safety +guarantees. However, I'm not entirely clear on what the current wording +requires of a conforming implementation. To quote from +has_nothrow_default_constructor:
- -+++or T is a class type with a default constructor that is known not to throw +any exceptions +
-The class template basic_string conforms to the requirements for a -Sequence (23.1.1) and for a Reversible Container (23.1). +What level of magic do we expect to deduce if this is known? +
++E.g.
-struct test{ + int x; + test() : x() {} +}; +-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. +Should I expect a conforming compiler to + assert( has_nothrow_constructor<test>::value ) +
++Is this a QoI issue? +
++Should I expect to 'know' only if-and-only-if there is an inline definition +available? +
++Should I never expect that to be true, and insist that the user supplies an +empty throw spec if they want to assert the no-throw guarantee? +
++It would be helpful to maybe have a footnote explaining what is required, +but right now I don't know what to suggest putting in the footnote. +
++(agreement since is that trivial ops and explicit no-throws are required. +Open if QoI should be allowed to detect further)
[ @@ -9523,33 +9415,14 @@ Bellevue:
---
-- emplace, for example, may not make sense for strings. Is also likely suboptimal
-- with concepts do we need to maintain string as sequence container?
-- One approach might be to say something like: string is a sequence except it doesn't have these functions
--
-General consensus is to suggest option 2. +This looks like a QoI issue. +In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. +Move to OPEN. Need to talk to Core about this.- basic_string already has push_back
-- const_iterator parameters to insert and erase should be added to basic_string
-- this leaves emplace to handle -- we have the following options: -
--
-- option 1: add it to string even though it's optional
-- option 2: make emplace optional to sequences (move from table 89 to 90)
-- option 3: say string not sequence (the proposal),
-- option 4: add an exception to basic string wording.
-Proposed resolution:
-Remove this sentence, in recognition of the fact that basic_string is -not just a vector-light for literal types, but something quite -different, a string abstraction in its own right.
@@ -9557,660 +9430,405 @@ different, a string abstraction in its own right.
-719. std::is_literal type traits should be provided
-Section: 20.5 [meta] Status: Open - Submitter: Daniel Krügler Date: 2007-08-25
-View all other issues in [meta].
+750. The current definition for is_convertible requires that the type be +implicitly convertible, so explicit constructors are ignored.
+Section: 20.6.5 [meta.rel] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-03-11
+View other active issues in [meta.rel].
+View all other issues in [meta.rel].
View all issues with Open status.
Discussion:
-Since the inclusion of constexpr in the standard draft N2369 we have -a new type category "literal", which is defined in 3.9 [basic.types]/p.11: +With the pending arrival of explicit conversion functions though, I'm +wondering if we want an additional trait, is_explictly_convertible?
+[ +Bellevue: +]
+ +----11- A type is a literal type if it is: -
--
+Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits.- a scalar type; or
-- -
a class type (clause 9) with
--
-- a trivial copy constructor,
-- a trivial destructor,
-- at least one constexpr constructor other than the copy constructor,
-- no virtual base classes, and
-- all non-static data members and base classes of literal types; or
-- an array of literal type.
--I strongly suggest that the standard provides a type traits for -literal types in 20.5.4.3 [meta.unary.prop] for several reasons: -
- --
+- To keep the traits in sync with existing types.
-- I see many reasons for programmers to use this trait in template - code to provide optimized template definitions for these types, - see below.
-- A user-provided definition of this trait is practically impossible -to write portably.
-Proposed resolution:
-The special problem of reason (c) is that I don't see currently a -way to portably test the condition for literal class types:
----
-- at least one constexpr constructor other than the copy constructor,
--Here follows a simply example to demonstrate it's usefulness: -
-+template <typename T> -constexpr typename std::enable_if<std::is_literal<T>::value, T>::type -abs(T x) { - return x < T() ? -x : x; -} -template <typename T> -typename std::enable_if<!std::is_literal<T>::value, T>::type -abs(const T& x) { - return x < T() ? -x : x; -} -
+751. change pass-by-reference members of vector<bool> to pass-by-value?
+Section: 23.3.7 [vector.bool] Status: Open + Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2008-09-22
+View other active issues in [vector.bool].
+View all other issues in [vector.bool].
+View all issues with Open status.
+Discussion:
-Here we have the possibility to provide a general abs function -template that can be used in ICE's if it's argument is a literal -type which's value is a constant expression, otherwise we -have an optimized version for arguments which are expensive -to copy and therefore need the usage of arguments of -reference type (instead of const T& we could decide to -use T&&, but that is another issue). +A number of vector<bool> members take const bool& as arguments. +Is there any chance we could change them to pass-by-value or would I +be wasting everyone's time if wrote up an issue?
[ -Alisdair is considering preparing a paper listing a number of missing -type traits, and feels that it might be useful to handle them all -together rather than piecemeal. This would affect issue 719 and 750. -These two issues should move to OPEN pending AM paper on type traits. +post Bellevue: ]
- - -Proposed resolution:
+-In 20.5.2 [meta.type.synop] in the group "type properties", -just below the line +As we understand it, the original requester (Martin Sebor) would like +for implementations to be permitted to pass-by-value. Alisdair suggests +that if this is to be resolved, it should be resolved more generally, +e.g. in other containers as well.
- --template <class T> struct is_pod; --add a new one: +We note that this would break ABI. However, we also suspect that this +might be covered under the "as-if" rule in section 1.9.
- --template <class T> struct is_literal; --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: +Many in the group feel that for vector<bool>, this is a "don't care", +and that at this point in the process it's not worth the bandwidth.
- --
- - - - - - -- -Template Condition Preconditions -- -template <class T> struct is_literal; -T is a literal type (3.9) -T shall be a complete type, an -array of unknown bound, or -(possibly cv-qualified) void. -
-720. Omissions in constexpr usages
-Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: 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 Ready status.
-Discussion:
--
+- -The member function bool array<T,N>::empty() const should be a -constexpr because this is easily to proof and to implement following it's operational -semantics defined by Table 87 (Container requirements) which says: a.size() == 0. -
-- -The member function bool bitset<N>::test() const must be a -constexpr (otherwise it would violate the specification of constexpr -bitset<N>::operator[](size_t) const, because it's return clause delegates to test()). -
-- -I wonder how the constructor bitset<N>::bitset(unsigned long) can -be declared as a constexpr. Current implementations usually have no such bitset -c'tor which would fulfill the requirements of a constexpr c'tor because they have a -non-empty c'tor body that typically contains for-loops or memcpy to compute the -initialisation. What have I overlooked here? -
-+Issue 679 -- which was in ready status pre-Bellevue and is +now in the working paper -- is related to this, though not a duplicate. +
++Moving to Open with a task for Alisdair to craft a informative note to +be put whereever appropriate in the WP. This note would clarify places +where pass-by-const-ref can be transformed to pass-by-value under the +as-if rule. +
+[ -Sophia Antipolis: +San Francisco: ]
--We handle this as two parts +This is really a clause 17 issue, rather than something specific to vector<bool>. +
++Move to Open. Alisdair to provide a resolution. Alternately, Howard can +close this as NAD and then open a new issue to handle the general issue +(rather than the vector<bool> one).
--
- -The proposed resolution is correct; move to ready. -
-- -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. -
--In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution. +Howard: Haven't yet opened new issue. Lacking wording for it.
Proposed resolution:
--
-- -
- -In the class template definition of 23.2.1 [array]/p. 3 change
--constexpr bool empty() const; -- -
-In the class template definition of 23.3.5 [template.bitset]/p. 1 change
--constexpr bool test(size_t pos ) const; --and in 23.3.5.2 [bitset.members] change
-- -constexpr bool test(size_t pos ) const; -
-721. wstring_convert inconsistensies
-Section: 22.1.3.2.2 [conversions.string] Status: New - Submitter: Bo Persson Date: 2007-08-27
-View all issues with New status.
+760. The emplace issue
+Section: 23.2 [container.requirements] Status: Open + Submitter: Paolo Carlini Opened: 2007-11-11 Last modified: 2008-06-02
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Open status.
Discussion:
-Paragraph 3 says that the Codecvt template parameter shall meet the -requirements of std::codecvt, even though std::codecvt itself cannot -be used (because of a protected destructor). -
- --How are we going to explain this code to beginning programmers? +In an emplace member function the function parameter pack may be bound +to a priori unlimited number of objects: some or all of them can be +elements of the container itself. Apparently, in order to conform to the +blanket statement 23.2 [container.requirements]/11, the implementation must check all of them for +that possibility. A possible solution can involve extending the +exception in 23.2 [container.requirements]/12 also to the emplace member. As a side note, the +push_back and push_front member functions are luckily not affected by +this problem, can be efficiently implemented anyway
-+template<class I, class E, class S> -struct codecvt : std::codecvt<I, E, S> -{ - ~codecvt() - { } -}; +[ +Related to 767 +]
-void main() -{ - std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok; - - std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok; -} -[ +Bellevue: +]
-Proposed resolution:
++- - -+The proposed addition (13) is partially redundant with the existing +paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why +does it not cover subelements and pointers? +
+Resolution: Alan Talbot to rework language, then set state to Review.
+
-723. basic_regex should be moveable
-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 Open status.
-Discussion:
+Proposed resolution:
-According to the current state of the standard draft, the class -template basic_regex, as described in 28.8 [re.regex]/3, is -neither MoveConstructible nor MoveAssignable. -IMO it should be, because typical regex state machines tend -to have a rather large data quantum and I have seen several -use cases, where a factory function returns regex values, -which would take advantage of moveabilities. +Add after 23.2 [container.requirements]/12:
-[ -Sophia Antipolis: -]
- --Needs wording for the semantics, the idea is agreed upon. -- - -Proposed resolution:
--
- -
-In the header <regex> synopsis 28.4 [re.syn], just below the function -template swap add two further overloads: +-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required.
-template <class charT, class traits> - void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2); -template <class charT, class traits> - void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2); -template <class charT, class traits> - void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2); --In the class definition of basic_regex, just below 28.8 [re.regex]/3, -perform the following changes: + +-13- Objects bound to the function parameter pack of the emplace member function shall not be elements or +sub-objects of elements of the container. No diagnostic required. +
-- -
+Just after the copy c'tor:
--basic_regex(basic_regex&&); -- -Just after the copy-assignment op.:
--basic_regex& operator=(basic_regex&&); -- -Just after the first assign overload insert:
--basic_regex& assign(basic_regex&& that); -- -Change the current swap function to read:
--void swap(basic_regex&&); -- -In 28.8.2 [re.regex.construct], just below the copy c'tor add a -corresponding member definition of:
--basic_regex(basic_regex&&); -- -Also in 28.8.2 [re.regex.construct], just below the copy assignment -c'tor add a corresponding member definition of:
--basic_regex& operator=(basic_regex&&); -- +In 28.8.3 [re.regex.assign], just below the first assign overload add -a corresponding member definition of:
--basic_regex& assign(basic_regex&& that); -
+765. more on iterator validity
+Section: 24.2 [iterator.concepts] Status: Tentatively Ready + Submitter: Martin Sebor Opened: 2007-12-14 Last modified: 2009-03-09
+View other active issues in [iterator.concepts].
+View all other issues in [iterator.concepts].
+View all issues with Tentatively Ready status.
+Discussion:
+-
- +Issue 278 +defines the meaning of the term "invalid iterator" as one that may be +singular. -In 28.8.6 [re.regex.swap], change the signature of swap to -say:
--void swap(basic_regex&& e); -- - + +In 28.8.7.1 [re.regex.nmswap], just below the single binary swap -function, add the two missing overloads:
--template <class charT, class traits> - void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2); -template <class charT, class traits> - void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2); --
-Of course there would be need of corresponding proper standardese -to describe these additions. -
+Consider the following code: + + +std::deque<int> x, y; + std::deque<int>::iterator i = x.end(), j = y.end(); + x.swap(y); +++ +Given that
+swap()
is required not to invalidate iterators +and using the definition above, what should be the expected result of +comparingi
andj
tox.end()
+andy.end()
, respectively, after theswap()
? ++I.e., is the expression below required to evaluate +to
+true
? +i == y.end() && j == x.end() +++(There are at least two implementations where the expression +returns
+false
.) +-
-724. DefaultConstructible is not defined
-Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Pablo Halpern Date: 2007-09-12
-View other active issues in [utility.arg.requirements].
-View all other issues in [utility.arg.requirements].
-View all issues with Open status.
-Discussion:
--The DefaultConstructible requirement is referenced in -several places in the August 2007 working draft -N2369, -but is not defined anywhere. -
+More generally, is the definition introduced in issue 278 meant to +make any guarantees about whether iterators actually point to the same +elements or be associated with the same containers after a +non-invalidating operation as they did before? + + ++ +Here's a motivating example intended to demonstrate the importance of +the question: + +
+Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 } + Container::iterator i = y.begin() + 1; + Container::iterator j = y.end(); + std::swap(x, y); + std::find(i, j, 3); +++ +
swap()
guarantees thati
andj
+continue to be valid. Unless the spec says that even though they are +valid they may no longer denote a valid range the code above must be +well-defined. Expert opinions on this differ as does the behavior of +popular implementations for some standardContainers
. +[ -Bellevue: +San Francisco: ]
-+ +-Walking into the default/value-initialization mess... +
Pablo: add a note to the last bullet of paragraph 11 of 23.1.1 +clarifying that the end() iterator doesn't refer to an element and that +it can therefore be invalidated.
-Why two lines? Because we need both expressions to be valid. -
--AJM not sure what the phrase "default constructed" means. This is -unfortunate, as the phrase is already used 24 times in the library! +Proposed wording:
++[Note: The end() iterator does not refer to any element and can +therefore be invalidated. -- end note] +-Example: const int would not accept first line, but will accept the second. +Howard will add this proposed wording to the issue and then move it to Review.
+[ +Post Summit: +]
+ + ++-This is an issue that must be solved by concepts, but we might need to solve it independantly first. +Lawrence: suggestion: "Note: The end() iterator does not refer to any element"
-It seems that the requirements are the syntax in the proposed first -column is valid, but not clear what semantics we need. +Walter: "Note: The end() iterator can nevertheless be invalidated, +because it does not refer to any element."
-A table where there is no post-condition seems odd, but appears to sum up our position best. +Nick: "The end() iterator does not refer to any element. It is therefore +subject to being invalidated."
-At a minimum an object is declared and is destuctible. +Consensus: go with Nick
-Move to open, as no-one happy to produce wording on the fly. +With that update, Recommend Tentatively Ready.
Proposed resolution:
-In section 20.1.1 [utility.arg.requirements], before table 33, add the -following table: +Add to 23.2.1 [container.requirements.general], p11:
-Table 33: DefaultConstructible requirements
- -- -- +-
- -- -- -expression
-- -post-condition
-- -- -T - t;
-
- T()- -T - is default constructed.
-++Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and +23.2.6.4) all container types defined in this Clause meet the following +additional requirements: +
++
+- ...
+- +no swap() function invalidates any references, pointers, or +iterators referring to the elements of the containers being swapped. +[Note: The end() iterator does not refer to any element. It is therefore +subject to being invalidated. -- end note] +
+
-726. Missing regex_replace() overloads
-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].
+774. Member swap undefined for most containers
+Section: 23 [containers] Status: Open + Submitter: Alisdair Meredith Opened: 2008-01-14 Last modified: 2008-05-11
+View other active issues in [containers].
+View all other issues in [containers].
View all issues with Open status.
Discussion:
-Two overloads of regex_replace() are currently provided: +It appears most containers declare but do not define a member-swap +function.
-- -template <class OutputIterator, class BidirectionalIterator, - class traits, class charT> - OutputIterator - regex_replace(OutputIterator out, - BidirectionalIterator first, BidirectionalIterator last, - const basic_regex<charT, traits>& e, - const basic_string<charT>& fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); - -template <class traits, class charT> - basic_string<charT> - regex_replace(const basic_string<charT>& s, - const basic_regex<charT, traits>& e, - const basic_string<charT>& fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); --
- -- Overloads taking const charT * are provided for regex_match() and -regex_search(), but not regex_replace(). This is inconsistent.
-- -
- -The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
- --const string s("kitten"); -const regex r("en"); -cout << regex_replace(s, r, "y") << endl; --The compiler error message will be something like "could not deduce -template argument for 'const std::basic_string<_Elem> &' from 'const -char[1]'". +This is unfortunate, as all overload the swap algorithm to call the +member-swap function! +(required for swappable guarantees [Table 37] and Container Requirements +[Table 87])
-Users expect that anything taking a basic_string<charT> can also take a -const charT *. In their own code, when they write a function taking -std::string (or std::wstring), they can pass a const char * (or const -wchar_t *), thanks to basic_string's implicit constructor. Because the -regex algorithms are templated on charT, they can't rely on -basic_string's implicit constructor (as the compiler error message -indicates, template argument deduction fails first). +Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b), +yet for all containers we define swap(a,b) to call a.swap(b) - a circular +definition.
-If a user figures out what the compiler error message means, workarounds -are available - but they are all verbose. Explicit template arguments -could be given to regex_replace(), allowing basic_string's implicit -constructor to be invoked - but charT is the last template argument, not -the first, so this would be extremely verbose. Therefore, constructing -a basic_string from each C string is the simplest workaround. +A quick survey of clause 23 shows that the following containers provide a +definition for member-swap:
-- -There is an efficiency consideration: constructing basic_strings can -impose performance costs that could be avoided by a library -implementation taking C strings and dealing with them directly. -(Currently, for replacement sources, C strings can be converted into -iterator pairs at the cost of verbosity, but for format strings, there -is no way to avoid constructing a basic_string.) -
-[ -Sophia Antipolis: -]
+-array +queue +stack +vector +-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. -- ++Whereas the following declare it, but do not define the semantics: +
+-deque +list +map +multimap +multiset +priority_queue +set +unordered_map +unordered_multi_map +unordered_multi_set +unordered_set +Proposed resolution:
-Provide additional overloads for regex_replace(): one additional -overload of the iterator-based form (taking const charT* fmt), and three -additional overloads of the convenience form (one taking const charT* -str, another taking const charT* fmt, and the third taking both const -charT* str and const charT* fmt). 28.11.4 [re.alg.replace]: +Suggested resolution:
--+template <class OutputIterator, class BidirectionalIterator, - class traits, class charT> - OutputIterator - regex_replace(OutputIterator out, - BidirectionalIterator first, BidirectionalIterator last, - const basic_regex<charT, traits>& e, - const basic_string<charT>& fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); - -template <class OutputIterator, class BidirectionalIterator, - class traits, class charT> - OutputIterator - regex_replace(OutputIterator out, - BidirectionalIterator first, BidirectionalIterator last, - const basic_regex<charT, traits>& e, - const charT* fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); --...
-template <class traits, class charT> - basic_string<charT> - regex_replace(const basic_string<charT>& s, - const basic_regex<charT, traits>& e, - const basic_string<charT>& fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); - -template <class traits, class charT> - basic_string<charT> - regex_replace(const basic_string<charT>& s, - const basic_regex<charT, traits>& e, - const charT* fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); - -template <class traits, class charT> - basic_string<charT> - regex_replace(const charT* s, - const basic_regex<charT, traits>& e, - const basic_string<charT>& fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); - -template <class traits, class charT> - basic_string<charT> - regex_replace(const charT* s, - const basic_regex<charT, traits>& e, - const charT* fmt, - regex_constants::match_flag_type flags = - regex_constants::match_default); -+Provide a definition for each of the affected containers...[ +Bellevue: +]
- - - -
-727. regex_replace() doesn't accept basic_strings with custom traits and allocators
-Section: 28.11.4 [re.alg.replace] Status: New - Submitter: Stephan T. Lavavej Date: 2007-09-22
-View other active issues in [re.alg.replace].
-View all other issues in [re.alg.replace].
-View all issues with New status.
-Discussion:
--regex_match() and regex_search() take const basic_string<charT, ST, -SA>&. regex_replace() takes const basic_string<charT>&. This prevents -regex_replace() from accepting basic_strings with custom traits and -allocators. -
++Move to Open and ask Alisdair to provide wording. +Proposed resolution:
-Overloads of regex_replace() taking basic_string should be additionally -templated on class ST, class SA and take const basic_string<charT, ST, -SA>&. Consistency with regex_match() and regex_search() would place -class ST, class SA as the first template arguments; compatibility with -existing code using TR1 and giving explicit template arguments to -regex_replace() would place class ST, class SA as the last template -arguments. +Wording provided in +N2590.
@@ -10218,311 +9836,317 @@ arguments.
-728. Problem in [rand.eng.mers]/6
-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 Ready status.
+780. std::merge() specification incorrect/insufficient
+Section: 25.5.4 [alg.merge] Status: Review + Submitter: Daniel Krügler Opened: 2008-01-25 Last modified: 2009-05-23
+View all issues with Review status.
Discussion:
-The mersenne_twister_engine is required to use a seeding method that is given -as an algorithm parameterized over the number of bits W. I doubt whether the given generalization -of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate -for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in -which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. -Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister -[reference]. +Though issue 283 has fixed many open issues, it seems that some are still open:
-I see two possible resolutions: +Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461 +have no Requires element and the Effects element contains some requirements, +which is probably editorial. Worse is that:
--
-- Restrict the parameter W of the mersenne_twister_template to values of 32 or 64 and use the -multiplier from [the above reference] for the 64-bit case (my preference)
-- Interpret the state array for any W as a 32-bit array of appropriate length (and a specified byte -order) and always employ the 32-bit algorithm for seeding +
+
- +no assignment requirements are specified (neither implicit nor explicit).
--See N2424 -for further discussion. -
++the effects clause just speaks of "merges", which is badly worded +near to a circular definition. + + ++p. 2 mentions a range [first, last), which is not defined by the +function arguments or otherwise. + + ++p. 2 says "according to the ordering defined by comp" which is both +incomplete (because +this excludes the first variant with <) and redundant (because the +following subordinate +clause mentions comp again) + +[ -Bellevue: +Post Summit Alisdair adds: ]
-Stephan Tolksdorf has additional comments on N2424. He comments: "there -is a typo in the required behaviour for mt19937_64: It should be the -10000th (not 100000th) invocation whose value is given, and the value -should be 9981545732273789042 (not 14002232017267485025)." These values -need checking. -
--Take the proposed recommendation in N2424 and move to REVIEW. +Suggest:
++(where last is equal to next(result, distance(first1, last1) + +distance(first2, last2)), such that resulting range will be sorted in +non-decreasing order; that is, for every iterator i in [result,last) other +than result, the condition *i < *prev(i) or, respectively, comp(*i, +*prev(i)) will be false.- - - -Proposed resolution:
--See N2424 -for the proposed resolution. +Note that this might still not be technically accurate in the case of +InputIterators, depending on other resolutions working their way through the +system (1011).
+[ -Stephan Tolksdorf adds pre-Bellevue: +Post Summit Daniel adds: ]
-I support the proposed resolution in -N2424, -but there is a typo in the -required behaviour for mt19937_64: It should be the 10000th (not -100000th) invocation whose value is given, and the value should be -9981545732273789042 (not 14002232017267485025). The change to para. 8 -proposed by Charles Karney should also be included in the proposed -wording. +If we want to use prev and next here (Note: merge +is sufficiently satisfied with InputIterator) we should instead *add* more to +25 [algorithms]/6, but I can currently not propose any good wording for this.[ -Sophia Antipolis: +Batavia (2009-05): ]
--Note the main part of the issue is resolved by -N2424. -- - - - - - -
-732. Defect in [rand.dist.samp.genpdf]
-Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Open - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all other issues in [rand.dist.samp.genpdf].
-View all issues with Open status.
-Duplicate of: 795
-Discussion:
-26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is -meant to simulate random numbers from any general distribution given only the density and the -support of the distribution. I'm not aware of any general purpose algorithm that would be capable -of correctly and efficiently implementing the described functionality. From what I know, this is -essentially an unsolved research problem. Existing algorithms either require more knowledge -about the distribution and the problem domain or work only under very limited circumstances. -Even the state of the art special purpose library UNU.RAN does not solve the problem in full -generality, and in any case, testing and customer support for such a library feature would be a -nightmare. +Pete points out the existing wording in [algorithms]/4 +that permits the use of + in algorithm specifications.
--Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. +Alisdair points out that that wording may not apply to input iterators.
- -[ -Bellevue: -]
- - -+ + +-Disagreement persists. +Move to Review.
+Proposed resolution:
-Objection to this issue is that this function takes a general functor. -The general approach would be to normalize this function, integrate it, -and take the inverse of the integral, which is not possible in general. -An example function is sin(1+n*x) -- for any spatial frequency that the -implementor chooses, there is a value of n that renders that choice -arbitrarily erroneous. +In 25.5.4 [alg.merge] replace p.1+ 2:
+ +- - --Correction: The formula above should instead read 1+sin(n*x). +Effects:
+MergesCopies all the elements of the two sorted ranges [first1,last1) and +[first2,last2) into the range +[result,result + (last1 - first1) + (last2 - first2))+[result, last) (where last is equal to result + (last1 +- first1) + (last2 - first2)), such that resulting range will be +sorted in non-decreasing order; that is, for every iterator i in +[result,last) other than result, the condition *i < *(i - 1) or, +respectively, comp(*i, *(i - 1)) will be false.-Objector proposes the following possible compromise positions: +Requires: The resulting range shall not overlap with either of the original ranges.
-The list will be sorted in non-decreasing +order according to the ordering defined by comp; that is, for every iterator i in +[first,last) other than first, the condition *i < *(i - 1) or +comp(*i, *(i - 1)) will be false.-
- -rand.dist.samp.genpdf takes an number of points so that implementor need not guess. -
-- replace rand.disk.samp.genpdf with an extension to either or both -of the discrete functions to take arguments that take a functor and -number of points in place of the list of probabilities. Reference -issues 793 and 794. -
-Proposed resolution:
-See N2424 -for the proposed resolution. +[N.B.: I attempted to reuse the wording style of inplace_merge, +therefore proposing to +insert ", respectively," between both predicate tests. This is no +strictly necessary as +other parts of <algorithm> show, just a matter of consistency]
+
-734. Unnecessary restriction in [rand.dist.norm.chisq]
-Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Review - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with Review status.
+785. Random Number Requirements in TR1
+Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: Tentatively NAD + Submitter: John Maddock Opened: 2008-01-15 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
Discussion:
-chi_squared_distribution, fisher_f_distribution and student_t_distribution -have parameters for the "degrees of freedom" n and m that are specified as integers. For the -following two reasons this is an unnecessary restriction: First, in many applications such as -Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- -eters as continuous variables. Second, the standard non-naive algorithms (i.e. -O(1) algorithms) -for simulating from these distributions work with floating-point parameters anyway (all three -distributions could be easily implemented using the Gamma distribution, for instance). +Table 16 of TR1 requires that all Pseudo Random Number generators have a
--Similar arguments could in principle be made for the parameters t and k of the discrete -binomial_distribution and negative_binomial_distribution, though in both cases continuous -parameters are less frequently used in practice and in case of the binomial_distribution -the implementation would be significantly complicated by a non-discrete parameter (in most -implementations one would need an approximation of the log-gamma function instead of just the -log-factorial function). -
+seed(integer-type s) +-Possible resolution: For these reasons, I propose to change the type of the respective parameters -to double. +member function that is equivalent to:
-[ -Bellevue: +
+ +mygen = Generator(s) ++But the generators xor_combine and discard_block have no such seed member, only the +
+ ++ +template <class Gen> +seed(Gen&); ++member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. +
+ ++So... is this a bug in TR1? +
+ +This is a real issue BTW, since the Boost implementation does adhere +to the requirements of Table 16, while at least one commercial +implementation does not and follows a strict adherence to sections +5.1.4.5 and 5.1.4.6 instead. +
+ +[ +Jens adds: ]
-In N2424. Not wildly enthusiastic, not really felt necessary. Less -frequently used in practice. Not terribly bad either. Move to OPEN. +Both engines do have the necessary +constructor, therefore the omission of the seed() member +functions appears to be an oversight.[ -Sophia Antipolis: +Post Summit Daniel adds: ]
-+-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. -
+Recommend NAD: xor_combine does no longer exist and discard_block[_engine] +has now the required seed overload accepting a result_type, which shall be an +unsigned integral type.[ +Batavia (2009-05): +]
+ ++Move to NAD as recommended. +Proposed resolution:
-See N2424 -for the proposed resolution. +NAD Recommended.
-[ -Stephan Tolksdorf adds pre-Bellevue: -]
--+-In 26.4.8.4.3 [rand.dist.norm.chisq]: -
--+-Delete ", where n is a positive integer" in the first paragraph. -
+
+788. ambiguity in [istream.iterator]
+Section: 24.6.1 [istream.iterator] Status: Open + Submitter: Martin Sebor Opened: 2008-02-06 Last modified: 2009-03-14
+View other active issues in [istream.iterator].
+View all other issues in [istream.iterator].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 287
+ +-Replace both occurrences of "explicit chi_squared_distribution(int n = 1);" -with "explicit chi_squared_distribution(RealType n = 1);". +It is not clear what the initial state of an istream_iterator should be. Is +_value_ initialized by reading the stream, or default/value initialized? If +it is initialized by reading the stream, what happens if the initialization +is deferred until first dereference, when ideally the iterator value should +have been that of an end-of-stream iterator which is not safely +dereferencable?
-Replace both occurrences of "int n() const;" with "RealType n() const;". +Recommendation: Specify _value_ is initialized by reading the stream, or +the iterator takes on the end-of-stream value if the stream is empty.
--In 26.4.8.4.5 [rand.dist.norm.f]: +The description of how an istream_iterator object becomes an +end-of-stream iterator is a) ambiguous and b) out of date WRT +issue 468:
+--Delete ", where m and n are positive integers" in the first paragraph. -
+istream_iterator reads (using operator>>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time ++ is used, the iterator reads and stores a value of T. If +the end of stream is reached (operator void*() on the stream returns +false), the iterator becomes equal to the end-of-stream iterator value. +The constructor with no arguments istream_iterator() always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of operator* on an +end of stream is not defined. For any other iterator value a const T& is +returned. The result of operator-> on an end of stream is not defined. +For any other iterator value a const T* is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that ++ operators are not equality preserving, +that is, i == j does not guarantee at all that ++i == ++j. Every time ++ +is used a new value is read. +-Replace both occurrences of -
--explicit fisher_f_distribution(int m = 1, int n = 1); --with +istream::operator void*() returns null if istream::fail() is true, +otherwise non-null. istream::fail() returns true if failbit or +badbit is set in rdstate(). Reaching the end of stream doesn't +necessarily imply that failbit or badbit is set (e.g., after +extracting an int from stringstream("123") the stream object will +have reached the end of stream but fail() is false and operator +void*() will return a non-null value).
-explicit fisher_f_distribution(RealType m = 1, RealType n = 1); --Replace both occurrences of "int m() const;" with "RealType m() const;". +Also I would prefer to be explicit about calling fail() here +(there is no operator void*() anymore.)
--Replace both occurrences of "int n() const;" with "RealType n() const;". -
-[ +Summit: +]
--In 26.4.8.4.6 [rand.dist.norm.t]: -
---Delete ", where n is a positive integer" in the first paragraph. -
+Moved from Ready to Open for the purposes of using this issue to address NB UK 287. +Martin to handle. +-Replace both occurrences of "explicit student_t_distribution(int n = 1);" -with "explicit student_t_distribution(RealType n = 1);". -
+Proposed resolution:
-Replace both occurrences of "int n() const;" with "RealType n() const;". +Change 24.6.1 [istream.iterator]/1:
-+istream_iterator reads (using operator>>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time ++ is used, the iterator reads and stores a value of T. If +@@ -10530,72 +10154,75 @@ Replace both occurrences of "int n() const;" with "RealType n() conthe end of stream is reachedthe iterator fails to read and store a value of T +(operator void*()fail() on the stream returns +falsetrue), the iterator becomes equal to the end-of-stream iterator value. +The constructor with no arguments istream_iterator() always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of operator* on an +end of stream is not defined. For any other iterator value a const T& is +returned. The result of operator-> on an end of stream is not defined. +For any other iterator value a const T* is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that ++ operators are not equality preserving, +that is, i == j does not guarantee at all that ++i == ++j. Every time ++ +is used a new value is read.
-742. Enabling swap for proxy iterators
-Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-10-10
-View other active issues in [utility.arg.requirements].
-View all other issues in [utility.arg.requirements].
+801. tuple and pair trivial members
+Section: 20.5 [tuple] Status: Open + Submitter: Lawrence Crowl Opened: 2008-02-18 Last modified: 2009-05-30
+View all other issues in [tuple].
View all issues with Open status.
Discussion:
-This issue was split from 672. 672 now just -deals with changing the requirements of T in the Swappable -requirement from CopyConstructible and CopyAssignable to -MoveConstructible and MoveAssignable. +Classes with trivial special member functions are inherently more +efficient than classes without such functions. This efficiency is +particularly pronounced on modern ABIs that can pass small classes +in registers. Examples include value classes such as complex numbers +and floating-point intervals. Perhaps more important, though, are +classes that are simple collections, like pair and tuple. When the +parameter types of these classes are trivial, the pairs and tuples +themselves can be trivial, leading to substantial performance wins.
--This issue seeks to widen the Swappable requirement to support proxy iterators. Here -is example code: +The current working draft make specification of trivial functions +(where possible) much easer through defaulted and deleted functions. +As long as the semantics of defaulted and deleted functions match +the intended semantics, specification of defaulted and deleted +functions will yield more efficient programs. +
++There are at least two cases where specification of an explicitly +defaulted function may be desirable. +
++First, the std::pair template has a non-trivial default constructor, +which prevents static initialization of the pair even when the +types are statically initializable. Changing the definition to
--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 +pair() = default; ++would enable such initialization. Unfortunately, the change is +not semantically neutral in that the current definition effectively +forces value initialization whereas the change would not value +initialize in some contexts. +
-... ++** Does the committee confirm that forced value initialization +was the intent? If not, does the committee wish to change the +behavior of std::pair in C++0x? +
++Second, the same default constructor issue applies to std::tuple. +Furthermore, the tuple copy constructor is current non-trivial, +which effectively prevents passing it in registers. To enable +passing tuples in registers, the copy constructor should be +make explicitly defaulted. The new declarations are: +
-Mine::proxied_iterator<Mine::A> i(...) -Mine::A a; -swap(*i1, a); +tuple() = default; +tuple(const tuple&) = default;-The key point to note in the above code is that in the call to swap, *i1 -and a are different types (currently types can only be Swappable with the -same type). A secondary point is that to support proxies, one must be able to pass rvalues -to swap. But note that I am not stating that the general purpose std::swap -should accept rvalues! Only that overloaded swaps, as in the example above, be allowed -to take rvalues. +This changes is not implementation neutral. In particular, it +prevents implementations based on pointers to the parameter +types. It does however, permit implementations using the +parameter types as bases.
--That is, no standard library code needs to change. We simply need to have a more flexible -definition of Swappable. +** How does the committee wish to trade implementation +efficiency versus implementation flexibility?
[ @@ -10605,294 +10232,207 @@ Bellevue:
+-While we believe Concepts work will define a swappable concept, we -should still resolve this issue if possible to give guidance to the -Concepts work. +General agreement; the first half of the issue is NAD.
-Would an ambiguous swap function in two namespaces found by ADL break -this wording? Suggest that the phrase "valid expression" means such a -pair of types would still not be swappable. +Before voting on the second half, it was agreed that a "Strongly Favor" +vote meant support for trivial tuples (assuming usual requirements met), +even at the expense of other desired qualities. A "Weakly Favor" vote +meant support only if not at the expense of other desired qualities.
-Motivation is proxy-iterators, but facility is considerably more -general. Are we happy going so far? +Concensus: Go forward, but not at expense of other desired qualities.
-We think this wording is probably correct and probably an improvement on -what's there in the WP. On the other hand, what's already there in the -WP is awfully complicated. Why do we need the two bullet points? They're -too implementation-centric. They don't add anything to the semantics of -what swap() means, which is there in the post-condition. What's wrong -with saying that types are swappable if you can call swap() and it -satisfies the semantics of swapping? +It was agreed to Alisdair should fold this work in with his other +pair/tuple action items, above, and that issue 801 should be "open", but +tabled until Alisdair's proposals are disposed of.
[ +2009-05-27 Daniel adds: +]
-Proposed resolution:
--Change 20.1.1 [utility.arg.requirements]: -
-+This is partly solved by 1117. +---1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, T and V are
-is atypes 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;andrv is a non-const -rvalue of type T; w is a value of type T; and v is a value of type V. --
-Table 37: Swappable requirements [swappable] -- expression return type post-condition - swap( sw,tv)void -tw has the value originally -held byuv, and -uv has the value originally held -bytw- + Proposed resolution:
-The Swappable requirement is met by satisfying one or more of the following conditions:
--
-- -T is Swappable if T and V are -the same type and T satisfies the -
-CopyConstructible-MoveConstructible requirements (Table34-33) and theCopyAssignable-MoveAssignable requirements (Table36-35); -- -T is Swappable with V if a namespace scope function named -swap exists in the same namespace as the definition of -T or V, such that the expression -swap(
-tw,uv) is valid and has the -semantics described in this table. -
-747. We have 3 separate type traits to identify classes supporting no-throw operations
-Section: 20.5.4.3 [meta.unary.prop] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10
-View all other issues in [meta.unary.prop].
-View all issues with Open status.
+810. Missing traits dependencies in operational semantics of extended manipulators
+Section: 27.7.4 [ext.manip] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-03-01 Last modified: 2009-05-23
+View all other issues in [ext.manip].
+View all issues with Tentatively Ready status.
Discussion:
-We have 3 separate type traits to identify classes supporting no-throw -operations, which are very useful when trying to provide exception safety -guarantees. However, I'm not entirely clear on what the current wording -requires of a conforming implementation. To quote from -has_nothrow_default_constructor: -
---or T is a class type with a default constructor that is known not to throw -any exceptions -
-What level of magic do we expect to deduce if this is known? +The recent draft (as well as the original proposal n2072) uses an +operational semantic +for get_money ([ext.manip]/4) and put_money ([ext.manip]/6), which uses
+ ++istreambuf_iterator<charT> +-E.g. +and
-+Counterarguments: + +struct test{ - int x; - test() : x() {} -}; ++ostreambuf_iterator<charT>-Should I expect a conforming compiler to - assert( has_nothrow_constructor<test>::value ) -
--Is this a QoI issue? -
--Should I expect to 'know' only if-and-only-if there is an inline definition -available? -
--Should I never expect that to be true, and insist that the user supplies an -empty throw spec if they want to assert the no-throw guarantee? -
--It would be helpful to maybe have a footnote explaining what is required, -but right now I don't know what to suggest putting in the footnote. +resp, instead of the iterator instances, with explicitly provided +traits argument (The operational semantic defined by f is also traits +dependent). This is an obvious oversight because both *stream_buf +c'tors expect a basic_streambuf<charT,traits> as argument.
-(agreement since is that trivial ops and explicit no-throws are required. -Open if QoI should be allowed to detect further) +The same problem occurs within the get_time and put_time semantic +where additional to the problem we +have an editorial issue in get_time (streambuf_iterator instead of +istreambuf_iterator).
[ -Bellevue: +Batavia (2009-05): ]
--This looks like a QoI issue. -In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. -Move to OPEN. Need to talk to Core about this. ++This appears to be an issue of presentation. +
++We agree with the proposed resolution. +Move to Tentatively Ready. +
Proposed resolution:
+In 27.7.4 [ext.manip]/4 within function f replace the first line
++template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { + typedef istreambuf_iterator<charT, traits> Iter; + ... ++In 27.7.4 [ext.manip]/5 remove the first template charT parameter: +
+- -template <class charT,class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); +
-750. The current definition for is_convertible requires that the type be -implicitly convertible, so explicit constructors are ignored.
-Section: 20.5.5 [meta.rel] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10
-View all issues with Open status.
-Discussion:
-With the pending arrival of explicit conversion functions though, I'm -wondering if we want an additional trait, is_explictly_convertible? +In 27.7.4 [ext.manip]/6 within function f replace the first line
-[ -Bellevue: -]
++template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { + typedef ostreambuf_iterator<charT, traits> Iter; + ... ++In 27.7.4 [ext.manip]/8 within function f replace the first line +
--Alisdair is considering preparing a paper listing a number of missing -type traits, and feels that it might be useful to handle them all -together rather than piecemeal. This would affect issue 719 and 750. -These two issues should move to OPEN pending AM paper on type traits. -++template <class charT, class traits> +void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { + typedef istreambuf_iterator<charT, traits> Iter; + ... ++In 27.7.4 [ext.manip]/10 within function f replace the first line +
+ +-template <class charT, class traits> +void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { + typedef ostreambuf_iterator<charT, traits> Iter; + ... +Proposed resolution:
+In 27.7 [iostream.format], Header <iomanip> synopsis change:
++template <class charT,class moneyT> T8 put_money(const moneyT& mon, bool intl = false); +
-751. change pass-by-reference members of vector<bool> to pass-by-value?
-Section: 23.2.7 [vector.bool] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10
+814. vector<bool>::swap(reference, reference) not defined
+Section: 23.3.7 [vector.bool] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2008-03-17 Last modified: 2009-05-23
View other active issues in [vector.bool].
View all other issues in [vector.bool].
-View all issues with New status.
+View all issues with Tentatively Ready status.
Discussion:
-A number of vector<bool> members take const bool& as arguments. -Is there any chance we could change them to pass-by-value or would I -be wasting everyone's time if wrote up an issue? +vector<bool>::swap(reference, reference) has no definition.
[ -post Bellevue: +San Francisco: ]
-+-As we understand it, the original requester (Martin Sebor) would like -for implementations to be permitted to pass-by-value. Alisdair suggests -that if this is to be resolved, it should be resolved more generally, -e.g. in other containers as well. -
--We note that this would break ABI. However, we also suspect that this -might be covered under the "as-if" rule in section 1.9. -
--Many in the group feel that for vector<bool>, this is a "don't care", -and that at this point in the process it's not worth the bandwidth. -
--Issue 679 -- which was in ready status pre-Bellevue and is -now in the working paper -- is related to this, though not a duplicate. -
--Moving to Open with a task for Alisdair to craft a informative note to -be put whereever appropriate in the WP. This note would clarify places -where pass-by-const-ref can be transformed to pass-by-value under the -as-if rule. -
+Move to Open. Alisdair to provide a resolution.[ +Post Summit Daniel provided wording. +]
-Proposed resolution:
--
- - +[ +Batavia (2009-05): +]
++We agree with the proposed resolution. +Move to Tentatively Ready. +-
-752. Allocator complexity requirement
-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 Review status.
-Discussion:
--Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations -on the allocators are expected to be amortized constant time."? -
--As I think I pointed out earlier, this is currently fiction for -allocate() if it has to obtain memory from the OS, and it's unclear to -me how to interpret this for construct() and destroy() if they deal with -large objects. Would it be controversial to officially let these take -time linear in the size of the object, as they already do in real life? -
+Proposed resolution:
-Allocate() more blatantly takes time proportional to the size of the -object if you mix in GC. But it's not really a new problem, and I think -we'd be confusing things by leaving the bogus requirements there. The -current requirement on allocate() is generally not important anyway, -since it takes O(size) to construct objects in the resulting space. -There are real performance issues here, but they're all concerned with -the constants, not the asymptotic complexity. +Just after 23.3.7 [vector.bool]/5 add the following prototype and description:
- -Proposed resolution:
+@@ -10900,830 +10440,734 @@ requirements on allocator types.-Change 20.1.2 [allocator.requirements]/2: +static void swap(reference x, reference y);
---2- Table 39 describes the requirements on types manipulated through -allocators.
+All the operations on the allocators are expected to be -amortized constant time.Table 40 describes the -requirements on allocator types. +-6- Effects: Exchanges the contents of x and y as-if by:++bool b = x; +x = y; +y = b; +
-753. Move constructor in draft
-Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Yechezkel Mett Date: 2007-10-14
-View other active issues in [utility.arg.requirements].
-View all other issues in [utility.arg.requirements].
+815. std::function and reference_closure do not use perfect forwarding
+Section: 20.7.16.2.4 [func.wrap.func.inv] Status: Open + Submitter: Alisdair Meredith Opened: 2008-03-16 Last modified: 2009-06-01
View all issues with Open status.
Discussion:
-The draft standard n2369 uses the term move constructor in a few -places, but doesn't seem to define it. +std::function and reference_closure should use "perfect forwarding" as +described in the rvalue core proposal.
--MoveConstructible requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as -follows: -
+[ +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.MoveConstructible requirements -- -expression post-condition -- -T t = rv t is equivalent to the value of rv before the construction -- -[Note: There is no requirement on the value of rv after the -construction. -- end note] --(where rv is a non-const rvalue of type T). -
- --So I assume the move constructor is the constructor that would be used -in filling the above requirement. -
+[ +2009-05-01 Howard adds: +]
--For vector::reserve, vector::resize and the vector modifiers given in -23.2.6.4 [vector.modifiers] we have -
-Requires: If value_type has a move constructor, that constructor shall -not throw any exceptions. ---Firstly "If value_type has a move constructor" is superfluous; every -type which can be put into a vector has a move constructor (a copy -constructor is also a move constructor). Secondly it means that for -any value_type which has a throwing copy constructor and no other move -constructor these functions cannot be used -- which I think will come -as a shock to people who have been using such types in vector until -now! +Sebastian Gesemann brought to my attention that the CopyConstructible +requirement on function's ArgTypes... is an unnecessary +restriction.
--I can see two ways to correct this. The simpler, which is presumably -what was intended, is to say "If value_type has a move constructor and -no copy constructor, the move constructor shall not throw any -exceptions" or "If value_type has a move constructor which changes the -value of its parameter,". -
+template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> +... +-The other alternative is add to MoveConstructible the requirement that -the expression does not throw. This would mean that not every type -that satisfies the CopyConstructible requirements also satisfies the -MoveConstructible requirements. It would mean changing requirements in -various places in the draft to allow either MoveConstructible or -CopyConstructible, but I think the result would be clearer and -possibly more concise too. +On further investigation, this complaint seemed to be the same +issue as this one. I believe the reason CopyConstructible was put +on ArgTypes in the first place was because of the nature of the +invoke member:
+-template<class R, class ...ArgTypes> +R +function<R(ArgTypes...)>::operator()(ArgTypes... arg) const +{ + if (f_ == 0) + throw bad_function_call(); + return (*f_)(arg...); +} +Proposed resolution:
-Add new defintions to 17.1 [definitions]: +However now with rvalue-refs, "by value" no longer implies CopyConstructible +(as Sebastian correctly points out). If rvalue arguments are supplied, MoveConstructible +is sufficient. Furthermore, the constraint need not be applied in function +if I understand correctly. Rather the client must apply the proper constraints +at the call site. Therefore, at the very least, I recommend that CopyConstructible +be removed from the template class function.
--- --move constructor -
--a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the construction. -
--move assignment operator -
--an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the assignment. -
--move assignment -
-use of the move assignment operator. +Furthermore we need to mandate that the invoker is coded as:
-[ -Howard adds post-Bellevue: -]
+-template<class R, class ...ArgTypes> +R +function<R(ArgTypes...)>::operator()(ArgTypes... arg) const +{ + if (f_ == 0) + throw bad_function_call(); + return (*f_)(std::forward<ArgTypes>(arg)...); +} +- - - - - --Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. reserve et. al. will use a move constructor -if one is available, else it will use a copy constructor. A type may have both. If the move constructor is -used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording -is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am -unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) +Note that ArgTypes&& (the "perfect forwarding signature") is not +appropriate here as this is not a deduced context for ArgTypes. Instead +the client's arguments must implicitly convert to the non-deduced ArgType +type. Catching these arguments by value makes sense to enable decay.
-
-758. shared_ptr and nullptr
-Section: 20.7.12.2 [util.smartptr.shared] Status: Review - Submitter: Joe Gottman Date: 2007-10-31
-View other active issues in [util.smartptr.shared].
-View all other issues in [util.smartptr.shared].
-View all issues with Review status.
-Discussion:
-Consider the following program: +Next forward is used to move the ArgTypes as efficiently as +possible, and also with minimum requirements (not CopyConstructible) +to the type-erased functor. For object types, this will be a move. For +reference type ArgTypes, this will be a copy. The end result must be +that the following is a valid program:
-+int main() { - shared_ptr<int> p(nullptr); - return 0; -} --#include <functional> +#include <memory> +#include <cassert> --This program will fail to compile because shared_ptr uses the following -template constructor to construct itself from pointers: -
+std::unique_ptr<int> +f(std::unique_ptr<int> p, int& i) +{ + ++i; + return std::move(p); +} --template <class Y> shared_ptr(Y *); +int main() +{ + int i = 2; + std::function<std::unique_ptr<int>(std::unique_ptr<int>, + int&> g(f); + std::unique_ptr<int> p = g(std::unique_ptr<int>(new int(1)), i); + assert(*p == 1); + assert(i == 3); +}-According -to N2431, -the conversion from nullptr_t to Y * is not -deducible, so the above constructor will not be found. There are similar problems with the -constructors that take a pointer and a deleter or a -pointer, a deleter and an allocator, as well as the -corresponding forms of reset(). Note that N2435 -will solve this problem for constructing from just nullptr, but not for constructors that use -deleters or allocators or for reset(). -
- --In the case of the functions that take deleters, there is the additional -question of what argument should be passed to the deleter when it is -eventually called. There are two reasonable possibilities: nullptr or -static_cast<T *>(0), where T is the template argument of the -shared_ptr. It is not immediately clear which of these is better. If -D::operator() is a template function similar to shared_ptr's -constructor, then d(static_cast<T*>(0)) will compile and d(nullptr) -will not. On the other hand, if D::operator()() takes a parameter that -is a pointer to some type other that T (for instance U* where U derives -from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not. -
-[ -Bellevue: +Tested in pre-concepts rvalue-ref-enabled compiler. ]
---The general idea is right, we need to be able to pass a nullptr to a -shared_ptr, but there are a few borderline editorial issues here. (For -example, the single-argument nullptr_t constructor in the class synopsis -isn't marked explicit, but it is marked explicit in the proposed wording -for 20.6.6.2.1. There is a missing empty parenthesis in the form that -takes a nullptr_t, a deleter, and an allocator.) -
--More seriously: this issue says that a shared_ptr constructed from a -nullptr is empty. Since "empty" is undefined, it's hard to know whether -that's right. This issue is pending on handling that term better. -
--Peter suggests definition of empty should be "does not own anything" -
--Is there an editorial issue that post-conditions should refer to get() = -nullptr, rather than get() = 0? -
--No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. -
--Seems there are no technical merits between NAD and Ready, comes down to -"Do we intentially want to allow/disallow null pointers with these -functions". Staw Poll - support null pointers 5 - No null pointers 0 -
-Move to Ready, modulo editorial comments +In the example above, the first ArgType is unique_ptr<int> +and the second ArgType is int&. Both must work!
+[ -post Bellevue Peter adds: +2009-05-27 Daniel adds: ]
--The following wording changes are less intrusive: +in the 2009-05-01 comment of above mentioned issue Howard
++
- +Recommends to replace the CopyConstructible requirement by a +MoveConstructible requirement +
+- +Says: "Furthermore, the constraint need not be applied in function if I +understand correctly. Rather the client must apply the proper constraints +at the call site" +
+-In 20.7.12.2.1 [util.smartptr.shared.const], add: +I'm fine with (a), but I think comment (b) is incorrect, at least in the +sense I read these sentences. Let's look at Howard's example code:
--shared_ptr(nullptr_t); +function<R(ArgTypes...)>::operator()(ArgTypes... arg) const +{ + if (f_ == 0) + throw bad_function_call(); + return (*f_)(std::forward<ArgTypes>(arg)...); +}-after: +In the constrained scope of this operator() overload the expression +"(*f_)(std::forward<ArgTypes>(arg)...)" must be valid. How can it +do so, if ArgTypes aren't at least MoveConstructible?
+-shared_ptr(); --(Absence of explicit intentional.) -
+Proposed resolution:
-px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so -I'm not convinced of its utility. -
--It's similarly not clear to me whether the deleter constructors need to be -extended to take nullptr, but if they need to: -
--Add
--template<class D> shared_ptr(nullptr_t p, D d); -template<class D, class A> shared_ptr(nullptr_t p, D d, A a); --after -
-+ +template<class Y, class D> shared_ptr(Y* p, D d); -template<class Y, class D, class A> shared_ptr(Y* p, D d, A a); -
+816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
+Section: 20.7.12.1.3 [func.bind.bind] Status: Open + Submitter: Stephan T. Lavavej Opened: 2008-02-08 Last modified: 2009-05-23
+View other active issues in [func.bind.bind].
+View all other issues in [func.bind.bind].
+View all issues with Open status.
+Discussion:
-Note that this changes the semantics of the new constructors such that they -consistently call d(p) instead of d((T*)0) when p is nullptr. +Library Issue 527 notes that bind(f, t1, ..., tN) +should be nofail when f, t1, ..., tN have nofail copy ctors.
-The ability to be able to pass 0/NULL to a function that takes a shared_ptr -has repeatedly been requested by users, but the other additions that the -proposed resolution makes are not supported by real world demand or -motivating examples. +However, no guarantees are provided for the copy ctor of the functor +returned by bind(). (It's guaranteed to have a copy ctor, which can +throw implementation-defined exceptions: bind() returns a forwarding +call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, +TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. +Everything without an exception-specification may throw +implementation-defined exceptions unless otherwise specified, C++03 +17.4.4.8/3.)
-It might be useful to split the obvious and non-controversial nullptr_t -constructor into a separate issue. Waiting for "empty" to be clarified is -unnecessary; this is effectively an alias for the default constructor. +Should the nofail guarantee requested by Library Issue 527 be extended +to cover both calling bind() and copying the returned functor?
+ +[ +Howard adds: +]
+ + ++tuple construction should probably have a similar guarantee.[ -Sophia Antipolis: +San Francisco: +]
+ + ++Howard to provide wording. ++ +[ +Post Summit, Anthony provided wording. ]
+[ +Batavia (2009-05): +]
++Part of all of this issue appears to be rendered moot +by the proposed resolution to issue 817 (q.v.). +We recommend the issues be considered simultaneously +(or possibly even merged) +to ensure there is no overlap. +Move to Open, and likewise for issue 817. ++ + +Proposed resolution:
-We want to remove the reset functions from the proposed resolution. +Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:
+ ++-The remaining proposed resolution text (addressing the constructors) are wanted. +-2- Returns: A forwarding call wrapper g with a weak result type (20.6.2). The effect of g(u1, u2, +..., uM) shall be INVOKE(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type), where cv +represents the cv-qualifiers of g and the values and types of the bound arguments +v1, v2, ..., vN are determined as specified below. +The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of F or any of the types +in BoundArgs... throw an exception.
+...
-Disposition: move to review. The review should check the wording in the then-current working draft. +-4- Returns: A forwarding call wrapper g with a nested type result_type defined as a synonym +for R. The effect of g(u1, u2, ..., uM) shall be INVOKE(f, v1, v2, ..., vN, R), where the +values and types of the bound arguments v1, v2, ..., vN are determined as specified below. +The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of F or any of the types +in BoundArgs... throw an exception.
-Proposed resolution:
--Add the following constructors to 20.7.12.2 [util.smartptr.shared]: -
-+shared_ptr(nullptr_t); -template <class D> shared_ptr(nullptr_t, D d); -template <class D, class A> shared_ptr(nullptr_t, D d, A a); -
+817. bind needs to be moved
+Section: 20.7.12.1.3 [func.bind.bind] Status: Open + Submitter: Howard Hinnant Opened: 2008-03-17 Last modified: 2009-05-23
+View other active issues in [func.bind.bind].
+View all other issues in [func.bind.bind].
+View all issues with Open status.
+Discussion:
+Addresses US 72, JP 38 and DE 21
-Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: +The functor returned by bind() should have a move constructor that +requires only move construction of its contained functor and bound arguments. +That way move-only functors can be passed to objects such as thread.
- --explicit shared_ptr(nullptr_t); ----Effects: Constructs an empty shared_ptr object. +This issue is related to issue 816.
+-Postconditions: use_count() == 0 && get() == 0. +US 72:
+ ++bind should support move-only functors and bound arguments. ++-Throws: nothing. +JP 38:
--- - - - - - - -template <class D> shared_ptr(nullptr_t, D d); -template <class D, class A> shared_ptr<nullptr_t, D d, A a); ----Requires: D shall be CopyConstructible. The copy constructor and -destructor of D shall not throw exceptions. The expression -d(static_cast<T *>(0)) shall be well-formed, shall have well defined behavior, -and shall not throw exceptions. A shall be an allocator (20.1.2 [allocator.requirements]). -The copy constructor and destructor of A shall not throw -exceptions. +add the move requirement for bind's return type.
-Effects: Constructs a shared_ptr object that owns a null pointer of type T * -and deleter d. The -second constructor shall use a copy of a to allocate memory for -internal use. +For example, assume following th1 and th2,
+ ++void f(vector<int> v) { } + +vector<int> v{ ... }; +thread th1([v]{ f(v); }); +thread th2(bind(f, v)); +-Postconditions: use_count() == 1 and get() == 0. +When function object are set to thread, v is moved to th1's lambda +expression in a Move Constructor of lambda expression because th1's lambda +expression has a Move Constructor. But bind of th2's +return type doesn't have the requirement of Move, so it may not +moved but copied.
-Throws: bad_alloc, or an implementation-defined exception when a -resource other than memory could not be obtained. +Add the requirement of move to get rid of this useless copy.
-Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called. +And also, add the MoveConstructible as well as CopyConstructible.
-760. The emplace issue
-Section: 23.1 [container.requirements] Status: Open - Submitter: Paolo Carlini Date: 2007-11-11
-View other active issues in [container.requirements].
-View all other issues in [container.requirements].
-View all issues with Open status.
-Discussion:
-In an emplace member function the function parameter pack may be bound -to a priori unlimited number of objects: some or all of them can be -elements of the container itself. Apparently, in order to conform to the -blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for -that possibility. A possible solution can involve extending the -exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the -push_back and push_front member functions are luckily not affected by -this problem, can be efficiently implemented anyway +DE 21
++The specification for bind claims twice that "the values and types for +the bound arguments v1, v2, ..., vN are determined as specified below". +No such specification appears to exist. ++[ -Related to 767 +San Francisco: ]
++Howard to provide wording. ++[ -Bellevue: +Post Summit Alisdair and Howard provided wording. ]
- +-The proposed addition (13) is partially redundant with the existing -paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why -does it not cover subelements and pointers? -
--Resolution: Alan Talbot to rework language, then set state to Review. +Several issues are being combined in this resolution. They are all touching the +same words so this is an attempt to keep one issue from stepping on another, and +a place to see the complete solution in one place.
-+
+- +bind needs to be "moved". +
+- +20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798. +
+- +Issue 929 argues for a way to pass by && for +efficiency but retain the decaying behavior of pass by value for the +thread constructor. That same solution is applicable here. +
+Proposed resolution:
--Add after 23.1 [container.requirements]/12: -
+[ +Batavia (2009-05): +]
+--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No -diagnostic required. +We were going to recommend moving this issue to Tentatively Ready +until we noticed potential overlap with issue 816 (q.v.).
- --13- Objects bound to the function parameter pack of the emplace member function shall not be elements or -sub-objects of elements of the container. No diagnostic required. - +Move to Open, +and recommend both issues be considered together +(and possibly merged).
-Proposed resolution:
++Change 20.7 [function.objects] p2: +
+- - -template<CopyConstructibleMoveConstructible Fn,CopyConstructibleMoveConstructible... Types> + unspecified bind(Fn&&, Types&&...); +template<Returnable R,CopyConstructibleMoveConstructible Fn,CopyConstructibleMoveConstructible... Types> + unspecified bind(Fn&&, Types&&...); +
-762. std::unique_ptr requires complete type?
-Section: 20.7.11 [unique.ptr] Status: Ready - Submitter: Daniel Krügler Date: 2007-11-30
-View all other issues in [unique.ptr].
-View all issues with Ready status.
-Discussion:
-In contrast to the proposed std::shared_ptr, std::unique_ptr -does currently not support incomplete types, because it -gives no explicit grant - thus instantiating unique_ptr with -an incomplete pointee type T automatically belongs to -undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last -bullet. This is an unnecessary restriction and prevents -many well-established patterns - like the bridge pattern - -for std::unique_ptr. +Change 20.7.12.1.3 [func.bind.bind]:
-[ -Bellevue: -]
- +-template<CopyConstructibleMoveConstructible F,CopyConstructibleMoveConstructible... BoundArgs> + unspecified bind(F&& f, BoundArgs&&... bound_args); +-Move to open. The LWG is comfortable with the intent of allowing -incomplete types and making unique_ptr more like shared_ptr, but we are -not comfortable with the wording. The specification for unique_ptr -should be more like that of shared_ptr. We need to know, for individual -member functions, which ones require their types to be complete. The -shared_ptr specification is careful to say that for each function, and -we need the same level of care here. We also aren't comfortable with the -"part of the operational semantic" language; it's not used elsewhere in -the standard, and it's not clear what it means. We need a volunteer to -produce new wording. -- - -Proposed resolution:
-The proposed changes in the following revision refers to the current state of -N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed -according to the current state of 740. +Requires: unspecified return type shall be MoveConstructible.
-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.7.11.3 [unique.ptr.runtime]/1: -"T shall be a complete type, if used as template argument of -unique_ptr<T[], D> +-1- Requires: INVOKE(f, w1, w2, ..., wN) (20.6.2) shall be a valid expression for some values +w1, w2, ..., wN, where N == sizeof...(bound_args).
-This issue has some overlap with 673, but it seems not to cause any -problems with this one, -because 673 adds only optional requirements on D that do not conflict -with the here discussed -ones, provided that D::pointer's operations (including default -construction, copy construction/assignment, -and pointer conversion) are specified not to throw, otherwise this -would have impact on the -current specification of unique_ptr. +-2- Returns: A forwarding call wrapper g with a weak result type (20.6.2). The effect of g(u1, u2, +..., uM) shall be INVOKE(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type), where cv +represents the cv-qualifiers of g and the values and types of the bound arguments +v1, v2, ..., vN are determined as specified below.
++Throws: Nothing unless the constructor of F or of one of the types in the BoundArgs... pack expansion +throws an exception. +
+-
- -
- --In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: -
+template<Returnable R,CopyConstructibleMoveConstructible F,CopyConstructibleMoveConstructible... BoundArgs> + unspecified bind(F&& f, BoundArgs&&... bound_args); +-The unique_ptr provides a semantics of strict ownership. A -unique_ptr owns the object it holds a pointer to. A -unique_ptr is not CopyConstructible, nor -CopyAssignable, however it is MoveConstructible and -MoveAssignable. The template parameter T of -unique_ptr may be an incomplete type. [ Note: The -uses of unique_ptr include providing exception safety for -dynamically allcoated memory, passing ownership of dynamically allocated -memory to a function, and returning dynamically allocated memory from a -function. -- end note ] --- - -
-20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +Requires: unspecified return type shall be MoveConstructible.
- ---[ -N.B.: We only need the requirement that D is DefaultConstructible. -The current wording says just this. -]
- -- -
-In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: +-3- Requires: INVOKE(f, w1, w2, ..., wN) shall be a valid expression for some values w1, w2, ..., +wN, where N == sizeof...(bound_args).
- ---Requires:
-The expression D()(p) shall be well formed. The default constructor -of D shall not throw an exception.-D must not be a reference type.- -D shall be default constructible, and that construction -shall not throw an exception. - +-4- Returns: A forwarding call wrapper g with a nested type result_type defined as a synonym +for R. The effect of g(u1, u2, ..., uM) shall be INVOKE(f, v1, v2, ..., vN, R), where the +values and types of the bound arguments v1, v2, ..., vN are determined as specified below.[ -N.B.: There is no need that the expression D()(p) is well-formed at -this point. I assume that the current wording is based on the -corresponding shared_ptr wording. In case of shared_ptr this -requirement is necessary, because the corresponding c'tor *can* fail -and must invoke delete p/d(p) in this case. Unique_ptr is simpler in -this regard. The *only* functions that must insist on well-formedness -and well-definedness of the expression get_deleter()(get()) are (1) -the destructor and (2) reset. The reasoning for the wording change to -explicitly require DefaultConstructible of D is to guarantee that -invocation of -D's default c'tor is both well-formed and well-defined. Note also that -we do *not* need the -requirement that T must be complete, also in contrast to shared_ptr. -Shared_ptr needs this, because it's c'tor is a template c'tor which -potentially requires Convertible<Y*, X*>, which -again requires Completeness of Y, if !SameType<X, Y> -]
++
+Throws: Nothing unless the constructor of F or of one of the types in the BoundArgs... pack expansion +throws an exception. +
- -
--Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence -of 12, but transferring the "requires" to 13: -
++Let the values of bound arguments v1, v2, ..., vN and +their corresponding types V1, V2, ..., VN depend on the type of +the corresponding argument ti in bound_args in the +call to bind and the cv-qualifiers cv of the call +wrapper g as follows. Let Ti be an alias for the ith +element of the pack expansion decay<BoundArgs>::type..., +and let ti be an alias for the ith element in the function +parameter pack expansion bound_args...: +
----Requires: If D is not an lvalue-reference type then[..] -
-[ -N.B.: For the same reasons as for (3), there is no need that d(p) is -well-formed/well-defined at this point. The current wording guarantees -all what we need, namely that the initialization of both the T* -pointer and the D deleter are well-formed and well-defined. -]
++
- +if ti is of type reference_wrapper<T> the argument is +ti.get() and its type Vi is T&; +
+- +if the value of std::is_bind_expression<Ti>::value is true the argument is ti(u1, u2, ..., uM) and +its type Vi is result_of<Ti cv (U1&, U2&, ..., UM&)>::type; +
+- +if the value j of std::is_placeholder<Ti>::value is not zero the argument is std::forward<Uj>(uj) and +its type Vi is Uj&&; +
+- +otherwise the value is ti and its type Vi is Ti cv &. +
+- -20.7.11.2.1 [unique.ptr.single.ctor]/17: 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 -is completely defined, because it requires that Convertible<U*, T*> is -true. If the committee wishes this explicit requirement can be added, -e.g. "U shall be a complete type." -]
-- + +
-
+819. rethrow_if_nested
+Section: 18.8.6 [except.nested] Status: Open + Submitter: Alisdair Meredith Opened: 2008-03-25 Last modified: 2008-09-17
+View other active issues in [except.nested].
+View all other issues in [except.nested].
+View all issues with Open status.
+Discussion:
-20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: +Looking at the wording I submitted for rethrow_if_nested, I don't think I +got it quite right.
-+-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] +The current wording says:
-[ -N.B.: This requirement ensures that the whole responsibility on -type-completeness of T is delegated to this expression. -]
++-template <class E> void rethrow_if_nested(const E& e); ++++Effects: Calls e.rethrow_nested() only if e +is publicly derived from nested_exception. +
+- - -
-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. +This is trying to be a bit subtle, by requiring e (not E) to be publicly +derived from nested_exception the idea is that a dynamic_cast would be +required to be sure. Unfortunately, if e is dynamically but not statically +derived from nested_exception, e.rethrow_nested() is ill-formed.
[ -N.B. The current wording is sufficient, because we can delegate all -further requirements on the requirements of the effects clause +San Francisco: ]
-- -
+-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] +Alisdair was volunteered to provide wording.-[ -N.B.: The current wording of p. 6 already implicitly guarantees that -U is completely defined, because it requires that Convertible<U*, T*> -is true, see (6)+(8). -]
-Proposed resolution:
-- -
--20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. -
-[ -N.B.: Delegation to requirements of effects clause is sufficient. -]
-- -20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: -
---T* operator->() const;--Note: Use typically requires T shall be complete. -- end note] --- -20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. -
+
+822. Object with explicit copy constructor no longer CopyConstructible
+Section: X [utility.arg.requirements] Status: Tentatively NAD + Submitter: James Kanze Opened: 2008-04-01 Last modified: 2009-05-23
+View all other issues in [utility.arg.requirements].
+View all issues with Tentatively NAD status.
+Discussion:
++I just noticed that the following program is legal in C++03, but +is forbidden in the current draft: +
+ +-#include <vector> +#include <iostream> + +class Toto +{ +public: + Toto() {} + explicit Toto( Toto const& ) {} +} ; + +int +main() +{ + std::vector< Toto > v( 10 ) ; + return 0 ; +} +- -
-20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: +Is this change intentional? (And if so, what is the +justification? I wouldn't call such code good, but I don't see +any reason to break it unless we get something else in return.)
+ +[ +San Francisco: +]
+ +-Requires: The expression get_deleter()(get()) shall be well-formed, -shall have well-defined behavior, and shall not throw exceptions. +The subgroup that looked at this felt this was a good change, but it may +already be handled by incoming concepts (we're not sure).-- -20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. -
+ +Original Proposed resolution: + -- -
-20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: +In X [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]:
+++
++ +expression post-condition ++ +T t(rv) = rvt is equivalent to the value of rv before the construction ++ +... +-A specialization for array types is provided with a slightly altered interface. +In X [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]:
--
+- -... -
-- -T shall be a complete type. -
-+-+
+ +expression post-condition ++ +T t(u) = uthe value of u is unchanged and is equivalent to t ++ +... +[ -post Bellevue: Daniel provided revised wording. +Post Summit: ]
++++Alisdair: Proposed resolution kinda funky as these tables no longer +exist. Move from direct init to copy init. Clarify with Doug, recommends +NAD. +
++Walter: Suggest NAD via introduction of concepts. +
++Recommend close as NAD. +
+Proposed resolution:
++Recommend close as NAD. +
-
-765. more on iterator validity
-Section: 24.1 [iterator.requirements] Status: New - Submitter: Martin Sebor Date: 2007-12-14
-View other active issues in [iterator.requirements].
-View all other issues in [iterator.requirements].
-View all issues with New status.
-Discussion:
-- -Issue 278 -defines the meaning of the term "invalid iterator" as one that may be -singular. - -
-- -Consider the following code: - -
-std::deque<int> x, y; - std::deque<int>::iterator i = x.end(), j = y.end(); - x.swap(y); ---Given that
-swap()
is required not to invalidate iterators -and using the definition above, what should be the expected result of -comparingi
andj
tox.end()
-andy.end()
, respectively, after theswap()
? --I.e., is the expression below required to evaluate -to
true
? +
+825. Missing rvalues reference stream insert/extract operators?
+Section: 19.5.2.2 [syserr.errcode.overview], 20.8.13.2.8 +[util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.6.3 +[bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.10 +[re.submatch] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2008-04-10 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++Should the following use rvalues references to stream in insert/extract +operators? +
- -i == y.end() && j == x.end() --+
+
-(There are at least two implementations where the expression -returns- 19.5.2.2 [syserr.errcode.overview]
+- 20.8.13.2.8 [util.smartptr.shared.io]
+- 22.4.8 [facets.examples]
+- 20.3.6.3 [bitset.operators]
+- 26.4.6 [complex.ops]
+- Doubled signatures in 27.6 [stream.buffers] for character inserters +(ref 27.7.2.6.4 [ostream.inserters.character]) ++ definition 27.7.2.6.4 [ostream.inserters.character]
+- 28.10 [re.submatch]
+false
.) +[ +Sophia Antipolis +]
- --More generally, is the definition introduced in issue 278 meant to -make any guarantees about whether iterators actually point to the same -elements or be associated with the same containers after a -non-invalidating operation as they did before? +
+Agree with the idea in the issue, Alisdair to provide wording. +- -+
[ +Daniel adds 2009-02-14: +]
-Here's a motivating example intended to demonstrate the importance of -the question: - -Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 } - Container::iterator i = y.begin() + 1; - Container::iterator j = y.end(); - std::swap(x, y); - std::find(i, j, 3); --+
+The proposal given in the paper +N2831 +apparently resolves this issue. +-swap()
guarantees thati
andj
-continue to be valid. Unless the spec says that even though they are -valid they may no longer denote a valid range the code above must be -well-defined. Expert opinions on this differ as does the behavior of -popular implementations for some standardContainers
. +[ +Batavia (2009-05): +]
- +++The cited paper is an earlier version of +N2844, +which changed the rvalue reference binding rules. +That paper includes generic templates +operator<< and operator>> +that adapt rvalue streams. +
++We therefore agree with Daniel's observation. +Move to NAD Editorial. +
+Proposed resolution:
@@ -11735,1793 +11179,1718 @@ popular implementations for some standardContainers
.
-769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"
-Section: 20.6.15.2 [func.wrap.func] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-10
-View all issues with Ready status.
+827. constexpr shared_ptr::shared_ptr()?
+Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Open + Submitter: Peter Dimov Opened: 2008-04-11 Last modified: 2009-05-30
+View other active issues in [util.smartptr.shared.const].
+View all other issues in [util.smartptr.shared.const].
+View all issues with Open status.
Discussion:
-N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed -(implicit) conversion operator to "unspecified-bool-type" by the new -explicit bool conversion, but the inverse conversion should also -use the new std::nullptr_t type instead of "unspecified-null-pointer- -type". +Would anyone object to making the default constructor of shared_ptr (and +weak_ptr and enable_shared_from_this) constexpr? This would enable +static initialization for shared_ptr variables, eliminating another +unfair advantage of raw pointers.
+[ +San Francisco: +]
-Proposed resolution:
++ +-In 20.6 [function.objects], header <functional> synopsis replace: +It's not clear to us that you can initialize a pointer with the literal +0 in a constant expression. We need to ask CWG to make sure this works. +Bjarne has been appointed to do this.
- --template<class R, class... ArgTypes> - bool operator==(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); -template<class R, class... ArgTypes> - bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); -template<class R, class... ArgTypes> - bool operator!=(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); -template<class R, class... ArgTypes> - bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); --In the class function synopsis of 20.6.15.2 [func.wrap.func] replace +Core got back to us and assured as that nullptr would do the job +nicely here.
+[ +2009-05-01 Alisdair adds: +]
-+function(unspecified-null-pointer-typenullptr_t); -... -function& operator=(unspecified-null-pointer-typenullptr_t); ---In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: +I don't believe that constexpr will buy anything in this case. +shared_ptr/weak_ptr/enable_shared_from_this cannot be literal types as they +have a non-trivial copy constructor. As they do not produce literal types, +then the constexpr default constructor will not guarantee constant +initialization, and so not buy the hoped for optimization.
- --template <class R, class... ArgTypes> - bool operator==(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); -template <class R, class... ArgTypes> - bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); -template <class R, class... ArgTypes> - bool operator!=(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); -template <class R, class... ArgTypes> - bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); --In 20.6.15.2.1 [func.wrap.func.con], replace +I recommend referring this back to Core to see if we can get static +initialization for types with constexpr constructors, even if they are not +literal types. Otherwise this should be closed as NAD.
++function(unspecified-null-pointer-typenullptr_t); -... -function& operator=(unspecified-null-pointer-typenullptr_t); -[ +2009-05-26 Daniel adds: +]
--In 20.6.15.2.6 [func.wrap.func.nullptr], replace -
-+template <class R, class... ArgTypes> - bool operator==(const function<R(ArgTypes...)>& f,unspecified-null-pointer-typenullptr_t); -template <class R, class... ArgTypes> - bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>& f); -+If Alisdair's 2009-05-01 comment is correct, wouldn't that also make +constexpr mutex() useless, because this class has a non-trivial +destructor? (828) ---and replace -
++template <class R, class... ArgTypes> - bool operator!=(const function<R(ArgTypes...)>& f,unspecified-null-pointer-typenullptr_t); -template <class R, class... ArgTypes> - bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>& f); -Proposed resolution:
++
-771. Impossible throws clause in [string.conversions]
-Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13
-View other active issues in [string.conversions].
-View all other issues in [string.conversions].
-View all issues with Ready status.
+828. Static initialization for std::mutex?
+Section: 30.4.1.1 [thread.mutex.class] Status: Review + Submitter: Peter Dimov Opened: 2008-04-18 Last modified: 2009-05-30
+View other active issues in [thread.mutex.class].
+View all other issues in [thread.mutex.class].
+View all issues with Review status.
Discussion:
-The new to_string and to_wstring functions described in 21.4 [string.conversions] -have throws clauses (paragraphs 8 and 16) which say: +[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
- --Throws: nothing ---Since all overloads return either a std::string or a std::wstring by value -this throws clause is impossible to realize in general, since the basic_string -constructors can fail due to out-of-memory conditions. Either these throws -clauses should be removed or should be more detailled like: +Currently std::mutex doesn't support static initialization. This is a +regression with respect to pthread_mutex_t, which does. I believe that +we should strive to eliminate such regressions in expressive power where +possible, both to ease migration and to not provide incentives to (or +force) people to forego the C++ primitives in favor of pthreads.
--Throws: Nothing if the string construction throws nothing -+[ +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. +
-Further there is an editorial issue in p. 14: All three to_wstring -overloads return a string, which should be wstring instead (The -header <string> synopsis of 21.2 [string.classes] is correct in this -regard). +If ubiquitous implementability cannot be assured, plan B is to introduce +another constructor, make this constexpr, which is +conditionally-supported. To avoid ambiguities, this new constructor needs +to have an additional parameter.
+[ +Post Summit: +]
-Proposed resolution:
+-In 21.4 [string.conversions], remove the paragraphs 8 and 16. +Jens: constant initialization seems to be ok core-language wise +
++Consensus: Defer to threading experts, in particular a Microsoft platform expert. +
++Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams, +Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker, +Peter Dimov to alert them of this issue. +
++Lawrence: What about header file shared with C? The initialization +syntax is different in C and C++. +
++Recommend Keep in Review
- --+string to_string(long long val); -string to_string(unsigned long long val); -string to_string(long double val); ---Throws: nothing-[ +Batavia (2009-05): +]
+-- - - +wstring to_wstring(long long val); -wstring to_wstring(unsigned long long val); -wstring to_wstring(long double val); ----Throws: nothing+Keep in Review status pending feedback from members of the Concurrency subgroup.[ +See related comments from Alisdiar and Daniel in 827. +]
-
-772. Impossible return clause in [string.conversions]
-Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13
-View other active issues in [string.conversions].
-View all other issues in [string.conversions].
-View all issues with Ready status.
-Discussion:
--The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring -overloads says: -
--Returns: each function returns a wstring object holding the character -representation of the value of its argument that would be generated by -calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld", -or L"%f", respectively. -+Proposed resolution:
-Problem is: There does not exist any wsprintf function in C99 (I checked -the 2nd edition of ISO 9899, and the first and the second corrigenda from -2001-09-01 and 2004-11-15). What probably meant here is the function -swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent -declaration: +Change 30.4.1.1 [thread.mutex.class]:
-int swprintf(wchar_t * restrict s, size_t n, -const wchar_t * restrict format, ...); +-class mutex { +public: + constexpr mutex(); + ...-therefore the paragraph needs to mention the size_t parameter n. -
-Proposed resolution:
+ +
+830. Incomplete list of char_traits specializations
+Section: 21.2 [char.traits] Status: Tentatively NAD Editorial + Submitter: Dietmar Kühl Opened: 2008-04-23 Last modified: 2009-05-23
+View all other issues in [char.traits].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
-Change the current wording of 21.4 [string.conversions]/p. 15 to: + Paragraph 4 of 21.2 [char.traits] mentions that this + section specifies two specializations (
+char_traits<char>
+ and (char_traits<wchar_t>
). However, there are actually + four specializations provided, i.e. in addition to the two above also +char_traits<char16_t>
andchar_traits<char32_t>
). + I guess this was just an oversight and there is nothing wrong with just + fixing this.[ +Alisdair adds: +]
+-Returns:-eEach function returns a -wstring object holding the character representation of the -value of its argument that would be generated by calling -wsswprintf(buf, bufsz, fmt, -val) with a format specifier fmt of L"%lld", -L"%ulld", or L"%f", respectively, where buf -designates an internal character buffer of sufficient size bufsz. +char_traits< char16/32_t > +should also be added to <ios_fwd> in 27.3 [iostream.forward], and all the specializations +taking a char_traits parameter in that header.-[Hint to the editor: The resolution also adds to mention the name of -the format specifier "fmt"] -
+[ +Sophia Antipolis: +]
+ +- - + +-I also would like to remark that the current wording of it's equivalent -paragraph 7 should also mention the meaning of buf and fmt. +Idea of the issue is ok.
--Change the current wording of 21.4 [string.conversions]/p. 7 to: +Alisdair to provide wording, once that wording arrives, move to review.
--Returns:+eEach function returns a string object holding the -character representation of the value of its argument that would be -generated by calling sprintf(buf, fmt, val) with a format specifier fmt of -"%lld", "%ulld", or "%f", respectively, where buf designates an internal -character buffer of sufficient size.[ +2009-05-04 Alisdair adds: +]
- - - -
-774. Member swap undefined for most containers
-Section: 23 [containers] Status: Open - Submitter: Alisdair Meredith Date: 2008-01-14
-View other active issues in [containers].
-View all other issues in [containers].
-View all issues with Open status.
-Discussion:
+--It appears most containers declare but do not define a member-swap -function. +The main point of the issue was resolved editorially in +N2723, +so we are +close to NAD Editorial. +However, exploring the issue we found a second tweak was necessary for +<iosfwd> and that is still outstanding, so here are the words I am long +overdue delivering:
--This is unfortunate, as all overload the swap algorithm to call the -member-swap function! -(required for swappable guarantees [Table 37] and Container Requirements -[Table 87]) -
+[ +Howard: I've put Alisdair's words into the proposed wording section and +moved the issue to Review. +]
--Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b), -yet for all containers we define swap(a,b) to call a.swap(b) - a circular -definition. -
--A quick survey of clause 23 shows that the following containers provide a -definition for member-swap: -
++array -queue -stack -vector -[ +Original proposed wording. +]
--Whereas the following declare it, but do not define the semantics: -
-+deque -list -map -multimap -multiset -priority_queue -set -unordered_map -unordered_multi_map -unordered_multi_set -unordered_set --Suggested resolution: + Replace paragraph 4 of 21.2 [char.traits] by:
-Provide a definition for each of the affected containers... ++ This subclause specifies a struct template,
+char_traits<charT>
, + and four explicit specializations of it,char_traits<char>
, +char_traits<char16_t>
,char_traits<char32_t>
, and +char_traits<wchar_t>
, all of which appear in the header + <string> and satisfy the requirements below. +[ -Bellevue: +Batavia (2009-05): ]
--Move to Open and ask Alisdair to provide wording. +We agree. Move to NAD Editorial.Proposed resolution:
-Wording provided in -N2590. +Change Forward declarations 27.3 [iostream.forward]: +
+ +++Header <iosfwd> synopsis
+namespace std { + template<class charT> class char_traits; + template<> class char_traits<char>; + template<> class char_traits<char16_t>; + template<> class char_traits<char32_t>; + template<> class char_traits<wchar_t>; +... +} ++
-776. Undescribed assign function of std::array
-Section: 23.2.1 [array] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-20
-View other active issues in [array].
-View all other issues in [array].
-View all issues with Ready status.
+833. Freestanding implementations header list needs review for C++0x
+Section: 17.6.1.3 [compliance] Status: Open + Submitter: Beman Dawes Opened: 2008-05-14 Last modified: 2009-03-11
+View other active issues in [compliance].
+View all other issues in [compliance].
+View all issues with Open status.
Discussion:
-The class template array synopsis in 23.2.1 [array]/3 declares a member -function +Once the C++0x standard library is feature complete, the LWG needs to +review 17.6.1.3 [compliance] Freestanding implementations header list to +ensure it reflects LWG consensus.
-+void assign(const T& u); -[ +San Francisco: +]
+ ++ +-which's semantic is no-where described. Since this signature is -not part of the container requirements, such a semantic cannot -be derived by those. +This is a placeholder defect to remind us to review the table once we've +stopped adding headers to the library.
--I found only one reference to this function in the issue list, -588 where the question is raised: +Three new headers that need to be added to the list:
- --what's the effect of calling assign(T&) on a zero-sized array? -- +<initializer_list> <concept> <iterator_concepts> +-which does not answer the basic question of this issue. +<iterator_concepts>, in particular, has lots of stuff +that isn't needed, so maybe the stuff that is needed should be broken +out into a separate header.
--If this function shall be part of the std::array, it's probable -semantic should correspond to that of boost::array, but of -course such wording must be added. +Robert: What about reference_closure? It's currently in +<functional>.
+[ +Post Summit Daniel adds: +]
+ + ++++
+- +The comment regarding reference_closure seems moot since it was just +recently decided to remove that. +
+- +A reference to proposal +N2814 +("Fixing freestanding") should be added. This +paper e.g. proposes to add only <initializer_list> to the include list +of freestanding. +
+Proposed resolution:
--Just after the section 23.2.1.4 [array.data] add the following new section: -
--23.2.1.5 array::fill [array.fill] -
--+ +void fill(const T& u); ---1: Effects: fill_n(begin(), N, u) -
-
+834. Unique_ptr::pointer requirements underspecified
+Section: 20.8.12.2 [unique.ptr.single] Status: Open + Submitter: Daniel Krügler Opened: 2008-05-14 Last modified: 2008-06-19
+View other active issues in [unique.ptr.single].
+View all other issues in [unique.ptr.single].
+View all issues with Open status.
+Discussion:
-[N.B: I wonder, why class array does not have a "modifiers" -section. If it had, then assign would naturally belong to it] +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).
--Change the synopsis in 23.2.1 [array]/3: +Unfortunately no requirements are specified for the type pointer which has +impact on at least two key features of unique_ptr:
-+template <class T, size_t N> -struct array { - ... - voidassignfill(const T& u); - ... -+
+- Operational fail-safety.
+- (Well-)Definedness of expressions.
++Unique_ptr specification makes great efforts to require that essentially *all* +operations cannot throw and therefore adds proper wording to the affected +operations of the deleter as well. If user-provided pointer-emulating types +("smart pointers") will be allowed, either *all* throw-nothing clauses have to +be replaced by weaker "An exception is thrown only if pointer's {op} throws +an exception"-clauses or it has to be said explicitly that all used +operations of +pointer are required *not* to throw. I understand the main focus of unique_ptr +to be as near as possible to the advantages of native pointers which cannot +fail and thus strongly favor the second choice. Also, the alternative position +would make it much harder to write safe and simple template code for +unique_ptr. Additionally, I assume that a general statement need to be given +that all of the expressions of pointer used to define semantics are required to +be well-formed and well-defined (also as back-end for 762). +
[ -Bellevue: +Sophia Antipolis: ]
- --Suggest substituting "fill" instead of "assign". +Howard: We maybe need a core concept PointerLike, but we don't need the +arithmetic (see shared_ptr vs. vector<T>::iterator.
-Set state to Review given substitution of "fill" for "assign". +Howard will go through and enumerate the individual requirements wrt. pointer for each member function.
-779. Resolution of #283 incomplete
-Section: 25.2.8 [alg.remove] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-25
-View all other issues in [alg.remove].
-View all issues with Ready status.
-Discussion:
--The resolution of 283 did not resolve similar necessary changes for algorithm -remove_copy[_if], -which seems to be an oversight. -
- -Proposed resolution:
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: +Add the following sentence just at the end of the newly proposed +20.8.12.2 [unique.ptr.single]/p. 3:
-Requires:-Type T is EqualityComparable (31).The ranges [first,last) -and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be -valid. +unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well +defined behavior, and shall not throw exceptions.
-780. std::merge() specification incorrect/insufficient
-Section: 25.3.4 [alg.merge] Status: New - Submitter: Daniel Krügler Date: 2008-01-25
-View all issues with New status.
+835. tying two streams together (correction to DR 581)
+Section: 27.5.4.2 [basic.ios.members] Status: Review + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-05-30
+View other active issues in [basic.ios.members].
+View all other issues in [basic.ios.members].
+View all issues with Review status.
Discussion:
--Though issue 283 has fixed many open issues, it seems that some are still open: -
+-
-Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 -have no Requires element and the Effects element contains some requirements, -which is probably editorial. Worse is that: -
+The fix for +issue 581, +now integrated into the working paper, overlooks a couple of minor +problems. --
+Second, as Bo Persson notes in his +comp.lang.c++.moderated post, +for streams with the- -no assignment requirements are specified (neither implicit nor explicit). -
+ +-
- -the effects clause just speaks of "merges", which is badly worded -near to a circular definition. -
+First, being an unformatted function once again,flush()
+is required to create a sentry object whose constructor must, among +other things, flush the tied stream. When two streams are tied +together, either directly or through another intermediate stream +object, flushing one will also cause a call toflush()
on +the other tied stream(s) and vice versa, ad infinitum. The program +below demonstrates the problem. -- -p. 2 mentions a range [first, last), which is not defined by the -function arguments or otherwise. -
+ +-
- -p. 2 says "according to the ordering defined by comp" which is both -incomplete (because -this excludes the first variant with <) and redundant (because the -following subordinate -clause mentions comp again) -
-unitbuf
flag set such +asstd::stderr
, the destructor of the sentry object will +again callflush()
. This seems to create an infinite +recursion forstd::cerr << std::flush;
+ + +++#include <iostream> +int main () +{ + std::cout.tie (&std::cerr); + std::cerr.tie (&std::cout); + std::cout << "cout\n"; + std::cerr << "cerr\n"; +} ++[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Review. ++ +[ +2009-05-26 Daniel adds: +]
-Proposed resolution:
--In 25.3.4 [alg.merge] replace p.1+ 2: -
+-Effects:
-MergesCopies all the elements of the two sorted ranges [first1,last1) and -[first2,last2) into the range -[result,result + (last1 - first1) + (last2 - first2))-[result, last) (where last is equal to result + (last1 -- first1) + (last2 - first2)), such that resulting range will be -sorted in non-decreasing order; that is, for every iterator i in -[result,last) other than result, the condition *i < *(i - 1) or, -respectively, comp(*i, *(i - 1)) will be false. +I think that the most recently suggested change in +27.7.2.4 [ostream::sentry] need some further word-smithing. As +written, it would make the behavior undefined, if under +conditions when pubsync() should be called, but when +in this scenario os.rdbuf() returns 0.-Requires: The resulting range shall not overlap with either of the original ranges.
+ +The list will be sorted in non-decreasing -order according to the ordering defined by comp; that is, for every iterator i in -[first,last) other than first, the condition *i < *(i - 1) or -comp(*i, *(i - 1)) will be false.The results of the expressions *first1 and *first2 -shall be writable to the output iterator. +This case is explicitly handled in flush() and needs to be +taken care of. My suggested fix is:+If ((os.flags() & ios_base::unitbuf) && !uncaught_exception() +&& os.rdbuf() != 0) is true, callsos.flush()+os.rdbuf()->pubsync().-[N.B.: I attempted to reuse the wording style of inplace_merge, -therefore proposing to -insert ", respectively," between both predicate tests. This is no -strictly necessary as -other parts of <algorithm> show, just a matter of consistency] +Two secondary questions are:
++
+- +Should pubsync() be invoked in any case or shouldn't a +base requirement for this trial be that os.good() == true +as required in the original flush() case? +
+- +Since uncaught_exception() is explicitly tested, shouldn't +a return value of -1 of pubsync() produce setstate(badbit) +(which may throw ios_base::failure)? +
+Proposed resolution:
++I think an easy way to plug the first hole is to add a requires clause +to
ostream::tie(ostream *tiestr)
requiring the this +pointer not be equal to any pointer on the list starting +withtiestr->tie()
+throughtiestr()->tie()->tie()
and so on. I am not +proposing that we require implementations to traverse this list, +although I think we could since the list is unlikely to be very long. -
-785. Random Number Requirements in TR1
-Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New - Submitter: John Maddock Date: 2008-01-15
-View all issues with New status.
-Discussion:
--Table 16 of TR1 requires that all Pseudo Random Number generators have a -
+ +-
+Add a Requires clause to 27.5.4.2 [basic.ios.members] withethe following +text: -seed(integer-type s) --member function that is equivalent to: -
+ +-++Requires: Ifmygen = Generator(s) -(tiestr != 0)
is +true,tiestr
must not be reachable by traversing the +linked list of tied stream objects starting +fromtiestr->tie()
. --But the generators xor_combine and discard_block have no such seed member, only the -
+-
+In addition, to prevent the infinite recursion that Bo writes about in +his comp.lang.c++.moderated post, I propose to change +27.7.2.4 [ostream::sentry], p2 like so: -template <class Gen> -seed(Gen&); --member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. -
+ +-+ --So... is this a bug in TR1? -
+If((os.flags() & ios_base::unitbuf) && +!uncaught_exception())
is true, +callsos.flush()os.rdbuf()->pubsync()
. -This is a real issue BTW, since the Boost implementation does adhere -to the requirements of Table 16, while at least one commercial -implementation does not and follows a strict adherence to sections -5.1.4.5 and 5.1.4.6 instead. -
+[ -Jens adds: -]
--Both engines do have the necessary -constructor, therefore the omission of the seed() member -functions appears to be an oversight. -+
+836. + effects of
+money_base::space
and +money_base::none
onmoney_get
+Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Open + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2008-09-22
+View other active issues in [locale.money.get.virtuals].
+View all other issues in [locale.money.get.virtuals].
+View all issues with Open status.
+Duplicate of: 670
+Discussion:
++In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following: -
Proposed resolution:
--
+ ++Where+space
ornone
appears in the format +pattern, except at the end, optional white space (as recognized +byct.is
) is consumed after any required space. ++This requirement can be (and has been) interpreted two mutually +exclusive ways by different readers. One possible interpretation +is that: +
++++
+- -
+
-787. complexity of binary_search
-Section: 25.3.3.4 [binary.search] Status: Ready - Submitter: Daniel Krügler Date: 2007-09-08
-View all issues with Ready status.
-Discussion:
--In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as -
+wheremoney_base::space
appears in the format, at least +one space is required, and --At most log(last - first) + 2 comparisons. -+- -
+-This should be precised and brought in line with the nomenclature used for -lower_bound, upper_bound, and equal_range. -
+wheremoney_base::none
appears in the format, space is +allowed but not required. --All existing libraries I'm aware of, delegate to -lower_bound (+ one further comparison). Since -issue 384 -has now WP status, the resolution of #787 should -be brought in-line with 384 by changing the + 2 -to + O(1). -
++ +The other is that: + +
++ +where eithermoney_base::space
ormoney_base::none
appears in the format, white space is optional. + +[ -Sophia Antipolis: +San Francisco: ]
-Alisdair prefers to apply an upper bound instead of O(1), but that would -require fixing for lower_bound, upper_bound etc. as well. If he really -cares about it, he'll send an issue to Howard. +Martin will revise the proposed resolution.+ +Proposed resolution:
++I propose to change the text to make it clear that the first +interpretation is intended, that is, to make following change to +22.4.6.1.2 [locale.money.get.virtuals], p2: -
Proposed resolution:
--Change 25.3.3.4 [binary.search]/3 -
+ --Complexity: At most log2(last - first) ++2O(1) comparisons. -+When+money_base::space
+ormoney_base::none
appears as the last +element in the format pattern,except at the end, optional +white space (as recognized byno white space is consumed. Otherwise, +wherect.is
) is consumed after +any required space.money_base::space
appears in any of the initial +elements of the format pattern, at least one white space character is +required. Wheremoney_base::none
appears in any of the +initial elements of the format pattern, white space is allowed but not +required. In either case, any required followed by all optional white +space (as recognized byct.is()
) is consumed. +If(str.flags() & str.showbase)
isfalse
, ... +
-788. ambiguity in [istream.iterator]
-Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-02-06
-View other active issues in [istream.iterator].
-View all other issues in [istream.iterator].
-View all issues with New status.
+837. +
+basic_ios::copyfmt()
overly loosely specified +Section: 27.5.4.2 [basic.ios.members] Status: Tentatively NAD Editorial + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-05-23
+View other active issues in [basic.ios.members].
+View all other issues in [basic.ios.members].
+View all issues with Tentatively NAD Editorial status.
Discussion:
--The description of how an istream_iterator object becomes an -end-of-stream iterator is a) ambiguous and b) out of date WRT -issue 468: -
- --istream_iterator reads (using operator>>) successive elements from the -input stream for which it was constructed. After it is constructed, and -every time ++ is used, the iterator reads and stores a value of T. If -the end of stream is reached (operator void*() on the stream returns -false), the iterator becomes equal to the end-of-stream iterator value. -The constructor with no arguments istream_iterator() always constructs -an end of stream input iterator object, which is the only legitimate -iterator to be used for the end condition. The result of operator* on an -end of stream is not defined. For any other iterator value a const T& is -returned. The result of operator-> on an end of stream is not defined. -For any other iterator value a const T* is returned. It is impossible to -store things into istream iterators. The main peculiarity of the istream -iterators is the fact that ++ operators are not equality preserving, -that is, i == j does not guarantee at all that ++i == ++j. Every time ++ -is used a new value is read. -- --istream::operator void*() returns null if istream::fail() is true, -otherwise non-null. istream::fail() returns true if failbit or -badbit is set in rdstate(). Reaching the end of stream doesn't -necessarily imply that failbit or badbit is set (e.g., after -extracting an int from stringstream("123") the stream object will -have reached the end of stream but fail() is false and operator -void*() will return a non-null value). -
- --Also I would prefer to be explicit about calling fail() here -(there is no operator void*() anymore.) -
- - -Proposed resolution:
--Change 24.5.1 [istream.iterator]/1: -
- --istream_iterator reads (using operator>>) successive elements from the -input stream for which it was constructed. After it is constructed, and -every time ++ is used, the iterator reads and stores a value of T. If -- +the end of stream is reachedthe iterator fails to read and store a value of T -(operator void*()fail() on the stream returns -falsetrue), the iterator becomes equal to the end-of-stream iterator value. -The constructor with no arguments istream_iterator() always constructs -an end of stream input iterator object, which is the only legitimate -iterator to be used for the end condition. The result of operator* on an -end of stream is not defined. For any other iterator value a const T& is -returned. The result of operator-> on an end of stream is not defined. -For any other iterator value a const T* is returned. It is impossible to -store things into istream iterators. The main peculiarity of the istream -iterators is the fact that ++ operators are not equality preserving, -that is, i == j does not guarantee at all that ++i == ++j. Every time ++ -is used a new value is read. -+The
+basic_ios::copyfmt()
member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects: ++Effects: If+(this == &rhs)
does +nothing. Otherwise assigns to the member objects of*this
+the corresponding member objects ofrhs
, except that -
-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:
--discrete_distribution should have a constructor like: -
++
+- -
++template<class _Fn> - discrete_distribution(result_type _Count, double _Low, double _High, - _Fn& _Func); -rdstate()
andrdbuf()
are left unchanged; --(Makes it easier to fill a histogram with function values over a range.) -
+- -
+[ -Bellevue: -]
+exceptions()
is altered last by +callingexceptions(rhs.except)
+- -
+-How do you specify the function so that it does not return negative -values? If you do it is a bad construction. This requirement is already -there. Where in each bin does one evaluate the function? In the middle. -Need to revisit tomorrow. -+the contents of arrays pointed at bypword
+andiword
are copied not the pointers themselves -[ -Sophia Antipolis: -]
++Since the rest of the text doesn't specify what the member objects +of
basic_ios
are this seems a little too loose. ---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: +Batavia (2009-05): ]
--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. +We agree with the proposed resolution. +Move to NAD Editorial.-Proposed resolution:
--
- -
- --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); -- -
-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: -
--
+- -fw shall be callable with one argument of type double, and shall -return values of a type convertible to double;
-- 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;
+I propose to tighten things up by adding a Postcondition clause +to the function like so: -- The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
+ ++ Postconditions: -+ +
++ ++ copyfmt()
postconditions+ + + +Element +Value ++ ++ rdbuf()
unchanged ++ ++ tie()
+ rhs.tie()
+ ++ rdstate()
unchanged ++ ++ exceptions()
+ rhs.exceptions()
+ ++ flags()
+ rhs.flags()
+ ++ width()
+ rhs.width()
+ ++ precision()
+ rhs.precision()
+ ++ fill()
+ rhs.fill()
+ + ++ getloc()
+ rhs.getloc()
-
-Effects: -
--
-- If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and - consist of the single value w0 = 1.
+The format of the table follows Table 117 (as +of N2588):basic_ios::init()
+effects. -- -
-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) -- -
-Constructs a discrete_distribution object with probabilities:
--pk = wk/S for k = 0, . . . , n-1. -+The intent of the new table is not to impose any new requirements or +change existing ones, just to be more explicit about what I believe is +already there. +
+
-794. piecewise_constant_distribution missing constructor
-Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09
-View other active issues in [rand.dist.samp.pconst].
-View all other issues in [rand.dist.samp.pconst].
+838. + can an end-of-stream iterator become a non-end-of-stream one? +
+Section: 24.6.1 [istream.iterator] Status: Open + Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2008-10-27
+View other active issues in [istream.iterator].
+View all other issues in [istream.iterator].
View all issues with Open status.
Discussion:
--piecewise_constant_distribution should have a constructor like: -
+-
+From message c++std-lib-20003... -template<class _Fn> - piecewise_constant_distribution(size_t _Count, - _Ty _Low, _Ty _High, _Fn& _Func); --(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: -]
+The description ofistream_iterator
in +24.6.1 [istream.iterator], p1 specifies that objects of the +class become the end-of-stream (EOS) iterators under the +following condition (see also issue 788 another problem +with this paragraph): + +-+-+If the end of stream is reached (-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. -
-operator void*()
on the +stream returnsfalse
), the iterator becomes equal to +the end-of-stream iterator value. -[ -Pre San Francisco, Daniel provided wording. -]
++One possible implementation approach that has been used in practice is +for the iterator to set its
in_stream
pointer to 0 when +it reaches the end of the stream, just like the default ctor does on +initialization. The problem with this approach is that +the Effects clause foroperator++()
says the +iterator unconditionally extracts the next value from the stream by +evaluating*in_stream >> value
, without checking +for(in_stream == 0)
. --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. -+ ++Conformance to the requirement outlined in the Effects clause +can easily be verified in programs by setting
+eofbit
+orfailbit
inexceptions()
of the associated +stream and attempting to iterate past the end of the stream: each +past-the-end access should trigger an exception. This suggests that +some other, more elaborate technique might be intended. +-
Proposed resolution:
+Another approach, one that allowsoperator++()
to attempt +to extract the value even for EOS iterators (just as long +asin_stream
is non-0) is for the iterator to maintain a +flag indicating whether it has reached the end of the stream. This +technique would satisfy the presumed requirement implied by +the Effects clause mentioned above, but it isn't supported by +the exposition-only members of the class (no such flag is shown). This +approach is also found in existing practice. --
- +- -
+The inconsistency between existing implementations raises the question +of whether the intent of the specification is that a non-EOS iterator +that has reached the EOS become a non-EOS one again after the +stream's-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(size_t nf, RealType xmin, RealType xmax, Func fw); -eofbit
flag has been cleared? That is, are the +assertions in the program below expected to pass? + + +++sstream strm ("1 "); + istream_iterator eos; + istream_iterator it (strm); + int i; + i = *it++ + assert (it == eos); + strm.clear (); + strm << "2 3 "; + assert (it != eos); + i = *++it; + assert (3 == i); +++ +Or is it intended that once an iterator becomes EOS it stays EOS until +the end of its lifetime? + +
+ +[ +San Francisco: +]
-- -
--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<typename Func> -piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw); --[p5_1] Complexity: Exactly nf invocations of fw. -
--[p5_2] Requires: -
--
-- fw shall be callable with one argument of type RealType, and shall -return values of a type convertible to double; -
-- -For all sample values xk defined below, fw(xk) shall return a weight -value wk that is non-negative, non-NaN, and non-infinity; -
-- -The following relations shall hold: xmin < xmax, and -0 < S = w0+. . .+wn-1. -
--[p5_3] Effects: +We like the direction of the proposed resolution. We're not sure about +the wording, and we need more time to reflect on it,
--
-- -
-If nf == 0,
--
-- -sets deltax = xmax - xmin, and
-- lets the sequence w have length n = 1 and consist of the single - value w0 = 1, and
-- lets the sequence b have length n+1 with b0 = xmin and - b1 = xmax -
-- -
-Otherwise,
--
-- sets n = nf, deltax = (xmax - xmin)/n, - xcent = xmin + 0.5 * deltax, and -
-- -
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
-- sets bn = xmax
-- -
-Constructs a piecewise_constant_distribution object with -the above computed sequence b as the interval boundaries -and with the probability densities: +Move to Open. Detlef to rewrite the proposed resolution in such a way +that no reference is made to exposition only members of +istream_iterator.
--ρk = wk/(S * deltax) for k = 0, . . . , n-1. --[p5_4] Remarks: In this context, the subintervals [bk, bk+1) are commonly - known as the bins of a histogram. -
-Proposed resolution:
++The discussion of this issue on the reflector suggests that the intent +of the standard is for an
+istreambuf_iterator
that has +reached the EOS to remain in the EOS state until the end of its +lifetime. Implementations that permit EOS iterators to return to a +non-EOS state may only do so as an extension, and only as a result of +callingistream_iterator
member functions on EOS +iterators whose behavior is in this case undefined. +-
-800. Issues in 26.4.7.1 [rand.util.seedseq](6)
-Section: 26.4.7.1 [rand.util.seedseq] Status: Open - Submitter: Stephan Tolksdorf Date: 2008-02-18
-View other active issues in [rand.util.seedseq].
-View all other issues in [rand.util.seedseq].
-View all issues with Open status.
-Discussion:
--The for-loop in the algorithm specification has n iterations, where n is -defined to be end - begin, i.e. the number of supplied w-bit quantities. -Previous versions of this algorithm and the general logic behind it -suggest that this is an oversight and that in the context of the -for-loop n should be the number of full 32-bit quantities in b (rounded -upwards). If w is 64, the current algorithm throws away half of all bits -in b. If w is 16, the current algorithm sets half of all elements in v -to 0. -
+To this end we propose to change 24.6.1 [istream.iterator], p1, +as follows: --There are two more minor issues: -
+ +-+-
+The result of operator-> on an end-of-stream +is not defined. For any other iterator value a- -Strictly speaking end - begin is not defined since -InputIterator is not required to be a random access iterator. -
-- -Currently all integral types are allowed as input to the seed_seq -constructor, including bool. IMHO allowing bools unnecessarily -complicates the implementation without any real benefit to the user. -I'd suggest to exclude bools as input. -
-const T*
+is returned. Invokingoperator++()
on +an end-of-stream iterator is undefined. It is impossible +to store things into istream iterators... -[ -Bellevue: -]
++Add pre/postconditions to the member function descriptions of
istream_iterator
like so: --Move to OPEN Bill will try to propose a resolution by the next meeting. -+ +-+[ -post Bellevue: Bill provided wording. -]
+istream_iterator();+Effects: Constructs the end-of-stream iterator.
+Postcondition:in_stream == 0
. --This issue is made moot if 803 is accepted. -
+istream_iterator(istream_type &s);+Effects: Initializesin_stream
with &s. value +may be initialized during construction or the first time it is +referenced.
+Postcondition:in_stream == &s
. +istream_iterator(const istream_iterator &x);-Proposed resolution:
--Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: -
+Effects: Constructs a copy ofx
.
+Postcondition:in_stream == x.in_stream
. --+Requires:-Effects: Constructs a seed_seq object by effectively concatenating the -low-order u bits of each of the elements of the supplied sequence [begin, -end) -in ascending order of significance to make a (possibly very large) unsigned -binary number b having a total of n bits, and then carrying out the -following -algorithm: -
+istream_iterator& operator++();--for( v.clear(); n > 0; n -= 32 ) - v.push_back(b mod 232), b /= 232; -in_stream != 0
.
+Effects:*in_stream >> value
. +istream_iterator& operator++(int);+Requires:in_stream != 0
.
+Effects: ++istream_iterator tmp (*this); +*in_stream >> value; +return tmp; ++
-801. tuple and pair trivial members
-Section: 20.4 [tuple] Status: Open - Submitter: Lawrence Crowl Date: 2008-02-18
-View other active issues in [tuple].
-View all other issues in [tuple].
+839. Maps and sets missing splice operation
+Section: 23.4 [associative], 23.5 [unord] Status: Open + Submitter: Alan Talbot Opened: 2008-05-18 Last modified: 2008-09-22
+View other active issues in [associative].
+View all other issues in [associative].
View all issues with Open status.
Discussion:
-Classes with trivial special member functions are inherently more -efficient than classes without such functions. This efficiency is -particularly pronounced on modern ABIs that can pass small classes -in registers. Examples include value classes such as complex numbers -and floating-point intervals. Perhaps more important, though, are -classes that are simple collections, like pair and tuple. When the -parameter types of these classes are trivial, the pairs and tuples -themselves can be trivial, leading to substantial performance wins. -
--The current working draft make specification of trivial functions -(where possible) much easer through defaulted and deleted functions. -As long as the semantics of defaulted and deleted functions match -the intended semantics, specification of defaulted and deleted -functions will yield more efficient programs. -
--There are at least two cases where specification of an explicitly -defaulted function may be desirable. -
--First, the std::pair template has a non-trivial default constructor, -which prevents static initialization of the pair even when the -types are statically initializable. Changing the definition to +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.
--pair() = default; --would enable such initialization. Unfortunately, the change is -not semantically neutral in that the current definition effectively -forces value initialization whereas the change would not value -initialize in some contexts. +Suggested resolution:
-** Does the committee confirm that forced value initialization -was the intent? If not, does the committee wish to change the -behavior of std::pair in C++0x? -
--Second, the same default constructor issue applies to std::tuple. -Furthermore, the tuple copy constructor is current non-trivial, -which effectively prevents passing it in registers. To enable -passing tuples in registers, the copy constructor should be -make explicitly defaulted. The new declarations are: +Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
- -+tuple() = default; -tuple(const tuple&) = default; ++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);-This changes is not implementation neutral. In particular, it -prevents implementations based on pointers to the parameter -types. It does however, permit implementations using the -parameter types as bases. -
--** How does the committee wish to trade implementation -efficiency versus implementation flexibility? +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); +[ -Bellevue: +Sophia Antipolis: ]
- - --General agreement; the first half of the issue is NAD. +Don't try to splice "list" into the other containers, it should be container-type.
-Before voting on the second half, it was agreed that a "Strongly Favor" -vote meant support for trivial tuples (assuming usual requirements met), -even at the expense of other desired qualities. A "Weakly Favor" vote -meant support only if not at the expense of other desired qualities. +forward_list already has splice_after.
-Concensus: Go forward, but not at expense of other desired qualities. +Would "splice" make sense for an unordered_map?
-It was agreed to Alisdair should fold this work in with his other -pair/tuple action items, above, and that issue 801 should be "open", but -tabled until Alisdair's proposals are disposed of. +Jens, Robert: "splice" is not the right term, it implies maintaining ordering in lists.
-Proposed resolution:
+Howard: adopt?
- - - - - -
-803. Simplification of seed_seq::seq_seq
-Section: 26.4.7.1 [rand.util.seedseq] Status: Review - Submitter: Charles Karney Date: 2008-02-22
-View other active issues in [rand.util.seedseq].
-View all other issues in [rand.util.seedseq].
-View all issues with Review status.
-Discussion:
-seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq -object repacking the bits of supplied sequence [begin, end) into a -32-bit vector. +Jens: absorb?
-This repacking triggers several problems: +Alan: subsume?
--
- -Distinctness of the output of seed_seq::generate required the -introduction of the initial "if (w < 32) v.push_back(n);" (Otherwise -the unsigned short vectors [1, 0] and [1] generate the same sequence.) -
-- -Portability demanded the introduction of the template parameter u. -(Otherwise some sequences could not be obtained on computers where no -integer types are exactly 32-bits wide.) -
-- -The description and algorithm have become unduly complicated. -
--I propose simplifying this seed_seq constructor to be "32-bit only". -Despite it's being simpler, there is NO loss of functionality (see -below). +Robert: recycle?
-Here's how the description would read +Howard: transfer? (but no direction)
-+-26.4.7.1 [rand.util.seedseq] Class seed_seq +Jens: transfer_from. No.
- --template<class InputIterator> - seed_seq(InputIterator begin, InputIterator end); ----5 Requires: NO CHANGE +Alisdair: Can we give a nothrow guarantee? If your compare() and hash() doesn't throw, yes.
-6 Effects: Constructs a seed_seq object by +Daniel: For unordered_map, we can't guarantee nothrow.
---for (InputIterator s = begin; s != end; ++s) - v.push_back((*s) mod 2^32); --[ +San Francisco: +]
+ + ++ + + +-Discussion: -
--The chief virtues here are simplicity, portability, and generality. -
--
-- -Simplicity -- compare the above specification with the -n2461 proposal. -
-- -Portability -- with iterator_traits<InputIterator>::value_type = -uint_least32_t the user is guaranteed to get the same behavior across -platforms. -
-- -Generality -- any behavior that the -n2461 -proposal can achieve can be -obtained with this simpler proposal (albeit with a shuffling of bits -in the input sequence). -
--Arguments (and counter-arguments) against making this change (and -retaining the -n2461 -behavior) are: -
--
- -
-The user can pass an array of unsigned char and seed_seq will nicely - repack it. +Martin: this would possibly outlaw an implementation technique that is +currently in use; caching nodes in containers.
- Response: So what? Consider the seed string "ABC". The - n2461 - proposal results in +Alan: if you cache in the allocator, rather than the individual +container, this proposal doesn't interfere with that.
-v = { 0x3, 0x434241 }; --while the simplified proposal yields +Martin: I'm not opposed to this, but I'd like to see an implementation +that demonstrates that it works.
-+v = { 0x41, 0x42, 0x43 }; -Proposed resolution:
+ + + + + +
+847. string exception safety guarantees
+Section: 21.4.1 [string.require] Status: Open + Submitter: Hervé Brönnimann Opened: 2008-06-05 Last modified: 2009-02-14
+View other active issues in [string.require].
+View all other issues in [string.require].
+View all issues with Open status.
+Discussion:
-The results produced by seed_seq::generate with the two inputs are -different but nevertheless equivalently "mixed up" and this remains -true even if the seed string is long. +In 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.4 [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). ++-With long strings (e.g., with bit-length comparable to the number of - bits in the state), v is longer (by a factor of 4) with the simplified - proposal and seed_seq::generate will be slower. +However, the chapter 23 only says, on the topic of exceptions: 23.2 [container.requirements], +para 10:
+ +-Response: It's unlikely that the efficiency of seed_seq::generate will - be a big issue. If it is, the user is free to repack the seed vector - before constructing seed_seq. +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...
+-A user can pass an array of 64-bit integers and all the bits will be - used. +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.2 [container.requirements], para 3.
+- Response: Indeed. However, there are many instances in the - n2461 - where integers are silently coerced to a narrower width and this - should just be a case of the user needing to read the documentation. - The user can of course get equivalent behavior by repacking his seed - into 32-bit pieces. Furthermore, the unportability of the - n2461 - proposal with +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.
-+unsigned long s[] = {1, 2, 3, 4}; -seed_seq q(s, s+4); -- which typically results in v = {1, 2, 3, 4} on 32-bit machines and in -v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for - unsuspecting users. +The reaction in that group by Niels Dekker, Martin Sebor, and +Bo Persson, was all that this would be worth an LWG issue.
- --Note: this proposal renders moot issues 782 and 800. +A related issue is that erase() does not throw. This should be +stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1 +applies here).
[ -Bellevue: +San Francisco: ]
-Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. +Implementors will study this to confirm that it is actually possible.[ -Sophia Antipolis: +Daniel adds 2009-02-14: ]
--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. -
- +The proposed resolution of paper +N2815 +interacts with this issue (the paper does not refer to this issue).Proposed resolution:
-Change 26.4.7.1 [rand.util.seedseq]: +Add a blanket statement in 21.4.1 [string.require]:
--template<class InputIterator-, - size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> - seed_seq(InputIterator begin, InputIterator end); -+--5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1) -such that iterator_traits<InputIterator>::value_type shall denote an integral type. +- if any member function or operator of basic_string<charT, traits, Allocator> +throws, that function or operator has no effect.
--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:+- no erase() or pop_back() function throws.-
-First extract the rightmost u bits from each of the n = end -- begin elements of the supplied sequence and concatenate all the -extracted bits to initialize a single (possibly very large) unsigned -binary number, b = ∑n-1i=0 (begin[i] -mod 2u) · 2w·i (in which the bits of each begin[i] -are treated as denoting an unsigned quantity). Then carry out -the following algorithm:+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.--v.clear(); -if ($w$ < 32) - v.push_back($n$); -for( ; $n$ > 0; --$n$) - v.push_back(b mod 232), b /= 232; ----for (InputIterator s = begin; s != end; ++s) - v.push_back((*s) mod 232); --
-804. Some problems with classes error_code/error_condition
-Section: 19.4 [syserr] Status: Review - Submitter: Daniel Krügler Date: 2008-02-24
-View other active issues in [syserr].
-View all other issues in [syserr].
-View all issues with Review status.
+851. simplified array construction
+Section: 23.3.1 [array] Status: Open + Submitter: Benjamin Kosnik Opened: 2008-06-05 Last modified: 2009-06-10
+View other active issues in [array].
+View all other issues in [array].
+View all issues with Open status.
Discussion:
--
+- -
-19.4.2.1 [syserr.errcode.overview]/1, class error_code and -19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses -declare an expository data member cat_: +This is an issue that came up on the libstdc++ list, where a +discrepancy between "C" arrays and C++0x's std::array was pointed +out. +
+ ++In "C," this array usage is possible:
-const error_category& cat_; // exposition only + ++int ar[] = {1, 4, 6};-which is used to define the semantics of several members. The decision -to use a member of reference type lead to several problems: +But for C++,
--
+ +- -The classes are not (Copy)Assignable, which is probably not the intent. -
-- -The post conditions of all modifiers from -19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., -cannot be fulfilled. -
-+std::array<int> a = { 1, 4, 6 }; // error +-The simple fix would be to replace the reference by a pointer member. +Instead, the second parameter of the array template must be +explicit, like so:
-- -I would like to give the editorial remark that in both classes the -constrained operator= -overload (template with ErrorCodeEnum argument) makes in invalid -usage of std::enable_if: By using the default value for the second enable_if -parameter the return type would be defined to be void& even in otherwise -valid circumstances - this return type must be explicitly provided (In -error_condition the first declaration uses an explicit value, but of wrong -type). -
+-std::array<int, 3> a = { 1, 4, 6 }; +- -The member function message throws clauses ( -19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and -19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", -although -they return a std::string by value, which might throw in out-of-memory -conditions (see related issue 771). -
-+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); +[ -Sophia Antipolis: +San Francisco: ]
+-Part A: NAD (editorial), cleared by the resolution of issue 832. +Benjamin: Move to Ready? +
++Bjarne: I'm not convinced this is useful enough to add, so I'd like us +to have time to reflect on it.
-Part B: Technically correct, save for typo. Rendered moot by the concept proposal -(N2620) NAD (editorial). +Alisdair: the constraints are wrong, they should be
+template<ValueType T, ValueType... Args> +requires Convertible<Args, T>... +array<T, sizeof...(Args)> make_array(Args&&... args); +-Part C: We agree; this is consistent with the resolution of issue 721. +Alidair: this would be useful if we had a constexpr version.
-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. +Bjarne: this is probably useful for arrays with a small number of +elements, but it's not clearly useful otherwise.
-Beman provided updated wording. Since issue 832 is not going -forward, the provided wording includes resolution of part A. +Consensus is to move to Open.
[ +2009-06-07 Daniel adds: +]
-Proposed resolution:
- ++-Resolution of part A: +I suggest a fix and a simplification of the current proposal: Recent +prototyping by +Howard showed, that a fix is required because narrowing conversion +8.5.4 [dcl.init.list]/6 b.3 +would severely limit the possible distribution of argument types, e.g. +the expression +make_array<double>(1, 2.0) is ill-formed, because the narrowing +happens inside the +function body where no constant expressions exist anymore. Furthermore +given e.g.
-+-int f(); +double g(); +-Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: +we probably want to support
- --private: - int val_; // exposition only - const error_category&* cat_; // exposition only +make_array<double>(f(), g());-Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: +as well. To make this feasible, the currently suggested expansion
---error_code(); --+-+{ std::forward<Args>(args)... } +-Effects: Constructs an object of type error_code. +needs to be replaced by
+ ++{ static_cast<T>(std::forward<Args>(args))... } +-Postconditions: val_ == 0 and cat_ == &system_category. +which is safe, because we already ensure convertibility via the +element-wise Convertible<Args, T> requirement. Some other fixes are +necessary: The ValueType requirement for the function parameters +is invalid, because all lvalue arguments will deduce to an lvalue-reference, +thereby no longer satisfying this requirement.
+-Throws: Nothing. +The suggested simplification is to provide a default-computed effective +type for the result array based on common_type and decay, in +unconstrained form:
-error_code(int val, const error_category& cat); --+ +-+template<typename... Args> +array<typename decay<typename common_type<Args...>::type>::type, +sizeof...(Args)> +make_array(Args&&... args); +-Effects: Constructs an object of type error_code. -
+The approach used below is similar to that of make_pair and make_tuple +using a symbol C to represent the decayed common type [Note: Special +handling of reference_wrapper types is intentionally not provided, because +our target has so satisfy ValueType, thus under the revised proposal only +an all-reference_wrapper-arguments would be well-formed and an array of +reference_wrapper will be constructed]. I do currently not suggest to +add new concepts reflecting decay and common_type, but an implementor will +need something like this to succeed. Note that we use a similar fuzziness for +make_pair and make_tuple currently. This fuzziness is not related to +the currently +missing Constructible<Vi, Ti&&> requirement for those functions. The following +proposal fixes that miss for make_array. If the corresponding C type +deduction is +explicitly wanted for standardization, here the implementation + + ++auto concept DC<typename... T> { + typename type = typename decay<typename common_type<T...>::type>::type; +} +-Postconditions: val_ == val and cat_ == &cat. +where C is identical to DC<Args...>::type in the proposed resolution below.
-Throws: Nothing. +I intentionally added no further type relation between type and the concept +template parameters, but instead added this requirement below to make +the specification as transparent as possible. As written this concept is +satisfied, if the corresponding associated type exists.
--Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: -
+Suggested Resolution:
---void assign(int val, const error_category& cat); --++ + + ++
+ +- + +
-Postconditions: val_ == val and cat_ == &cat. +Add to the array synopsis in 23.3 [sequences]:
+++template<ReferentType... Args> +requires ValueType<C> && Constructible<C, Args&&>... +array<C, sizeof...(Args)> +make_array(Args&&... args); + +- + +
-Throws: Nothing. +Append after 23.3.1.7 [array.tuple] Tuple interface to class template array +the following new section: +
++++23.4.1.7 Array creation functions [array.creation]
+ ++template<ReferentType... Args> +requires ValueType<C> && Constructible<C, Args&&>... +array<C, sizeof...(Args)> +make_array(Args&&... args); ++ +++Let C be decay<common_type<Args...>::type>::type. +
++Returns: an array<C, sizeof...(Args)> initialized with +{ static_cast<C>(std::forward<Args>(args))... }. +
Proposed resolution:
-Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: +Add to the array synopsis in 23.3 [sequences]: +
+ ++ +template<ValueType T, ValueType... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); ++Append after 23.3.1.7 [array.tuple] Tuple interface to class template array the +following new section.
--const error_category& category() const;---Returns: *cat_. +23.2.1.7 Convenience interface to class template array [array.tuple]
+ +template<ValueType T, ValueType... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); ++ +-Throws: Nothing. +Returns: an array<T, sizeof...(Args)> initialized with {std::forward<T>(args)...}.
-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 -
+853. to_string needs updating with zero and one
+Section: 20.3.6 [template.bitset] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2008-06-18 Last modified: 2009-05-10
+View other active issues in [template.bitset].
+View all other issues in [template.bitset].
+View all issues with Tentatively Ready status.
+Discussion:
-Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: +Issue 396 adds defaulted arguments to the to_string member, but neglects to update +the three newer to_string overloads.
+[ -(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.) +post San Francisco: ]
-+ +error_condition(); -+Daniel found problems with the wording and provided fixes. Moved from Ready +to Review. +[ +Post Summit: +]
+ +--Effects: Constructs an object of type error_condition. +Alisdair: suggest to not repeat the default arguments in B, C, D +(definition of to_string members)
-Postconditions: val_ == 0 and cat_ == &posix_category. +Walter: This is not really a definition.
-Throws: Nothing. +Consensus: Add note to the editor: Please apply editor's judgement +whether default arguments should be repeated for B, C, D changes.
-error_condition(int val, const error_category& cat); --+ +-Effects: Constructs an object of type error_condition. +Recommend Tentatively Ready.
--Postconditions: val_ == val and cat_ == &cat. +
[ +2009-05-09: See alternative solution in issue 1113. +]
+ + + + +Proposed resolution:
++
+ + + + + + +- +
+replace in 20.3.6 [template.bitset]/1 (class bitset)
++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; +- +
-Throws: Nothing. +replace in 20.3.6.2 [bitset.members]/37
+- +template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > + to_string(charT zero = charT('0'), charT one = charT('1')) const; +++37 Returns: to_string<charT, traits, allocator<charT> >(zero, one).- +
-Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: +replace in 20.3.6.2 [bitset.members]/38
+template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > + to_string(charT zero = charT('0'), charT one = charT('1')) const; +-void assign(int val, const error_category& cat); -+--Postconditions: val_ == val and cat_ == &cat. -
--Throws: Nothing. -
+38 Returns: to_string<charT, char_traits<charT>, allocator<charT> >(zero, one).- + +
-Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +replace in 20.3.6.2 [bitset.members]/39
+basic_string<char, char_traits<char>, allocator<char> > + to_string(char zero = '0', char one = '1') const; +-const error_category& category() const; -++39 Returns: to_string<char, char_traits<char>, allocator<char> >(zero, one). ++
+854. default_delete converting constructor underspecified
+Section: 20.8.12.1.1 [unique.ptr.dltr.dflt] Status: Review + Submitter: Howard Hinnant Opened: 2008-06-18 Last modified: 2009-05-23
+View all issues with Review status.
+Discussion:
-Returns: *cat_. +No relationship between U and T in the converting constructor for default_delete template.
-Throws: Nothing. +Requirements: U* is convertible to T* and has_virtual_destructor<T>; +the latter should also become a concept.
--Resolution of part C: +Rules out cross-casting.
- --+ +-In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. +The requirements for unique_ptr conversions should be the same as those on the deleter.
---virtual string message(int ev) const = 0; -+[ +Howard adds 2008-11-26: +]
++-Returns: A string that describes the error condition denoted by ev. +I believe we need to be careful to not outlaw the following use case, and +I believe the current proposed wording +(requires Convertible<U*, T*> && HasVirtualDestructor<T>) does so:
+ ++#include <memory> + +int main() +{ + std::unique_ptr<int> p1(new int(1)); + std::unique_ptr<const int> p2(move(p1)); + int i = *p2; +// *p2 = i; // should not compile +} +-
-Throws: Nothing.+I've removed "&& HasVirtualDestructor<T>" from the +requires clause in the proposed wording.-In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. -
+[ +Post Summit: +]
+ ---string message() const; ---Returns: category().message(value()). +Alisdair: This issue has to stay in review pending a paper constraining +unique_ptr.
-
-Throws: Nothing.+Consensus: We agree with the resolution, but unique_ptr needs +to be constrained, too.-In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. +Recommend Keep in Review.
+[ +Batavia (2009-05): +]
--string message() const; --+Keep in Review status for the reasons cited. ++ + +Proposed resolution:
-Returns: category().message(value()). +Change 20.8.12.1.1 [unique.ptr.dltr.dflt]:
+ ++namespace std { + template <class T> struct default_delete { + default_delete(); + template <class U> + requires Convertible<U*, T*> + default_delete(const default_delete<U>&); + void operator()(T*) const; + }; +} +-
-Throws: Nothing.+...@@ -13529,336 +12898,368 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.template <class U> + requires Convertible<U*, T*> + default_delete(const default_delete<U>& other); +
-805. posix_error::posix_errno concerns
-Section: 19.4 [syserr] Status: Ready - Submitter: Jens Maurer Date: 2008-02-24
-View other active issues in [syserr].
-View all other issues in [syserr].
-View all issues with Ready status.
+857. condition_variable::time_wait return bool error prone
+Section: 30.5.1 [thread.condition.condvar] Status: Open + Submitter: Beman Dawes Opened: 2008-06-13 Last modified: 2009-06-14
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Open status.
Discussion:
-19.4 [syserr] +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.
- -namespace posix_error { - enum posix_errno { - address_family_not_supported, // EAFNOSUPPORT - ... ++It might be simpler to change the return type to a scoped enum: +
+enum class timeout { not_reached, reached };-should rather use the new scoped-enum facility (7.2 [dcl.enum]), -which would avoid the necessity for a new posix_error -namespace, if I understand correctly. +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. +]
+ +[ -Further discussion: +San Francisco: ]
+-See N2347, -Strongly Typed Enums, since renamed Scoped Enums. +There is concern that the enumeration names are just as confusing, if +not more so, as the bool. You might have awoken because of a signal or a +spurious wakeup, for example.
-Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. +Group feels that this is a defect that needs fixing.
-Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed. +Group prefers returning an enum over a void return.
-The wording for the Proposed resolution was provided by Beman Dawes. +Howard to provide wording.
[ +2009-06-14 Beman provided wording. +]
+ +Proposed resolution:
-Change System error support 19.4 [syserr] as indicated: +Change Condition variables 30.5 [thread.condition], Header +condition_variable synopsis, as indicated:
-+namespace posix_error {- enumposix_errnoclass errc { - address_family_not_supported, // EAFNOSUPPORT - ... - wrong_protocol_type, // EPROTOTYPE - }; -} // namespace posix_error- -template <> struct is_error_condition_enum<posix_error::posix_errnoerrc> - : public true_type {} +namespace std { + class condition_variable; + class condition_variable_any; -namespace posix_error {- error_code make_error_code(posix_errnoerrc e); - error_condition make_error_condition(posix_errnoerrc e); -} // namespace posix_error+ enum class cv_status { no_timeout, timeout }; +}-Change System error support 19.4 [syserr] : +Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
+class condition_variable { +public: + ... + template <class Clock, class Duration> +boolcv_status wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time); + template <class Clock, class Duration, class Predicate> + bool wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); + + template <class Rep, class Period> +boolcv_status wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time); + template <class Rep, class Period, class Predicate> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred); + ... +}; + +... + +template <class Clock, class Duration> +boolcv_status wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time); +-+The is_error_code_enum and is_error_condition_enum templates may be -specialized for user-defined types to indicate that such a type is -eligible for class error_code and class error_condition automatic -conversions, respectively.-+-15- Precondition: lock is locked by the calling thread, and either +
++
- +no other thread is waiting on this condition_variable object or +
+- +lock.mutex() returns the same value for each of the lock +arguments supplied by all concurrently waiting threads (via wait, +wait_for or wait_until.). +
+-Change System error support 19.4 [syserr] and its subsections: +-16- Effects:
--
- -remove all occurrences of posix_error:: +Atomically calls lock.unlock() and blocks on *this.
- -change all instances of posix_errno to errc +When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
- -change all instances of posix_category to generic_category +The function will unblock when signaled by a call to notify_one(), +a call to notify_all(),
by +the current time exceeding abs_timeif Clock::now() >= abs_time, +or spuriously.- -change all instances of get_posix_category to get_generic_category +If the function exits via an exception, lock.unlock() shall be called prior +to exiting the function scope.
-Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: +-17- Postcondition: lock is locked by the calling thread.
--Remarks: The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -+"POSIX""GENERIC". -+-18- Returns:
Clock::now() < abs_time+cv_status::timeout if the function unblocked because abs_time +was reached, otherwise cv_status::no_timeout. +-Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated: +-19- Throws: std::system_error when the effects or postcondition +cannot be achieved.
--+error_code make_error_code(+posix_errnoerrc e); -+-20- Error conditions: +
--Returns: error_code(static_cast<int>(e),+posixgeneric_category). -+
- +operation_not_permitted — if the thread does not own the lock. +
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+template <class Rep, class Period> ++boolcv_status wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time); + +++-21-
+EffectsReturns: +wait_until(lock, chrono::monotonic_clock::now() + rel_time) +-Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated: +
--22- Returns: false if the call is returning because the time +duration specified by rel_time has elapsed, +otherwise true.-- - - -error_condition make_error_condition(+posix_errnoerrc e); -[ +This part of the wording may conflict with 859 in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]
--Returns: error_condition(static_cast<int>(e),-posixgeneric_category).Rationale:
--
+... +template <class Lock, class Clock, class Duration> +- - -Names Considered -- - -portable --Too non-specific. Did not wish to reserve such a common word in -namespace std. Not quite the right meaning, either. - -- - -portable_error --Too long. Explicit qualification is always required for scoped enums, so -a short name is desirable. Not quite the right meaning, either. May be -misleading because *_error in the std lib is usually an exception class -name. - -- - -std_error --Fairly short, yet explicit. But in fully qualified names like -std::std_error::not_enough_memory, the std_ would be unfortunate. Not -quite the right meaning, either. May be misleading because *_error in -the std lib is usually an exception class name. - -- -generic --Short enough. The category could be generic_category. Fully qualified -names like std::generic::not_enough_memory read well. Reserving in -namespace std seems dicey. - -- +generic_error --Longish. The category could be generic_category. Fully qualified names -like std::generic_error::not_enough_memory read well. Misleading because -*_error in the std lib is usually an exception class name. - -template <class Clock, class Duration, class Predicate> + bool wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); +-- +generic_err --A bit less longish. The category could be generic_category. Fully -qualified names like std::generic_err::not_enough_memory read well. - -++ -+-23- Effects: +
+-while (!pred()) + if (!wait_until(lock, abs_time) == cv_status::timeout) + return pred(); +return true; +- +gen_err --Shorter still. The category could be generic_category. Fully qualified -names like std::gen_err::not_enough_memory read well. - -+-24- Returns: pred(). +
-- +generr --Shorter still. The category could be generic_category. Fully qualified -names like std::generr::not_enough_memory read well. - -+-25- [Note: +The returned value indicates whether the predicate evaluates to +true regardless of whether the timeout was triggered. +— end note]. +
+- +error --Shorter still. The category could be generic_category. Fully qualified -names like std::error::not_enough_memory read well. Do we want to use -this general a name? - -+Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated: +
-- +err --Shorter still. The category could be generic_category. Fully qualified -names like std::err::not_enough_memory read well. Although alone it -looks odd as a name, given the existing errno and namespace std names, -it seems fairly intuitive. -Problem: err is used throughout the standard library as an argument name -and in examples as a variable name; it seems too confusing to add yet -another use of the name. - -class condition_variable_any { +public: + ... + template <class Lock, class Clock, class Duration> +boolcv_status wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time); + template <class Lock, class Clock, class Duration, class Predicate> + bool wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); + + template <class Lock, class Rep, class Period> +boolcv_status wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time); + template <class Lock, class Rep, class Period, class Predicate> + bool wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred); + ... +}; -- -errc --Short enough. The "c" stands for "constant". The category could be -generic_category. Fully qualified names like -std::errc::not_enough_memory read well. Although alone it looks odd as a -name, given the existing errno and namespace std names, it seems fairly -intuitive. There are no uses of errc in the current C++ standard. - -boolcv_status wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time); ++++-13- Effects: +
++
-- +Atomically calls lock.unlock() and blocks on *this. +
+- +When unblocked, calls lock.lock() (possibly blocking on the lock) and returns. +
+- +The function will unblock when signaled by a call to notify_one(), +a call to notify_all(),
+by +the current time exceeding abs_timeif Clock::now() >= abs_time, +or spuriously. +- +If the function exits via an exception, lock.unlock() shall be called prior +to exiting the function scope. +
+
-806. unique_ptr::reset effects incorrect, too permissive
-Section: 20.7.11.2.5 [unique.ptr.single.modifiers] Status: Ready - Submitter: Peter Dimov Date: 2008-03-13
-View all issues with Ready status.
-Discussion:
-void unique_ptr::reset(T* p = 0) is currently specified as: +-14- Postcondition: lock is locked by the calling thread.
--Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). ---There are two problems with this. One, if get() == 0 and p != 0, the -deleter is called with a NULL pointer, and this is probably not what's -intended (the destructor avoids calling the deleter with 0.) +-15- Returns:
Clock::now() < abs_time+cv_status::timeout if the function unblocked because abs_time +was reached, otherwise cv_status::no_timeout.-Two, the special check for get() == p is generally not needed and such a -situation usually indicates an error in the client code, which is being -masked. As a data point, boost::shared_ptr was changed to assert on such -self-resets in 2001 and there were no complaints. +-16- Throws: std::system_error when the effects or postcondition +cannot be achieved.
-One might think that self-resets are necessary for operator= to work; it's specified to perform +-17- Error conditions:
-+reset( u.release() ); -+
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+template <class Lock, class Rep, class Period> ++ +boolcv_status wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time); + +- - - --and the self-assignment +-18-
- -EffectsReturns:-p = move(p); +wait_until(lock, chrono::monotonic_clock::now() + rel_time)-might appear to result in a self-reset. But it doesn't; the release() is -performed first, zeroing the stored pointer. In other words, p.reset( -q.release() ) works even when p and q are the same unique_ptr, and there -is no need to special-case p.reset( q.get() ) to work in a similar -scenario, as it definitely doesn't when p and q are separate. +
+-19- Returns: false if the call is returning because the time +duration specified by rel_time has elapsed, +otherwise true.[ +This part of the wording may conflict with 859 in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]
-Proposed resolution:
- --Change 20.7.11.2.5 [unique.ptr.single.modifiers]: -
+-+void reset(T* p = 0); +template <class Lock, class Clock, class Duration, class Predicate> + bool wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>&+rel_timeabs_time, + Predicate pred);--4- Effects: If-p ==get() == 0 there are no effects. Otherwise get_deleter()(get()). -+-20- Effects: +
+while (!pred()) + if (!wait_until(lock, abs_time) == cv_status::timeout) + return pred(); +return true; +-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: +-21- Returns: pred().
--@@ -13867,2927 +13268,2726 @@ Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:void reset(T* p = 0); ---+...
--2- Effects: If
p ==get() == 0 there are no effects. Otherwise get_deleter()(get()). +-22- [Note: +The returned value indicates whether the predicate evaluates to +true regardless of whether the timeout was triggered. +— end note].
-807. tuple construction should not fail unless its element's construction fails
-Section: 20.4.1.2 [tuple.cnstr] Status: Ready - Submitter: Howard Hinnant Date: 2008-03-13
-View all issues with Ready status.
+859. Monotonic Clock is Conditionally Supported?
+Section: 30.5 [thread.condition] Status: Open + Submitter: Pete Becker Opened: 2008-06-23 Last modified: 2009-06-14
+View all issues with Open status.
Discussion:
--527 Added a throws clause to bind constructors. I believe the same throws clause -should be added to tuple except it ought to take into account move constructors as well. -
+ -Proposed resolution:
-Add to 20.4.1.2 [tuple.cnstr]: +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.
- -+-For each tuple constructor and assignment operator, an exception is thrown only if the construction -or assignment of one of the types in Types throws an exception. +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? +
+[ +San Francisco: +]
-
-808. [forward] incorrect redundant specification
-Section: 20.2.2 [forward] Status: Ready - Submitter: Jens Maurer Date: 2008-03-13
-View other active issues in [forward].
-View all other issues in [forward].
-View all issues with Ready status.
-Discussion:
++ +-p4 (forward) says: +Nick: maybe instead of saying that chrono::monotonic_clock is +conditionally supported, we could say that it's always there, but not +necessarily supported..
--Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. ---First of all, lvalue-ness and rvalue-ness are properties of an expression, -not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. -Second, the phrase says exactly what the core language wording says for -folding references in 14.3.1 [temp.arg.type]/p4 and for function return values -in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should -at most be a note with cross-references to those sections.) +Beman: I'd prefer a typedef that identifies the best clock to use for +wait_for locks.
-The prose after the example talks about "forwarding as an int& (an lvalue)" etc. -In my opinion, this is a category error: "int&" is a type, "lvalue" is a -property of an expression, orthogonal to its type. (Btw, expressions cannot -have reference type, ever.) +Tom: combine the two concepts; create a duration clock type, but keep +the is_monotonic test.
-Similar with move: +Howard: if we create a duration_clock type, is it a typedef or an +entirely true type?
--Return type: an rvalue. --is just wrong and also redundant. +There was broad preference for a typedef.
- - -Proposed resolution:
-Change 20.2.2 [forward] as indicated: +Move to Open. Howard to provide wording to add a typedef for +duration_clock and to replace all uses of monotonic_clock in function +calls and signatures with duration_clock.
+[ +Howard notes post-San Francisco: +]
--template <class T> T&& forward(typename identity<T>::type&& t); --- -...
-
-Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.+After further thought I do not believe that creating a duration_clock typedef +is the best way to proceed. An implementation may not need to use a +time_point to implement the wait_for functions....
+--7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor -as
-an int&& (an rvalue). In the second call to factory, A1 is deduced -as int&, so i is forwarded to A's constructor asan int& (an lvalue). -In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as -double&& (an rvalue). +For example, on POSIX systems sleep_for can be implemented in terms of +nanosleep which takes only a duration in terms of nanoseconds. The current +working paper does not describe sleep_for in terms of sleep_until. +And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging +implementations to use monotonic clocks for sleep_for:template <class T> typename remove_reference<T>::type&& move(T&& t); --+...
+2 The member functions whose names end in _for take an argument that +specifies a relative time. Implementations should use a monotonic clock to +measure time for these functions. +-
-Return type: an rvalue.+I believe the approach taken in describing the effects of sleep_for +and try_lock_for is also appropriate for wait_for. I.e. these +are not described in terms of their _until variants.
-809. std::swap should be overloaded for array types
-Section: 25.2.3 [alg.swap] Status: Ready - Submitter: Niels Dekker Date: 2008-02-28
-View all other issues in [alg.swap].
-View all issues with Ready status.
-Discussion:
+Proposed resolution:
-For the sake of generic programming, the header
<algorithm>
should provide an -overload ofstd::swap
for array types: -template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); -- +Change 30.5.1 [thread.condition.condvar], p21-22: + --It became apparent to me that this overload is missing, when I considered how to write a swap -function for a generic wrapper class template. -(Actually I was thinking of Boost's value_initialized.) -Please look at the following template,
W
, and suppose that is intended to be a very -generic wrapper: -template<class T> class W { -public: - T data; -}; --ClearlyW<T>
is CopyConstructible and CopyAssignable, and therefore -Swappable, wheneverT
is CopyConstructible and CopyAssignable. -Moreover,W<T>
is also Swappable whenT
is an array type -whose element type is CopyConstructible and CopyAssignable. -Still it is recommended to add a custom swap function template to such a class template, -for the sake of efficiency and exception safety. -(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing -swap.) -This function template is typically written as follows: -template<class T> void swap(W<T>& x, W<T>& y) { - using std::swap; - swap(x.data, y.data); -} --Unfortunately, this will introduce an undesirable inconsistency, whenT
is an array. -For instance,W<std::string[8]>
is Swappable, but the current Standard does not -allow calling the custom swap function that was especially written forW
! -W<std::string[8]> w1, w2; // Two objects of a Swappable type. -std::swap(w1, w2); // Well-defined, but inefficient. -using std::swap; -swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!! ++-template <class Rep, class Period> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time);++++Precondition: lock is locked by the calling thread, and either +
++
+- no other thread is waiting on this condition_variable object or
+- lock.mutex() returns the same value for each of the lock +arguments supplied by all concurrently waiting threads (via wait, +wait_for or wait_until).
++21 Effects: +
++wait_until(lock, chrono::monotonic_clock::now() + rel_time)++
-- +Atomically calls lock.unlock() and blocks on *this. +
+ +- +When unblocked, calls lock.lock() (possibly blocking on the lock) and returns. +
+ +- +The function will unblock when signaled by a call to notify_one(), a call +to notify_all(), by +the elapsed time rel_time passing (30.2.4 [thread.req.timing]), +or spuriously. +
+ +- +If the function exits via an exception, lock.unlock() shall be called +prior to exiting the function scope. +
+W
'sswap
function would try to callstd::swap
for an array, -std::string[8]
, which is not supported by the Standard Library. -This issue is easily solved by providing an overload ofstd::swap
for array types. -This swap function should be implemented in terms of swapping the elements of the arrays, so that -it would be non-throwing for arrays whose element types have a non-throwing swap. ++Postcondition: lock is locked by the calling thread. +
-Note that such an overload of
-std::swap
should also support multi-dimensional -arrays. Fortunately that isn't really an issue, because it would do so automatically, by -means of recursion. +22 Returns: false if the call is returning because the time +duration specified by rel_time has elapsed, otherwise true.-For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard -Library] Shouldn't std::swap be overloaded for C-style arrays? -
+[ +This part of the wording may conflict with 857 in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]
-Proposed resolution:
--Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: -
--- T is Swappable if T is an array type whose element type is Swappable. +++Throws: std::system_error when the effects or postcondition cannot be achieved. +
+ ++Error conditions: +
+ ++
+- +operation_not_permitted -- if the thread does not own the lock. +
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+-Add the following to 25.2.3 [alg.swap]: +Change 30.5.1 [thread.condition.condvar], p26-p29:
+-+template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); +template <class Rep, class Period, class Predicate> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred);-Requires: Type-T
shall be Swappable. --Effects:+swap_ranges(a, a + N, b);
-+Precondition: lock is locked by the calling thread, and either +
++
+- no other thread is waiting on this condition_variable object or
+- lock.mutex() returns the same value for each of the lock +arguments supplied by all concurrently waiting threads (via wait, +wait_for or wait_until).
++26 Effects: +
+++wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))++
- +Executes a loop: Within the loop the function first evaluates pred() +and exits the loop if the result of pred() is true. +
+- +Atomically calls lock.unlock() +and blocks on *this. +
+- +When unblocked, calls lock.lock() (possibly blocking on the lock). +
+- +The function will unblock when signaled by a call to notify_one(), a +call to notify_all(), by the elapsed time rel_time passing (30.1.4 +[thread.req.timing]), or spuriously. +
+- +If the function exits via an exception, lock.unlock() shall be called +prior to exiting the function scope. +
+- +The loop terminates when pred() returns true or when the time +duration specified by rel_time has elapsed. +
++27 [Note: There is no blocking if pred() is initially true, +even if the timeout has already expired. -- end note] +
++Postcondition: lock is locked by the calling thread. +
- - -
-810. Missing traits dependencies in operational semantics of extended manipulators
-Section: 27.6.4 [ext.manip] Status: New - Submitter: Daniel Krügler Date: 2008-03-01
-View other active issues in [ext.manip].
-View all other issues in [ext.manip].
-View all issues with New status.
-Discussion:
-The recent draft (as well as the original proposal n2072) uses an -operational semantic -for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses +28 Returns: pred()
--istreambuf_iterator<charT> --and +29 [Note: The returned value indicates whether the predicate evaluates to +true regardless of whether the timeout was triggered. -- end note]
-+ostreambuf_iterator<charT> -+Throws: std::system_error when the effects or postcondition cannot be achieved. +
--resp, instead of the iterator instances, with explicitly provided -traits argument (The operational semantic defined by f is also traits -dependent). This is an obvious oversight because both *stream_buf -c'tors expect a basic_streambuf<charT,traits> as argument. -
--The same problem occurs within the get_time and put_time semantic (p. -7 and p. 9) -of n2071 incorporated in N2521, where additional to the problem we -have an editorial issue in get_time (streambuf_iterator instead of -istreambuf_iterator). -
++Error conditions: +
++
+ +- +operation_not_permitted -- if the thread does not own the lock. +
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+Proposed resolution:
-In 27.6.4 [ext.manip]/3 within function f replace the first line +Change 30.5.2 [thread.condition.condvarany], p18-19:
-- +template <class charT, class traits, class moneyT> -void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { - typedef istreambuf_iterator<charT, traits> Iter; - ... -+template <class Lock, class Rep, class Period> + bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time); ++-In 27.6.4 [ext.manip]/4 remove the first template charT parameter: +18 Effects:
- -+template <class charT,class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); +-wait_until(lock, chrono::monotonic_clock::now() + rel_time)-In 27.6.4 [ext.manip]/5 within function f replace the first line -
++
-- +Atomically calls lock.unlock() and blocks on *this. +
+ +- +When unblocked, calls lock.lock() (possibly blocking on the lock) and returns. +
+ +- +The function will unblock when signaled by a call to notify_one(), a call to +notify_all(), by +the elapsed time rel_time passing (30.2.4 [thread.req.timing]), +or spuriously. +
+ +- +If the function exits via an exception, lock.unlock() shall be called +prior to exiting the function scope. +
++template <class charT, class traits, class moneyT> -void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { - typedef ostreambuf_iterator<charT, traits> Iter; - ... -+Postcondition: lock is locked by the calling thread. +
-In 27.6.4 [ext.manip]/7 within function f replace the first line +19 Returns: false if the call is returning because the time duration +specified by rel_time has elapsed, otherwise true.
-+template <class charT, class traits> -void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { - typedef istreambuf_iterator<charT, traits> Iter; - ... -+Throws: std::system_error when the returned value, effects, +or postcondition cannot be achieved. +
--In 27.6.4 [ext.manip]/8 add const: -
++Error conditions: +
-+template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); -+
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+-In 27.6.4 [ext.manip]/9 within function f replace the first line +Change 30.5.2 [thread.condition.condvarany], p23-p26:
-- +template <class charT, class traits> -void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { - typedef ostreambuf_iterator<charT, traits> Iter; - ... -+-template <class Lock, class Rep, class Period, class Predicate> + bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred); +++++Precondition: lock is locked by the calling thread, and either +
++
- no other thread is waiting on this condition_variable object or
+- lock.mutex() returns the same value for each of the lock +arguments supplied by all concurrently waiting threads (via wait, +wait_for or wait_until).
+-Add to the <iomanip> synopsis in 27.6 [iostream.format] +23 Effects:
- -- - - - - - -template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false); -template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); -template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt); -template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); -
-811. pair of pointers no longer works with literal 0
-Section: 20.2.3 [pairs] Status: New - Submitter: Doug Gregor Date: 2008-03-14
-View all other issues in [pairs].
-View all issues with New status.
-Discussion:
-+#include <utility> - -int main() -{ - std::pair<char *, char *> p (0,0); -} -+wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))++
+- +Executes a loop: Within the loop the function first evaluates pred() +and exits the loop if the result of pred() is true. +
+- +Atomically calls lock.unlock() +and blocks on *this. +
+- +When unblocked, calls lock.lock() (possibly blocking on the lock). +
+- +The function will unblock when signaled by a call to notify_one(), a +call to notify_all(), by the elapsed time rel_time passing (30.1.4 +[thread.req.timing]), or spuriously. +
+- +If the function exits via an exception, lock.unlock() shall be called +prior to exiting the function scope. +
+- +The loop terminates when pred() returns true or when the time +duration specified by rel_time has elapsed. +
+-I just got a bug report about that, because it's valid C++03, but not -C++0x. The important realization, for me, is that the emplace -proposal---which made push_back variadic, causing the push_back(0) -issue---didn't cause this break in backward compatibility. The break -actually happened when we added this pair constructor as part of adding -rvalue references into the language, long before variadic templates or -emplace came along: +24 [Note: There is no blocking if pred() is initially true, +even if the timeout has already expired. -- end note]
-+template<class U, class V> pair(U&& x, V&& y); -+Postcondition: lock is locked by the calling thread. +
-Now, concepts will address this issue by constraining that pair -constructor to only U's and V's that can properly construct "first" and -"second", e.g. (from -N2322): +25 Returns: pred()
-- - - -template<class U , class V > -requires Constructible<T1, U&&> && Constructible<T2, V&&> -pair(U&& x , V&& y ); -Proposed resolution:
+26 [Note: The returned value indicates whether the predicate evaluates to +true regardless of whether the timeout was triggered. -- end note]
++Throws: std::system_error when the effects or postcondition cannot be achieved. +
++Error conditions: +
++
- -- +operation_not_permitted -- if the thread does not own the lock. +
+- +equivalent error condition from lock.lock() or lock.unlock(). +
+
-812. unsolicited multithreading considered harmful?
-Section: 25.3.1 [alg.sort] Status: New - Submitter: Paul McKenney Date: 2008-02-27
-View all issues with New status.
-Discussion:
--Multi-threading is a good thing, but unsolicited multi-threading can -potentially be harmful. For example, sort() performance might be -greatly increased via a multithreaded implementation. However, such -a multithreaded implementation could result in concurrent invocations -of the user-supplied comparator. This would in turn result in problems -given a caching comparator that might be written for complex sort keys. -Please note that this is not a theoretical issue, as multithreaded -implementations of sort() already exist. -
--Having a multithreaded sort() available is good, but it should not -be the default for programs that are not explicitly multithreaded. -Users should not be forced to deal with concurrency unless they have -asked for it. -
- -[ -This may be covered by -N2410 -Thread-Safety in the Standard Library (Rev 1). -]
- +Proposed resolution:
--
-813. "empty" undefined for shared_ptr
-Section: 20.7.12.2 [util.smartptr.shared] Status: Ready - Submitter: Matt Austern Date: 2008-02-26
-View other active issues in [util.smartptr.shared].
-View all other issues in [util.smartptr.shared].
-View all issues with Ready status.
+860. Floating-Point State
+Section: 26 [numerics] Status: Open + Submitter: Lawrence Crowl Opened: 2008-06-23 Last modified: 2009-03-09
+View other active issues in [numerics].
+View all other issues in [numerics].
+View all issues with Open status.
Discussion:
-Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr. -However, that term is nowhere defined. The closest thing we have to a -definition is that the default constructor creates an empty shared_ptr -and that a copy of a default-constructed shared_ptr is empty. Are any -other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What -are the properties of an empty shared_ptr? We should either clarify this -term or stop using it. -
+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.
-One reason it's not good enough to leave this term up to the reader's -intuition is that, in light of -N2351 -and issue 711, most readers' -intuitive understanding is likely to be wrong. Intuitively one might -expect that an empty shared_ptr is one that doesn't store a pointer, -but, whatever the definition is, that isn't it. -[ -Peter adds: +San Francisco: ]
--Or, what is an "empty" shared_ptr? -
- --
- -
- --Are any other shared_ptrs empty? +Nick: I think we already say that these functions do not introduce data +races; see 17.6.5.6/20
-Yes. Whether a given shared_ptr instance is empty or not is (*) -completely specified by the last mutating operation on that instance. -Give me an example and I'll tell you whether the shared_ptr is empty or -not. +Pete: there's more to it than not introducing data races; are these +states maintained per thread?
--(*) If it isn't, this is a legitimate defect. --- - -
-For example, is shared_ptr((T*) 0) empty? +Howard: 21.5/14 says that strtok and strerror are not required to avoid +data races, and 20.9/2 says the same about asctime, gmtime, ctime, and +gmtime.
-No. If it were empty, it would have a use_count() of 0, whereas it is -specified to have an use_count() of 1. +Nick: POSIX has a list of not-safe functions. All other functions are +implicitly thread safe.
-- +
-What are the properties of an empty shared_ptr? +Lawrence is to form a group between meetings to attack this issue. Nick +and Tom volunteered to work with Lawrence.
-The properties of an empty shared_ptr can be derived from the -specification. One example is that its destructor is a no-op. Another is -that its use_count() returns 0. I can enumerate the full list if you -really like. +Move to Open.
-- - --We should either clarify this term or stop using it. -
--I don't agree with the imperative tone -
--A clarification would be either a no-op - if it doesn't contradict the -existing wording - or a big mistake if it does. -
+[ +Post Summit: +]
+ + +-I agree that a clarification that is formally a no-op may add value. +Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
-- - -However, that term is nowhere defined. +Nick: Default wording seems to cover this? Hole in POSIX, these +functions need to be added to list of thread-unsafe functions.
-Terms can be useful without a definition. Consider the following -simplistic example. We have a type X with the following operations -defined: +Lawrence: Not sufficient, not "thread-safe" per our definition, but +think of state as a thread-local variable. Need something like "these +functions only affect state in the current thread."
-X x; -X x2(x); -X f(X x); -X g(X x1, X x2); --A default-constructed value is green.
-
-A copy has the same color as the original.
-f(x) returns a red value if the argument is green, a green value otherwise.
-g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise. +Hans: Suggest the following wording: "The floating point environment is +maintained per-thread."-Given these definitions, you can determine the color of every instance -of type X, even if you have absolutely no idea what green and red mean. +Walter: Any other examples of state being thread safe that are not +already covered elsewhere?
--Green and red are "nowhere defined" and completely defined at the same time. +Have thread unsafe functions paper which needs to be updated. Should +just fold in 26.3 [cfenv] functions.
--Alisdair's wording is fine. +Recommend Open. Lawrence instead suggests leaving it open until we have +suitable wording that may or may not include the thread local +commentary.
Proposed resolution:
-Append the following sentance to 20.7.12.2 [util.smartptr.shared]
--Theshared_ptr
class template stores a pointer, usually obtained -vianew
.shared_ptr
implements semantics of -shared ownership; the last remaining owner of the pointer is responsible for -destroying the object, or otherwise releasing the resources associated with -the stored pointer. Ashared_ptr
object that does not own -a pointer is said to be empty. -
-814. vector<bool>::swap(reference, reference) not defined
-Section: 23.2.7 [vector.bool] Status: New - Submitter: Alisdair Meredith Date: 2008-03-17
-View other active issues in [vector.bool].
-View all other issues in [vector.bool].
-View all issues with New status.
+861. Incomplete specification of EqualityComparable for std::forward_list
+Section: 23.2 [container.requirements] Status: Open + Submitter: Daniel Krügler Opened: 2008-06-24 Last modified: 2008-11-11
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Open status.
Discussion:
-vector<bool>::swap(reference, reference) has no definition. +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() +-Proposed resolution:
+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:
++
+- +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. +
+- +The simple fix where the usual test is adapted such that size() is replaced +by distance with corresponding performance disadvantages. +
++Both proposal choices are discussed, the preferred choice of the author is +to apply (A). +
+[ +San Francisco: +]
- -
-815. std::function and reference_closure do not use perfect forwarding
-Section: 20.6.15.2.4 [func.wrap.func.inv] Status: Open - Submitter: Alisdair Meredith Date: 2008-03-16
-View all issues with Open status.
-Discussion:
+-std::function and reference_closure should use "perfect forwarding" as -described in the rvalue core proposal. +There's an Option C: change the requirements table to use distance(). +
++LWG found Option C acceptable.
++Martin will draft the wording for Option C. +
+[ -Sophia Antipolis: +post San Francisco: ]
-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. +Martin provided wording for Option C.Proposed resolution:
+Common part:
- - - - - -
-816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
-Section: 20.6.11.1.3 [func.bind.bind] Status: New - Submitter: Stephan T. Lavavej Date: 2008-02-08
-View other active issues in [func.bind.bind].
-View all other issues in [func.bind.bind].
-View all issues with New status.
-Discussion:
++
+ +- +
-Library Issue 527 notes that bind(f, t1, ..., tN) -should be nofail when f, t1, ..., tN have nofail copy ctors. +Just betwen 23.3.3.5 [forwardlist.ops] and 23.3.3.6 [forwardlist.spec] +add a new +section "forwardlist comparison operators" [forwardlist.compare] (and +also add the +new section number to 23.3.3 [forwardlist]/2 in front of "Comparison operators"):
--However, no guarantees are provided for the copy ctor of the functor -returned by bind(). (It's guaranteed to have a copy ctor, which can -throw implementation-defined exceptions: bind() returns a forwarding -call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, -TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. -Everything without an exception-specification may throw -implementation-defined exceptions unless otherwise specified, C++03 -17.4.4.8/3.) +
+forwardlist comparison operators [forwardlist.compare] +++Option (A):
+++ ++
-Should the nofail guarantee requested by Library Issue 527 be extended -to cover both calling bind() and copying the returned functor? +Add to the new section [forwardlist.compare] the following paragraphs:
-[ -Howard adds: -]
- --tuple construction should probably have a similar guarantee. -- - - -Proposed resolution:
+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]).
- - - - - -
-817. bind needs to be moved
-Section: 20.6.11.1.3 [func.bind.bind] Status: New - Submitter: Howard Hinnant Date: 2008-03-17
-View other active issues in [func.bind.bind].
-View all other issues in [func.bind.bind].
-View all issues with New status.
-Discussion:
-The functor retureed by bind() should have a move constructor that -requires only move construction of its contained functor and bound arguments. -That way move-only functors can be passed to objects such as thread. +Returns: true if
++
- +
-This issue is related to issue 816. +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:
- - -Proposed resolution:
++*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.
- - - - - -
-818. wording for memory ordering
-Section: 29.1 [atomics.order] Status: New - Submitter: Jens Maurer Date: 2008-03-22
-View all issues with New status.
-Discussion:
-29.1 [atomics.order] p1 says in the table that +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). +- -Element Meaning -- -memory_order_acq_rel -the operation has both acquire and release semantics --To my naked eye, that seems to imply that even an atomic read has both -acquire and release semantics. +Option (B):
- +++ -+
-Then, p1 says in the table: +Add to the new section [forwardlist.compare] the following paragraphs:
--- +-
-- -Element Meaning -- -memory_order_seq_cst -the operation has both acquire and release semantics, - and, in addition, has sequentially-consistent operation ordering -template <class T, class Allocator> +bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +++-So that seems to be "the same thing" as memory_order_acq_rel, with additional -constraints. +Requires: Type T is EqualityComparable ([equalitycomparable]).
--I'm then reading p2, where it says: +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); +-The memory_order_seq_cst operations that load a value are acquire operations -on the affected locations. The memory_order_seq_cst operations that store a value -are release operations on the affected locations. +Returns: !(x == y). +-That seems to imply that atomic reads only have acquire semantics. If that -is intended, does this also apply to memory_order_acq_rel and the individual -load/store operations as well? -
+ +-Also, the table in p1 contains phrases with "thus" that seem to indicate -consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in -normative text, for the fear of redundant or inconsistent specification with -the other normative text. +Option (C):
- ++-+
- +
-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.) +Change Table 91 - Container Requirements in 23.2.1 [container.requirements.general] +(N2798) like so:
++
+- +
-29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in -1.10 [intro.multithread], it's just used in notes there. +Change the text in the Operational Semantics column in + the row for a == b as follows:
++== is an equivalence relation. + distance(a.begin(), a.end()) ++a.size()== + distance(b.begin(), b.end())b.size()&& + equal(a.begin(), a.end(), b.begin()) +- +
-And why does 29.4 [atomics.types.operations] p9 for "load" say: +Change the text in the Operational Semantics column in + the row for a.max_size() as follows:
- --Requires: The order argument shall not be memory_order_acquire -nor memory_order_acq_rel. +distance(a.begin(), a.end()) ++a.size()of the largest possible container- +
-(Since this is exactly the same restriction as for "store", it seems to be a typo.) +Change the text in the Operational Semantics column in + the row for a.empty() as follows:
++a.begin() == a.end() ++a.size() == 0+- +
-And then: 29.4 [atomics.types.operations] p12: +In addition, for consistency, change the text in the + Operational Semantics column in the row for a.size() + as follows:
--These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. +distance(a.begin(), a.end()) ++a.end() - a.begin()+-This is redundant with 1.10 [intro.multithread], see above for the reasoning. -
-Proposed resolution:
--Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of -1.7 [intro.memory]. -Rephrase the table in as follows (maybe don't use a table): -
----For memory_order_relaxed, no operation orders memory. -
+
+862. Impossible complexity for 'includes'
+Section: 25.5.5.1 [includes] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2008-07-02 Last modified: 2009-05-23
+View other active issues in [includes].
+View all other issues in [includes].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
-For memory_order_release, memory_order_acq_rel, and memory_order_seq_cst, -a store operation performs a release operation on the affected memory location. +In 25.5.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!
-For memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst, -a load operation performs an acquire operation on the affected memory location. +This same issue also applies to:
--Rephrase 29.1 [atomics.order] p2: -
++
-- set_union
+- set_intersection
+- set_difference
+- set_symmetric_difference
+- merge
+-+The memory_order_seq_cst operations that load a value are -acquire operations on the affected locations. The -memory_order_seq_cst operations that store a value are release -operations on the affected locations.-In addition, in a consistent -execution, tTheremust beis a single -total order S on all -memory_order_seq_cst operations, consistent with the happens before -order and modification orders for all affected locations, such that each -memory_order_seq_cst operation observes either the last preceding -modification according to this order S, or the result of an operation -that is not memory_order_seq_cst. [Note: Although it is not explicitly -required that S include locks, it can always be extended to an order -that does include lock and unlock operations, since the ordering between -those is already included in the happens before ordering. -- end note] -[ +2009-03-30 Beman adds: +]
--Rephrase 29.4 [atomics.types.operations] p12 as: -
-Effects: Atomically replaces the value pointed to by object or by -this with desired. Memory is affected according to the value of order. -These operations are read-modify-write operations-in the sense of the -"synchronizes with" definition(1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. +Suggest NAD. The complexity of empty ranges is -1 in other places in the +standard. See 25.5.4 [alg.merge] merge and +inplace_merge, and forward_list merge, for example. +The time and effort to find and fix all places in the standard where +empty range[s] result in negative complexity isn't worth the very +limited benefit.-Same in p15, p20, p22. -
- - - - +[ +2009-05-09 Alisdair adds: +]
-
-819. rethrow_if_nested
-Section: 18.7.6 [except.nested] Status: New - Submitter: Alisdair Meredith Date: 2008-03-25
-View all issues with New status.
-Discussion:
++ +-Looking at the wording I submitted for rethrow_if_nested, I don't think I -got it quite right. +I'm not happy with NAD if we can find a simple solution.
--The current wording says: +How about adding a rider somewhere in clause 17 suggesting that complexities +that specify a negative number of operations are treated as specifying zero +operations? That should generically solve the issue without looking for +further cases.
+[ +Batavia (2009-05): +]
--template <class E> void rethrow_if_nested(const E& e); ---+Pete to provide "straightforward" wording. +Move to NAD Editorial.-Effects: Calls e.rethrow_nested() only if e -is publicly derived from nested_exception. -
--This is trying to be a bit subtle, by requiring e (not E) to be publicly -derived from nested_exception the idea is that a dynamic_cast would be -required to be sure. Unfortunately, if e is dynamically but not statically -derived from nested_exception, e.rethrow_nested() is ill-formed. -
-Proposed resolution:
++Recommend NAD. +
-820. current_exception()'s interaction with throwing copy ctors
-Section: 18.7.5 [propagation] Status: New - Submitter: Stephan T. Lavavej Date: 2008-03-26
-View other active issues in [propagation].
-View all other issues in [propagation].
-View all issues with New status.
+863. What is the state of a stream after close() succeeds
+Section: 27.9.1 [fstreams] Status: Tentatively NAD + Submitter: Steve Clamage Opened: 2008-07-08 Last modified: 2009-05-23
+View all other issues in [fstreams].
+View all issues with Tentatively NAD status.
Discussion:
-As of N2521, the Working Paper appears to be silent about what -current_exception() should do if it tries to copy the currently handled -exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the -function needs to allocate memory and the attempt fails, it returns an -exception_ptr object that refers to an instance of bad_alloc.", but -doesn't say anything about what should happen if memory allocation -succeeds but the actual copying fails. +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.
--I see three alternatives: (1) return an exception_ptr object that refers -to an instance of some fixed exception type, (2) return an exception_ptr -object that refers to an instance of the copy ctor's thrown exception -(but if that has a throwing copy ctor, an infinite loop can occur), or -(3) call terminate(). +If either overflow or fclose fails, close() reports failure, and clearly +the stream should be in a failed or bad state.
--I believe that terminate() is the most reasonable course of action, but -before we go implement that, I wanted to raise this issue. +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?
[ -Peter's summary: +Batavia (2009-05): ]
--The current practice is to not have throwing copy constructors in -exception classes, because this can lead to terminate() as described in -15.5.1 [except.terminate]. Thus calling terminate() in this situation seems -consistent and does not introduce any new problems. +Tom's impression is that the issue is about the failbit, etc.
--However, the resolution of core issue 475 may relax this requirement: +Bill responds that the stream is now closed, +and any status bits remain unchanged.
- --The CWG agreed with the position that std::uncaught_exception() should -return false during the copy to the exception object and that std::terminate() -should not be called if that constructor exits with an exception. ---Since throwing copy constructors will no longer call terminate(), option -(3) doesn't seem reasonable as it is deemed too drastic a response in a -recoverable situation. +See the description of close() in 27.9.1.17 [fstream.members].
--Option (2) cannot be adopted by itself, because a potential infinite -recursion will need to be terminated by one of the other options. +We prefer not to add wording to say that nothing changes. +Move to NAD.
-Proposed resolution:
-Add the following paragraph after 18.7.5 [propagation]/7: -
- ----Returns (continued): If the attempt to copy the current exception -object throws an exception, the function returns an exception_ptr that -refers to the thrown exception or, if this is not possible, to an -instance of bad_exception. -
--[Note: The copy constructor of the thrown exception may also fail, so -the implementation is allowed to substitute a bad_exception to avoid -infinite recursion. -- end note.]
-
-821. Minor cleanup : unique_ptr
-Section: 20.7.11.3.3 [unique.ptr.runtime.modifiers] Status: New - Submitter: Alisdair Meredith Date: 2008-03-30
-View all issues with New status.
-Discussion:
+865. More algorithms that throw away information
+Section: 25.4.6 [alg.fill], 25.4.7 [alg.generate] Status: Open + Submitter: Daniel Krügler Opened: 2008-07-13 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
-Reading resolution of LWG issue 673 I noticed the following: +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:
--+void reset(+T*pointer p =0pointer()); -+
- +
+template<class OutputIterator, class Size, class T> +void fill_n(OutputIterator first, Size n, const T& value);- +
+template<class OutputIterator, class Size, class Generator> +void generate_n(OutputIterator first, Size n, Generator gen);--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] +In both cases the minimum requirements on the iterator are +OutputIterator, which means according to the requirements of +24.2.3 [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.[ +Post Summit Daniel "conceptualized" the wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++Alisdair likes the idea, but has concerns about the specific wording +about the returns clauses. +
++Alan notes this is a feature request. +
++Bill notes we have made similar changes to other algorithms. +
-This could be cleaned up by mandating the overload as a public deleted -function. In addition, we should probably overload reset on nullptr_t -to be a stronger match than the deleted overload. Words... +Move to Open.
+Proposed resolution:
++
- +
-Add to class template definition in 20.7.11.3 [unique.ptr.runtime] +Replace the current declaration of fill_n in 25 [algorithms]/2, header +<algorithm> synopsis and in 25.4.6 [alg.fill] by
--+// modifiers -T* release(); -void reset(T* p = 0); -void reset( nullptr_t ); -template< typename T > void reset( T ) = delete; -void swap(unique_ptr&& u); --template<class Iter, IntegralLike Size, class T> + requires OutputIterator<Iter, const T&> +voidIter fill_n(Iter first, Size n, const T& value); +-Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] +Just after the effects clause p.1 add a new returns clause saying:
--+void reset(pointer p = pointer()); -void reset(nullptr_t); -- +Returns: For fill_n and n > Size(0), returns first + n. Otherwise +returns first for fill_n. +- +
-
+-1- Requires: Does not accept pointer types which are convertible -to pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note]+Replace the current declaration of generate_n in 25 [algorithms]/2, header +<algorithm> synopsis and in 25.4.7 [alg.generate] bytemplate<class Iter, IntegralLike Size, Callable Generator> + requires OutputIterator<Iter, Generator::result_type> + && CopyConstructible<Generator> +voidIter generate_n(Iter first, Size n, Generator gen); +-Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). +Just after the effects clause p.1 add a new returns clause saying:
-...
++Returns: For generate_n and n > Size(0), returns first + n. +Otherwise returns first for generate_n.- -[ -Note this wording incorporates resolutions for 806 (New) and 673 (Ready). -]
- +
-822. Object with explicit copy constructor no longer CopyConstructible
-Section: 20.1.1 [utility.arg.requirements] Status: New - Submitter: James Kanze Date: 2008-04-01
-View other active issues in [utility.arg.requirements].
-View all other issues in [utility.arg.requirements].
-View all issues with New status.
+867. Valarray and value-initialization
+Section: 26.6.2.1 [valarray.cons] Status: Tentatively NAD Editorial + Submitter: Alberto Ganesh Barbati Opened: 2008-07-20 Last modified: 2009-05-23
+View other active issues in [valarray.cons].
+View all other issues in [valarray.cons].
+View all issues with Tentatively NAD Editorial status.
Discussion:
-I just noticed that the following program is legal in C++03, but -is forbidden in the current draft: +From 26.6.2.1 [valarray.cons], paragraph 2:
-+#include <vector> -#include <iostream> +-class Toto -{ -public: - Toto() {} - explicit Toto( Toto const& ) {} -} ; +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: +
-int -main() -{ - std::vector< Toto > v( 10 ) ; - return 0 ; -} -+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. +-Is this change intentional? (And if so, what is the -justification? I wouldn't call such code good, but I don't see -any reason to break it unless we get something else in return.) +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).
+[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to NAD Editorial. +Proposed resolution:
-In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: +Change 26.6.2.1 [valarray.cons], paragraph 2:
--
+- -expression post-condition -- -T t(rv) = rvt is equivalent to the value of rv before the construction -- -... -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 areconstructed using the default constructor for the instantiating type T+value-initialized (8.5 [dcl.init]). +-In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: +Change 26.6.2.7 [valarray.members], paragraph 9:
-+-
+[Example: If the argument has the value -2, the first two elements of the result will be- -expression post-condition -- -T t(u) = uthe value of u is unchanged and is equivalent to t -- -... -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]
-823. identity<void> seems broken
-Section: 20.2.2 [forward] Status: Review - Submitter: Walter Brown Date: 2008-04-09
-View other active issues in [forward].
-View all other issues in [forward].
-View all issues with Review status.
+868. default construction and value-initialization
+Section: 23 [containers] Status: Open + Submitter: Alberto Ganesh Barbati Opened: 2008-07-22 Last modified: 2008-09-22
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with Open status.
Discussion:
-N2588 seems to have added an operator() member function to the -identity<> helper in 20.2.2 [forward]. I believe this change makes it no -longer possible to instantiate identity<void>, as it would require -forming a reference-to-void type as this operator()'s parameter type. -
- --Suggested resolution: Specialize identity<void> so as not to require -the member function's presence. +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.
[ -Sophia Antipolis: +San Francisco: ]
-Jens: suggests to add a requires clause to avoid specializing on void. -
--Alisdair: also consider cv-qualified void. +The list provided in the proposed resolution is not complete. James +Dennett will review the library and provide a complete list and will +double-check the vocabulary.
-Alberto provided proposed wording. +This issue relates to Issue 886 tuple construction
Proposed resolution:
-Change definition of identity in 20.2.2 [forward], paragraph 2, to: +Change X [utility.arg.requirements], paragraph 2:
--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; -+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]). +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?). +In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized +(8.5 [dcl.init])":
++
+- 23.3.2.1 [deque.cons] para 2
+- 23.3.2.2 [deque.capacity] para 1
+- 23.3.3.1 [forwardlist.cons] para 3
+- 23.3.3.4 [forwardlist.modifiers] para 21
+- 23.3.4.1 [list.cons] para 3
+- 23.3.4.2 [list.capacity] para 1
+- 23.3.6.1 [vector.cons] para 3
+- 23.3.6.2 [vector.capacity] para 10
+
-824. rvalue ref issue with basic_string inserter
-Section: 21.3.8.9 [string.io] Status: Ready - Submitter: Alisdair Meredith Date: 2008-04-10
-View all other issues in [string.io].
-View all issues with Ready status.
+869. Bucket (local) iterators and iterating past end
+Section: 23.2.5 [unord.req] Status: Tentatively Ready + Submitter: Sohail Somani Opened: 2008-07-22 Last modified: 2009-03-09
+View other active issues in [unord.req].
+View all other issues in [unord.req].
+View all issues with Tentatively Ready status.
Discussion:
-In the current working paper, the <string> header synopsis at the end of -21.2 [string.classes] lists a single operator<< overload -for basic_string. -
- -- -template<class charT, class traits, class Allocator> - basic_ostream<charT, traits>& - operator<<(basic_ostream<charT, traits>&& os, - const basic_string<charT,traits,Allocator>& str); --The definition in 21.3.8.9 [string.io] lists two: +Is there any language in the current draft specifying the behaviour of the following snippet?
--template<class charT, class traits, class Allocator> - basic_ostream<charT, traits>& - operator<<(basic_ostream<charT, traits>& os, - const basic_string<charT,traits,Allocator>& str); +unordered_set<int> s; +unordered_set<int>::local_iterator it = s.end(0); -template<class charT, class traits, class Allocator> - basic_ostream<charT, traits>& - operator<<(basic_ostream<charT, traits>&& os, - const basic_string<charT,traits,Allocator>& str); +// Iterate past end - the unspecified part +it++;-I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two -signatures in 21.3.8.9 [string.io] should be deleted. -
- - -Proposed resolution:
--Delete the first of the two signatures in 21.3.8.9 [string.io]: +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.
-- - - - +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); -[ +San Francisco: +]
-
-825. Missing rvalues reference stream insert/extract operators?
-Section: 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8 -[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 -[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 -[re.submatch] Status: Open - Submitter: Alisdair Meredith Date: 2008-04-10
-View all issues with Open status.
-Discussion:
--Should the following use rvalues references to stream in insert/extract -operators? -
--
+- 19.4.2.1 [syserr.errcode.overview]
-- 20.7.12.2.8 [util.smartptr.shared.io]
-- 22.2.8 [facets.examples]
-- 23.3.5.3 [bitset.operators]
-- 26.3.6 [complex.ops]
-- Doubled signatures in 27.5 [stream.buffers] for character inserters -(ref 27.6.2.6.4 [ostream.inserters.character]) -+ definition 27.6.2.6.4 [ostream.inserters.character]
-- 28.9 [re.submatch]
-+We believe that this is not a substantive change, but the proposed +change to the wording is clearer than what we have now. +[ -Sophia Antipolis +Post Summit: ]
-Agree with the idea in the issue, Alisdair to provide wording. +Recommend Tentatively Ready.Proposed resolution:
+Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
++-+
+Table 97: Unordered associative container requirements ++ +expression return type assertion/note pre/post-condition complexity ++ +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 +
-827. constexpr shared_ptr::shared_ptr()?
-Section: 20.7.12.2.1 [util.smartptr.shared.const] Status: New - Submitter: Peter Dimov Date: 2008-04-11
-View all other issues in [util.smartptr.shared.const].
-View all issues with New status.
-Discussion:
--Would anyone object to making the default constructor of shared_ptr (and -weak_ptr and enable_shared_from_this) constexpr? This would enable -static initialization for shared_ptr variables, eliminating another -unfair advantage of raw pointers. -
- - -Proposed resolution:
--
- - -
-828. Static initialization for std::mutex?
-Section: 30.3.1.1 [thread.mutex.class] Status: Review - Submitter: Peter Dimov Date: 2008-04-18
-View all issues with Review status.
+873. signed integral type and unsigned integral type are not clearly defined
+Section: 3.9.1 [basic.fundamental] Status: Open + Submitter: Travis Vitek Opened: 2008-06-30 Last modified: 2009-03-21
+View all issues with Open status.
Discussion:
--[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] -
--Currently std::mutex doesn't support static initialization. This is a -regression with respect to pthread_mutex_t, which does. I believe that -we should strive to eliminate such regressions in expressive power where -possible, both to ease migration and to not provide incentives to (or -force) people to forego the C++ primitives in favor of pthreads. -
++ 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
andwchar_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, ifT
isunsigned char
, the + expressionmake_signed<T>::type
, is supposed to + name a signed integral type. There are potentially two types that + satisfy this requirement, namelysigned char
and +char
(assumingCHAR_MIN < 0
). +[ -Sophia Antipolis: +San Francisco: ]
-+-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. -
+Plum, Sebor to review.[ +Post Summit Daniel adds: +]
-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: Ready - Submitter: Beman Dawes Date: 2008-04-20
-View other active issues in [propagation].
-View all other issues in [propagation].
-View all issues with Ready status.
-Discussion:
-Consider this code:
--exception_ptr xp;-try {do_something(); } - -catch (const runtime_error& ) {xp = current_exception();} - -... - -rethrow_exception(xp);+The proposed resolution needs to be "conceptualized". Currently we have +in 14.10.4 [concept.support] only concept IntegralType +for all "integral types", thus indeed the current Container +concept and Iterator concepts are sufficiently satisfied with "integral +types". If the changes are applied, we might ask core for concept +BilateralIntegerType and add proper restrictions to the library +concepts.-Say
+ -do_something()
throws an exception object of type-range_error
. What is the type of the exception object thrown by-rethrow_exception(xp)
above? It must have a type ofrange_error
; -if it were of typeruntime_error
it still isn't possible to -propagate an exception and the exception_ptr/current_exception/rethrow_exception -machinery serves no useful purpose. --Unfortunately, the current wording does not explicitly say that. Different -people read the current wording and come to different conclusions. While it may -be possible to deduce the correct type from the current wording, it would be -much clearer to come right out and explicitly say what the type of the referred -to exception is. -
+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... +
++-+
+
+ +- + 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 asstd::ptrdiff_t
in the +<cstdint>
header (18.1)... +[ -Peter adds: -]
++ 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. + X [allocator.requirements] table 40... +
++ Table 40: Allocator requirements +++ +
++ + + +expression +return type +assertion/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.6.6.3 [meta.trans.sign] table 48... +
++ Table 48: Sign modifications +-+ +
++ + + +Template +Comments ++ ++ template <class T> struct make_signed; + ++ If +T
names a (possibly cv-qualified)signed + integral typesigned integer type (3.9.1) then + the member typedeftype
shall name the type +T
; otherwise, ifT
names a (possibly + cv-qualified)unsigned integral typeunsigned + integer type thentype
shall name the + correspondingsigned 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 whichsizeof(T) == + sizeof(type)
, with the same cv-qualifiers as +T
. --+ Requires:-I don't like the proposed resolution of 829. The normative text is -unambiguous that the exception_ptr refers to the currently handled -exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the -exception that throw; would rethrow, see 15.1 [except.throw]/7. -
--A better way to address this is to simply add the non-normative example -in question as a clarification. The term currently handled exception -should be italicized and cross-referenced. A [Note: the currently -handled exception is the exception that a throw expression without an -operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option. -
-T
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 typedeftype
+ shall name the typeT
; otherwise, if +T
names a (possibly cv-qualified)signed + integral typesigned integer type then +type
shall name the correspondingunsigned + integral typeunsigned integer type, with the + same cv-qualifiers asT
; otherwise, +type
shall name theunsigned integral + typeunsigned integer type with the smallest + rank (4.13) for whichsizeof(T) == sizeof(type)
, + with the same cv-qualifiers asT
. + Requires:T
shall be a (possibly + cv-qualified) integral type or enumeration but not a +bool
type. +Proposed resolution:
++ Note: I believe that the basefield values should probably be + prefixed with ios_base:: as they are in 22.4.2.2.2 [facet.num.put.virtuals] -
-After 18.7.5 [propagation] , paragraph 7, add the indicated text: -
+ The listed virtuals are all overloaded on signed and unsigned integer + types, the new wording just maintains consistency. --+ +exception_ptr current_exception();- ----Returns:
+ 22.4.2.1.2 [facet.num.get.virtuals] table 78... + +exception_ptr
object that refers -to the currently handled exception (15.3 [except.handle]) or a copy of the currently handled -exception, or a nullexception_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 ofbad_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 whethercurrent_exception
-creates a new copy each time it is called. --- end note] -+ Table 78: Integer Conversions +-+ +
++ + + +State +stdio equivalent ++ +basefield == oct +%o ++ +basefield == hex +%X ++ +basefield == 0 +%i ++ ++ signed integral typesigned integer + type%d ++ + ++ unsigned integral typeunsigned integer + type%u +-Throws: nothing. -
+ + ++ Rationale is same as above. + 22.4.2.2.2 [facet.num.put.virtuals] table 80... +
++ Table 80: Integer Conversions +-+ +
++ + + +State +stdio 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.2 [container.requirements] table 80... +
++ Table 89: Container requirements +++ +
++ + + +expression +return type +operational semantics +assertion/note/pre/post-condition +complexity ++ +X::difference_type ++ signed integral typesigned integer type+ is identical to the difference type of X::iterator + and X::const_iterator +compile time ++ + +X::size_type ++ unsigned integral typeunsigned integer type+ size_type can represent any non-negative value of + difference_type +compile time ++ 24.2 [iterator.concepts] 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 typeT
, + called the value type of the iterator. All output iterators + support the expression*i = o
whereo
is a + value of some type that is in the set of types that are + writable to the particular iterator type ofi
. All + iteratorsi
for which the expression(*i).m
+ is well-defined, support the expressioni->m
with the + same semantics as(*i).m
. For every iterator type +X
for which equality is defined, there is a corresponding +signed integral typesigned 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.5.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 asm - 1
. If the + template parameterm
is 0, the modulusm
+ 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
andc < + m
. ++ Same rationale as the previous change. + X [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.5.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 anunsigned 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.6 [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. +
-830. Incomplete list of char_traits specializations
-Section: 21.1 [char.traits] Status: Open - Submitter: Dietmar Kühl Date: 2008-04-23
-View all other issues in [char.traits].
+876. basic_string access operations should give stronger guarantees
+Section: 21.4 [basic.string] Status: Open + Submitter: Daniel Krügler Opened: 2008-08-22 Last modified: 2008-09-18
+View other active issues in [basic.string].
+View all other issues in [basic.string].
View all issues with Open status.
Discussion:
- Paragraph 4 of 21.1 [char.traits] mentions that this - section specifies two specializations (
- -char_traits<char>
- and (char_traits<wchar_t>
). However, there are actually - four specializations provided, i.e. in addition to the two above also -char_traits<char16_t>
andchar_traits<char32_t>
). - I guess this was just an oversight and there is nothing wrong with just - fixing this. +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.[ -Alisdair adds: -]
- --char_traits< char16/32_t > -should also be added to <ios_fwd> in 27.2 [iostream.forward], and all the specializations -taking a char_traits parameter in that header. -- -[ -Sophia Antipolis: -]
- - -- - --Idea of the issue is ok. +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.
-Alisdair to provide wording, once that wording arrives, move to review. +Due to earlier support for copy-on-write, we find the following +unnecessary limitations for C++0x:
-Proposed resolution:
-- Replace paragraph 4 of 21.1 [char.traits] by: -
--- - - - - -- This subclause specifies a struct template,
-char_traits<charT>
, - and four explicit specializations of it,char_traits<char>
, -char_traits<char16_t>
,char_traits<char32_t>
, and -char_traits<wchar_t>
, all of which appear in the header - <string> and satisfy the requirements below. -
-832. Applying constexpr to System error support
-Section: 19.4 [syserr] Status: Open - Submitter: Beman Dawes Date: 2008-05-14
-View other active issues in [syserr].
-View all other issues in [syserr].
-View all issues with Open status.
-Discussion:
--Initialization of objects of class error_code -(19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of -the new constexpr feature -[N2349] -of C++0x. Less code will need to be -generated for both library implementations and user programs when -manipulating constant objects of these types. -
- --This was not proposed originally because the constant expressions -proposal was moving into the standard at about the same time as the -Diagnostics Enhancements proposal -[N2241], -and it wasn't desirable to -make the later depend on the former. There were also technical concerns -as to how constexpr would apply to references. Those concerns are now -resolved; constexpr can't be used for references, and that fact is -reflected in the proposed resolution. -
- --Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements. -
++
- +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. +
+- +Missing complexity guarantees: data() and c_str() simply return +a pointer to their guts, which is guaranteed O(1). This should be +spelled out. +
+- +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. +
+-LWG issue 804 is related in that it raises the question of whether the -exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. -While in the context of 804 that is arguably an editorial question, -presenting it as a pointer becomes more or less required with this -proposal, given constexpr does not play well with references. The -proposed resolution thus changes the private member to a pointer, which -also brings it in sync with real implementations. +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.
[ -Sophia Antipolis: -]
- - --On going question of extern pointer vs. inline functions for interface. -- -[ -Pre-San Francisco: +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. +We oppose part 1 of the issue but hope to address size() in +issue 877.
- -Proposed resolution:
-The proposed wording assumes the LWG 805 proposed wording has been -applied to the WP, resulting in the former posix_category being renamed -generic_category. If 805 has not been applied, the names in this -proposal must be adjusted accordingly. +We do not support part B. 4 of the issue because of the breaking API change.
--Change 19.4.1.1 [syserr.errcat.overview] Class -error_category overview error_category synopsis as -indicated: +We support part A. 2 of the issue.
- --const error_category& get_generic_category();-const error_category& get_system_category();- -staticextern const error_category&* const generic_category= get_generic_category(); -staticextern const error_category&* constnative_categorysystem_category= get_system_category(); --Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +On support part A. 3 of the issue:
--extern const error_category-&* constget_generic_category(); --
- -Returns: A referencegeneric_category shall point -toana statically initialized object of a type derived from -class error_category. --
- -Remarks:The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -"GENERIC". -extern const error_category- -&* constget_system_category(); --
- -Returns: A referencesystem_category shall point -toana statically -initialized object of a type derived from class error_category. --
- -Remarks:The object's equivalent virtual functions shall behave as -specified for class error_category. The object's name virtual function -shall return a pointer to the string "system". The object's -default_error_condition virtual function shall behave as follows: --If the argument ev corresponds to a POSIX errno value posv, the function -shall return error_condition(posv, generic_category). Otherwise, the -function shall return error_condition(ev, system_category). What -constitutes correspondence for any given operating system is -unspecified. [Note: The number of potential system error codes is large -and unbounded, and some may not correspond to any POSIX errno value. -Thus implementations are given latitude in determining correspondence. --- end note] -
+Pete's broader comment: now that we know that basic_string will be a +block of contiguous memory, we should just rewrite its specification +with that in mind. The expression of the specification will be simpler +and probably more correct as a result. +-Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: -
- --class error_code { -public: - ...; - constexpr error_code(int val, const error_category&* cat); - ... - void assign(int val, const error_category&* cat); - ... - const error_category&* category() const; - ... -private: - int val_; // exposition only - const error_category&* cat_; // exposition only --Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: +
Proposed resolution:
++
-- +
++
+- +
+In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
--+constexpr error_code(int val, const error_category-&* cat); --Effects: Constructs an object of type error_code. -
--Postconditions: val_ == val and cat_ == cat. -
-Throws: Nothing. -
- +
-Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: +In 21.4.5 [string.access] replace p. 1 by the following 4 paragraghs:
--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: +Requires: pos ≤ size().
- ---const error_category-&* category() const; --Returns: cat_. +Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns +a reference to a charT() that shall not be modified.
Throws: Nothing.
--Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview as indicated: +Complexity: Constant time.
- --+class error_condition { -public: - ...; - constexpr error_condition(int val, const error_category&* cat); - ... - void assign(int val, const error_category&* cat); - ... - const error_category&* category() const; - ... -private: - int val_; // exposition only - const error_category&* cat_; // exposition only -- +
-Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: +In 21.4.7.1 [string.accessors] replace the now common returns +clause of c_str() and data() by the following three paragraphs:
--- -constexpr error_condition(int val, const error_category-&* cat); --Effects: Constructs an object of type error_condition. -
-Postconditions: val_ == val and cat_ == cat. +Returns: A pointer p such that p+i == &operator[](i) for each i +in [0, size()].
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. +Complexity: Constant time.
- +
++
+- +
-Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +In 21.4.5 [string.access] replace p.2 and p.3 by:
--+const error_category&* category() const; --Returns: cat_. +Requires: pos ≤ size()
-Throws: Nothing. +Throws: out_of_range if pos > size().
-Throughout 19.4 [syserr] System error support, change "category()." to "category()->". -Appears approximately six times. -
--[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, -paragraphs 2 and 4, change "category.equivalent(" to -"category()->equivalent(". -
--Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: -
--public: - system_error(error_code ec, const string& what_arg); - system_error(error_code ec); - system_error(int ev, const error_category&* ecat, - const string& what_arg); - system_error(int ev, const error_category&* ecat); --Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: -
--+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. + +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. -
-
+877. to throw() or to Throw: Nothing.
+Section: 17 [library] Status: Open + Submitter: Martin Sebor Opened: 2008-08-23 Last modified: 2008-09-18
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
+-
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. -
-+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. +
+-
-833. Freestanding implementations header list needs review for C++0x
-Section: 17.4.1.3 [compliance] Status: Open - Submitter: Beman Dawes Date: 2008-05-14
-View all issues with Open status.
-Discussion:
--Once the C++0x standard library is feature complete, the LWG needs to -review 17.4.1.3 [compliance] Freestanding implementations header list to -ensure it reflects LWG consensus. -
- - -Proposed resolution:
- - - - - -
-834. Unique_ptr::pointer requirements underspecified
-Section: 20.7.11.2 [unique.ptr.single] Status: Open - Submitter: Daniel Krügler Date: 2008-05-14
-View all issues with Open status.
-Discussion:
--Issue 673 (including recent updates by 821) proposes a useful -extension point for unique_ptr by granting support for an optional -deleter_type::pointer to act as pointer-like replacement for element_type* -(In the following: pointer). -
--Unfortunately no requirements are specified for the type pointer which has -impact on at least two key features of unique_ptr: -
- --
- -- Operational fail-safety.
-- (Well-)Definedness of expressions.
--Unique_ptr specification makes great efforts to require that essentially *all* -operations cannot throw and therefore adds proper wording to the affected -operations of the deleter as well. If user-provided pointer-emulating types -("smart pointers") will be allowed, either *all* throw-nothing clauses have to -be replaced by weaker "An exception is thrown only if pointer's {op} throws -an exception"-clauses or it has to be said explicitly that all used -operations of -pointer are required *not* to throw. I understand the main focus of unique_ptr -to be as near as possible to the advantages of native pointers which cannot -fail and thus strongly favor the second choice. Also, the alternative position -would make it much harder to write safe and simple template code for -unique_ptr. Additionally, I assume that a general statement need to be given -that all of the expressions of pointer used to define semantics are required to -be well-formed and well-defined (also as back-end for 762). -
- -[ -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.7.11.2 [unique.ptr.single]/p. 3: -
- --unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well -defined behavior, and shall not throw exceptions. -- - - - - -
-835. tying two streams together (correction to DR 581)
-Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17
-View other active issues in [basic.ios.members].
-View all other issues in [basic.ios.members].
-View all issues with New status.
-Discussion:
-- -The fix for -issue 581, -now integrated into the working paper, overlooks a couple of minor -problems. +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, being an unformatted function once again,
flush()
-is required to create a sentry object whose constructor must, among -other things, flush the tied stream. When two streams are tied -together, either directly or through another intermediate stream -object, flushing one will also cause a call toflush()
on -the other tied stream(s) and vice versa, ad infinitum. The program -below demonstrates the problem. +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.-Second, as Bo Persson notes in his -comp.lang.c++.moderated post, -for streams with the
unitbuf
flag set such -asstd::stderr
, the destructor of the sentry object will -again callflush()
. This seems to create an infinite -recursion forstd::cerr << std::flush;
+For example, given the following definition of +the std::uninitialized_copy function template and a +user-defined type SomeType:-- -#include <iostream> - -int main () +template <class InputIterator, class ForwardIterator> +ForwardIterator +uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) { - std::cout.tie (&std::cerr); - std::cerr.tie (&std::cout); - std::cout << "cout\n"; - std::cerr << "cerr\n"; -} --Proposed resolution:
-+ typedef iterator_traits<ForwardIterator>::value_type ValueType; -I think an easy way to plug the first hole is to add a requires clause -to
+ 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 (); +} +ostream::tie(ostream *tiestr)
requiring the this -pointer not be equal to any pointer on the list starting -withtiestr->tie()
-throughtiestr()->tie()->tie()
and so on. I am not -proposing that we require implementations to traverse this list, -although I think we could since the list is unlikely to be very long. + ForwardIterator start = res; --Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following -text: +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); -Requires: If(tiestr != 0)
is -true,tiestr
must not be reachable by traversing the -linked list of tied stream objects starting -fromtiestr->tie()
. - + return res; +}-In addition, to prevent the infinite recursion that Bo writes about in -his comp.lang.c++.moderated post, I propose to change -27.6.2.4 [ostream::sentry], p2 like so: +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.
-+- + +-If
((os.flags() & ios_base::unitbuf) && -!uncaught_exception())
is true, -callsos.flush()os.rdbuf()->pubsync()
. +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];-
-836. - effects of
-money_base::space
and -money_base::none
onmoney_get
-Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New - Submitter: Martin Sebor Date: 2008-05-17
-View other active issues in [locale.money.get.virtuals].
-View all other issues in [locale.money.get.virtuals].
-View all issues with New status.
-Duplicate of: 670
-Discussion:
+-In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: +the compiler generates the following code for the first statement:
- -Wherespace
ornone
appears in the format -pattern, except at the end, optional white space (as recognized -byct.is
) is consumed after any required space. - +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; +}-This requirement can be (and has been) interpreted two mutually -exclusive ways by different readers. One possible interpretation -is that: +but it is can generate much more compact code for the second statement:
-+-
- - -where
money_base::space
appears in the format, at least -one space is required, and +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. -where - -money_base::none
appears in the format, space is -allowed but not required. + +-
-The other is that: +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.
-+- + ++
+
- -where either
money_base::space
ormoney_base::none
appears in the format, white space is optional. +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. -+ +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. + + ++ +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. + + + + ++ +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:
-I propose to change the text to make it clear that the first -interpretation is intended, that is, to make following change to -22.2.6.1.2 [locale.money.get.virtuals], p2: +We propose two possible solutions. Our recommendation is to adopt +Option 1 below.
+-
+Option 1: -When+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." + + +money_base::space
-ormoney_base::none
appears as the last -element in the format pattern,except at the end, optional -white space (as recognized byno white space is consumed. Otherwise, -wherect.is
) is consumed after -any required space.money_base::space
appears in any of the initial -elements of the format pattern, at least one white space character is -required. Wheremoney_base::none
appears in any of the -initial elements of the format pattern, white space is allowed but not -required. In either case, any required followed by all optional white -space (as recognized byct.is()
) is consumed. -If(str.flags() & str.showbase)
isfalse
, ... + +-
+ +Option 2: + +
++ +For consistency, replace all occurrences of the empty exception +specification with a "Throws: Nothing." clause. + +
-837. -
-basic_ios::copyfmt()
overly loosely specified -Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17
-View other active issues in [basic.ios.members].
-View all other issues in [basic.ios.members].
-View all issues with New status.
+878. forward_list preconditions
+Section: 23.3.3 [forwardlist] Status: Tentatively Ready + Submitter: Martin Sebor Opened: 2008-08-23 Last modified: 2009-05-10
+View all issues with Tentatively Ready status.
Discussion:
-+
-The
-basic_ios::copyfmt()
member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: +forward_list member functions that take +a forward_list::iterator (denoted position in the +function signatures) argument have the following precondition: -+ ++-Effects: If+(this == &rhs)
does -nothing. Otherwise assigns to the member objects of*this
-the corresponding member objects ofrhs
, except that +Requires: position is dereferenceable or equal +to before_begin(). --
- +
-
rdstate()
andrdbuf()
are left unchanged; +I believe what's actually intended is this: - -+ + --exceptions()
is altered last by -callingexceptions(rhs.except)
+Requires: position is in the range +[before_begin(), end()). -+ -the contents of arrays pointed at by
pword
-andiword
are copied not the pointers themselves +That is, when it's dereferenceable, position must point +into *this, not just any forward_list object. - - -
+
-Since the rest of the text doesn't specify what the member objects -ofbasic_ios
are this seems a little too loose.
+[ +San Francisco: +]
- - -Proposed resolution:
-+
+Robert suggested alternate proposed wording which had large support. +-I propose to tighten things up by adding a Postcondition clause -to the function like so: +
[ +Post Summit: +]
- -- Postconditions: --- -
-- -- copyfmt()
postconditions- - - -Element -Value -- -- rdbuf()
unchanged -- -- tie()
- rhs.tie()
- -- rdstate()
unchanged -- -- exceptions()
- rhs.exceptions()
- -- flags()
- rhs.flags()
- -- width()
- rhs.width()
- -- precision()
- rhs.precision()
- -- fill()
- rhs.fill()
- - -- getloc()
- rhs.getloc()
-
-The format of the table follows Table 117 (as
-of N2588): basic_ios::init()
-effects.
-
-
+
+-The intent of the new table is not to impose any new requirements or -change existing ones, just to be more explicit about what I believe is -already there. - - ++Walter: "position is before_begin() or a dereferenceable": add "is" after the "or" +
++With that minor update, Recommend Tentatively Ready. +
+
Proposed resolution:
++Change the Requires clauses + [forwardlist] , p21, p24, p26, p29, and, +23.3.3.5 [forwardlist.ops], p39, p43, p47 +as follows: -
Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-05-17
-View other active issues in [istream.iterator].
-View all other issues in [istream.iterator].
-View all issues with New status.
-Discussion:
-+
+-From message c++std-lib-20003... +Requires: position is before_begin() or is a +dereferenceable +iterator in the range [begin(), end()) ++ -The description ofor equal to before_begin(). ... - -+
istream_iterator
in
-24.5.1 [istream.iterator], p1 specifies that objects of the
-class become the end-of-stream (EOS) iterators under the
-following condition (see also issue 836 another problem
-with this paragraph):
-
- -If the end of stream is reached (-operator void*()
on the -stream returnsfalse
), the iterator becomes equal to -the end-of-stream iterator value. +
+879. Atomic load const qualification
+Section: 29 [atomics] Status: Review + Submitter: Alexander Chemeris Opened: 2008-08-24 Last modified: 2009-03-22
+View other active issues in [atomics].
+View all other issues in [atomics].
+View all issues with Review status.
+Discussion:
++The atomic_address type and atomic<T*> specialization provide atomic +updates to pointers. However, the current specification requires +that the types pointer be to non-const objects. This restriction +is unnecessary and unintended. +
-
+
[ +Summit: +]
-One possible implementation approach that has been used in practice is -for the iterator to set itsin_stream
pointer to 0 when
-it reaches the end of the stream, just like the default ctor does on
-initialization. The problem with this approach is that
-the Effects clause for operator++()
says the
-iterator unconditionally extracts the next value from the stream by
-evaluating *in_stream >> value
, without checking
-for (in_stream == 0)
.
++Move to review. Lawrence will first check with Peter whether the +current examples are sufficient, or whether they need to be expanded to +include all cases. +- -
-Conformance to the requirement outlined in the Effects clause
-can easily be verified in programs by setting eofbit
-or failbit
in exceptions()
of the associated
-stream and attempting to iterate past the end of the stream: each
-past-the-end access should trigger an exception. This suggests that
-some other, more elaborate technique might be intended.
+
Proposed resolution:
++Add const qualification to the pointer values of the atomic_address +and atomic<T*> specializations. E.g. +
+ +- -typedef struct atomic_address { + void store(const void*, memory_order = memory_order_seq_cst) volatile; + void* exchange( const void*, memory_order = memory_order_seq_cst) volatile; + bool compare_exchange( const void*&, const void*, + memory_order, memory_order) volatile; + bool compare_exchange( const void*&, const void*, + memory_order = memory_order_seq_cst ) volatile; + void* operator=(const void*) volatile; +} atomic_address; + +void atomic_store(volatile atomic_address*, const void*); +void atomic_store_explicit(volatile atomic_address*, const void*, + memory_order); +void* atomic_exchange(volatile atomic_address*, const void*); +void* atomic_exchange_explicit(volatile atomic_address*, const void*, + memory_order); +bool atomic_compare_exchange(volatile atomic_address*, + const void**, const void*); +bool atomic_compare_exchange_explicit(volatile atomic_address*, + const void**, const void*, + memory_order, memory_order); +
-Another approach, one that allows operator++()
to attempt
-to extract the value even for EOS iterators (just as long
-as in_stream
is non-0) is for the iterator to maintain a
-flag indicating whether it has reached the end of the stream. This
-technique would satisfy the presumed requirement implied by
-the Effects clause mentioned above, but it isn't supported by
-the exposition-only members of the class (no such flag is shown). This
-approach is also found in existing practice.
-
-The inconsistency between existing implementations raises the question
-of whether the intent of the specification is that a non-EOS iterator
-that has reached the EOS become a non-EOS one again after the
-stream's eofbit
flag has been cleared? That is, are the
-assertions in the program below expected to pass?
-
--sstream strm ("1 "); - istream_iterator eos; - istream_iterator it (strm); - int i; - i = *it++ - assert (it == eos); - strm.clear (); - strm << "2 3 "; - assert (it != eos); - i = *++it; - assert (3 == i); --
+
Section: 29 [atomics] Status: Open + Submitter: Lawrence Crowl Opened: 2008-08-24 Last modified: 2009-03-22
+View other active issues in [atomics].
+View all other issues in [atomics].
+View all issues with Open status.
+Duplicate of: 942
+Discussion:
++The atomic_exchange and atomic_exchange_explicit functions seem to +be inconsistently missing parameters. +
-Or is it intended that once an iterator becomes EOS it stays EOS until -the end of its lifetime? +[ +Post Summit: +]
- - -Proposed resolution:
-+
+-The discussion of this issue on the reflector suggests that the intent -of the standard is for an+Lawrence: Need to write up a list for Pete with details. +
++Detlef: Should not be New, we already talked about in Concurrency group. +
++Recommend Open. +
+
istreambuf_iterator
that has
-reached the EOS to remain in the EOS state until the end of its
-lifetime. Implementations that permit EOS iterators to return to a
-non-EOS state may only do so as an extension, and only as a result of
-calling istream_iterator
member functions on EOS
-iterators whose behavior is in this case undefined.
-
- +
Proposed resolution:
++Add the appropriate parameters. For example, +
-To this end we propose to change 24.5.1 [istream.iterator], p1, -as follows: +- -bool atomic_exchange(volatile atomic_bool*, bool); +bool atomic_exchange_explicit(volatile atomic_bool*, bool, memory_order); +
-The result of operator-> on an end-of-stream -is not defined. For any other iterator value a-const T*
-is returned. Invokingoperator++()
on -an end-of-stream iterator is undefined. It is impossible -to store things into istream iterators... -
-Add pre/postconditions to the member function descriptions of istream_iterator
like so:
-
+-
+881. shared_ptr conversion issue
+Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Open + Submitter: Peter Dimov Opened: 2008-08-30 Last modified: 2008-09-18
+View other active issues in [util.smartptr.shared.const].
+View all other issues in [util.smartptr.shared.const].
+View all issues with Open status.
+Discussion:
++We've changed shared_ptr<Y> to not convert to shared_ptr<T> when Y* +doesn't convert to T* by resolving issue 687. This only fixed the +converting copy constructor though. +N2351 +later added move support, and +the converting move constructor is not constrained. +
-istream_iterator();+[ +San Francisco: +]
-Effects: Constructs the end-of-stream iterator.
-Postcondition:in_stream == 0
. -istream_iterator(istream_type &s);++We might be able to move this to NAD, Editorial once shared_ptr is +conceptualized, but we want to revisit this issue to make sure. +-Effects: Initializesin_stream
with &s. value -may be initialized during construction or the first time it is -referenced.
-Postcondition:in_stream == &s
. -istream_iterator(const istream_iterator &x);+Proposed resolution:
++We need to change the Requires clause of the move constructor: +
-Effects: Constructs a copy ofx
.
-Postcondition:in_stream == x.in_stream
. +-shared_ptr(shared_ptr&& r); +template<class Y> shared_ptr(shared_ptr<Y>&& r); +++Requires:+For the second constructor Y* shall be +convertible to T*.+ +The second constructor shall not participate in overload resolution +unless Y* is convertible to T*. + +istream_iterator& operator++();++in order to actually make the example in 687 compile +(it now resolves to the move constructor). +
-Requires:in_stream != 0
.
-Effects:*in_stream >> value
. -istream_iterator& operator++(int);-Requires:in_stream != 0
.
-Effects: --istream_iterator tmp (*this); -*in_stream >> value; -return tmp; --
Section: 23.3 [associative], 23.4 [unord] Status: Open - Submitter: Alan Talbot Date: 2008-05-18
+Section: 23 [containers] Status: Open + Submitter: Alisdair Meredith Opened: 2008-09-10 Last modified: 2009-03-11
+View other active issues in [containers].
+View all other issues in [containers].
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: +Note in particular that Table 90 "Container Requirements" gives +semantics of a.swap(b) as swap(a,b), yet for all +containers we define swap(a,b) to call a.swap(b) - a +circular definition.
--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); -
[ +San Francisco: +]
--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); -
+Robert to propose a resolution along the lines of "Postcondition: "a = +b, b = a" This will be a little tricky for the hash containers, since +they don't have operator==. +
[ -Sophia Antipolis: +Post Summit Anthony Williams provided proposed wording. ]
-+ + ++Proposed resolution:
-Don't try to splice "list" into the other containers, it should be container-type. +In table 80 in section 23.2.1 [container.requirements.general], +replace the postcondition of a.swap(b) with the following:
--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. -
-
+++
+Table 80 -- Container requirements ++ +Expression +Return type +Operational semantics +Assertion/note pre-/post-conidtion +Complexity ++ +... +... +... +... +... ++ +a.swap(b); +void ++ + swap(a,b)+Exchange the contents of a and b as-if
+X u=std::move(a);
+a=std::move(b);
+b=std::move(u);(Note A) +
+Remove the reference to swap from the paragraph following the table. +
-Proposed resolution:
++Notes: the algorithmsswap(),equal() and +lexicographical_compare() are defined in Clause 25. ... +
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.
+Section: 20.8.13.2.4 [util.smartptr.shared.mod] Status: Tentatively NAD Editorial + Submitter: Jonathan Wakely Opened: 2008-09-15 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial 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 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#include <memory> +#include <cassert> -In cstdint.syn Header<cstdint>
-synopsis, C++ on the other hand, fixes the value -ofN
to 8, 16, 32, and 64, and specifies only -types with these exact widths. +struct A { }; +struct B : A { }; - --
+int main() +{ + std::shared_ptr<A> pa(new A); + std::shared_ptr<B> pb(new B); + std::swap<A>(pa, pb); // N.B. no argument deduction + assert( pa.get() == pb.get() ); + return 0; +} +
INT_8_MIN
that are not intended to be specified.
++Is this behaviour correct (I believe it is) and if so, is it +unavoidable, or not worth worrying about? +
-+
+This calls the lvalue/rvalue swap overload for shared_ptr: +
-Finally, the section is missing the usual table of symbols defined -in that header, making it inconsistent with the rest of the -specification. +- - -template<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b ); +
Proposed resolution:
-+
+silently converting the second argument from shared_ptr<B> to +shared_ptr<A> and binding the rvalue ref to the produced temporary. +
-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 symbolN
to denote one or
-more of a theoretically unbounded set of widths.
++This is not, in my opinion, a shared_ptr problem; it is a general issue +with the rvalue swap overloads. Do we want to prevent this code from +compiling? If so, how? +
- -+
+Perhaps we should limit rvalue args to swap to those types that would +benefit from the "swap trick". Or, since we now have shrink_to_fit(), just +eliminate the rvalue swap overloads altogether. The original motivation +was: +
-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. +- -vector<A> v = ...; +... +swap(v, vector<A>(v)); +
+N1690.
-To this effect, in cstdint.syn
-Header <cstdint>
synopsis, replace both the
-synopsis and paragraph 1 with the following text:
+
[ +Batavia (2009-05): +]
- ----
-
- -- - -In the names defined in the
-<cstdint>
header, the -symbolN
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 -ofN
in the set of 8, 16, 32, and 64 are -required. Exact-width types, and any macros and types for values -ofN
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. - -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; +-+We agree with the proposed resolution. +Move to NAD Editorial. +-}
-[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] +
Proposed resolution:
++Recommend NAD Editorial, fixed by +N2844. +
- -- Table ??: Header-<cstdint>
synopsis -- -
-- - - -Type -Name(s) -- -Macros: -INTN_MIN -INTN_MAX -UINTN_MAX -- -INT_FASTN_MIN -INT_FASTN_MAX -UINT_FASTN_MAX -- -INT_LEASTN_MIN -INT_LEASTN_MAX -UINT_LEASTN_MAX -- -INTPTR_MIN -INTPTR_MAX -UINTPTR_MAX -- -INTMAX_MIN -INTMAX_MAX -UINTMAX_MAX -- -PTRDIFF_MIN -PTRDIFF_MAX -PTRDIFF_MAX -- -SIG_ATOMIC_MIN -SIG_ATOMIC_MAX -SIZE_MAX -- -WCHAR_MIN -WCHAR_MAX -- - -WINT_MIN -WINT_MAX -- - -INTN_C() -UINTN_C() -- - -INTMAX_C() -UINTMAX_C() -- - -Types: -intN_t -uintN_t -- - -int_fastN_t -uint_fastN_t -- - -int_leastN_t -uint_leastN_t -- - -intptr_t -uintptr_t -- - - -intmax_t -uintmax_t --
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.
+Section: 20.3.3 [pairs] Status: Open + Submitter: Alisdair Meredith Opened: 2008-09-15 Last modified: 2009-05-25
+View other active issues in [pairs].
+View all other issues in [pairs].
+View all issues with Open status.
Discussion:
++20.2.3 pairs +Missing assignemnt operator: +template<class U , class V> + requires CopyAssignable<T1, U> && CopyAssignable<T2, V> + pair& operator=(pair<U , V> const & p ); +
-23.1 [container.requirements]/p3 says: +Well, that's interesting. This assignment operator isn't in the +current working paper, either. Perhaps we deemed it acceptable to +build a temporary of type pair from pair<U, V>, then move-assign +from that temporary?
- --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. +It sounds more like an issue waiting to be opened, unless you want to plug +it now. As written we risk moving from lvalues.
+[ +San Francisco: +]
-Proposed resolution:
+ +++ ++Would be NAD if better ctors fixed it. +
-Change 23.1 [container.requirements]/p3: +Related to 811.
+
[ +post San Francisco: +]
+-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] +Possibly NAD Editorial, solved by +N2770.-
-Change 23.2.7 [vector.bool]/p2: -
+[ +2009-05-25 Alisdair adds: +]
+-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. +Issue 885 was something I reported while reviewing the library concepts +documents ahead of San Francisco. The missing operator was added as part of +the paper adopted at that meeting +(N2770) +and I can confirm this operator is +present in the current working paper. I recommend NAD.+ + +
Proposed resolution:
-Move 23.3.5 [template.bitset] to clause 20.
-Section: 20.6.17.1 [func.referenceclosure.cons] Status: New - Submitter: Lawrence Crowl Date: 2008-06-02
-View all issues with New status.
+Section: 20.5.2.1 [tuple.cnstr] Status: Open + Submitter: Alisdair Meredith Opened: 2008-09-15 Last modified: 2009-05-05
+View other active issues in [tuple.cnstr].
+View all other issues in [tuple.cnstr].
+View all issues with Open 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. +20.5.2.1 [tuple.cnstr]: +
++Effects: Default initializes each element. ++ +
+Could be clarified to state each "non-trivial" element. Otherwise +we have a conflict with Core deinfition of default initialization - +trivial types do not get initialized (rather than initialization +having no effect) +
+ ++I'm going to punt on this one, because it's not an issue that's +related to concepts. I suggest bringing it to Howard's attention on +the reflector.
+ +[ +San Francisco: +]
+ + ++-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. +Text in draft doesn't mean anything, changing to "non-trivial" makes it +meaningful.
-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. +We prefer "value initializes". Present implementations use +value-initialization. Users who don't want value initialization have +alternatives.
-The semantics of assignment are effectively obtained by use of the -default destructor and default copy assignment operator via +Request resolution text from Alisdair.
--x.~reference_closure(); new (x) reference_closure(y); --So the copy assignment operator generates no significant real burden -to the implementation. +This issue relates to Issue 868 default construction and value-initialization.
+
[ +2009-05-04 Alisdair provided wording and adds: +]
-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. +Note: This IS a change of semantic from TR1, although one the room agreed +with during the discussion. To preserve TR1 semantics, this would have been +worded:
+-requires DefaultConstructible<Types>... tuple(); +++-2- Effects: Default-initializes each non-trivial element. +++template<class R , class... ArgTypes > - class reference_closure<R (ArgTypes...)> { - public: - ... - reference_closure& operator=(const reference_closure&) =deletedefault; - ... -
Proposed resolution:
-In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, -add the member function description +Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
--reference_closure& operator=(const reference_closure& f) +@@ -16797,127 +15997,157 @@ add the member function description -requires DefaultConstructible<Types>... tuple();-Postcondition: *this is a copy of f. -
--Returns: *this. +-2- Effects:
DefaultValue-initializes each element.
-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.
+887. issue with condition::wait_...
+Section: 30.5.1 [thread.condition.condvar] Status: Open + Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2009-03-09
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Open status.
Discussion:
-The current working draft is in an inconsistent state. +The Posix/C++ working group has identified an inconsistency between +Posix and the C++ working draft in that Posix requires the clock to be +identified at creation, whereas C++ permits identifying the clock at the +call to wait. The latter cannot be implemented with the former. +
+ +[ +San Francisco: +]
+ + +++Howard recommends NAD with the following explanation:
-26.3.8 [complex.transcendentals] says that: +The intent of the current wording is for the condtion_variable::wait_until +be able to handle user-defined clocks as well as clocks the system knows about. +This can be done by providing overloads for the known clocks, and another +overload for unknown clocks which synchs to a known clock before waiting. +For example:
--pow(complex<float>(), int()) returns a complex<float>. -+template <class Duration> +bool +condition_variable::wait_until(unique_lock<mutex>& lock, + const chrono::time_point<chrono::system_clock, Duration>& abs_time) +{ + using namespace chrono; + nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch()); + __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d)); + return system_clock::now() < abs_time; +} + +template <class Clock, class Duration> +bool +condition_variable::wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time) +{ + using namespace chrono; + typename Clock::time_point c_entry = Clock::now(); + system_clock::time_point s_entry = system_clock::now(); + nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() - + c_entry.time_since_epoch()); + __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn); + return Clock::now() < abs_time; +} +-26.3.9 [cmplx.over] says that: +In the above example, system_clock is the only clock which the underlying +condition variable knows how to deal with. One overload just passes that clock +through. The second overload (approximately) converts the unknown clock into +a system_clock time_point prior to passing it down to the native +condition variable.
--pow(complex<float>(), int()) returns a complex<double>. ++On Posix systems vendors are free to add implementation defined constructors which +take a clock. That clock can be stored in the condition_variable, and converted +to (or not as necessary) as shown above. +
+ ++If an implementation defined constructor takes a clock (for example), then part +of the semantics for that implementation defined ctor might include that a +wait_until using a clock other than the one constructed with results +in an error (exceptional condition) instead of a conversion to the stored clock. +Such a design is up to the vendor as once an implementation defined ctor is used, +the vendor is free to specifiy the behavior of waits and/or notifies however +he pleases (when the cv is constructed in an implementation defined manner). +
[ -Sophia Antipolis: +Post Summit: ]
-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. +"POSIX people will review the proposed NAD resolution at their upcoming NY +meeting.
+-Special note: ask P.J. Plauger. +See the minutes at: http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009.
--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.
+888. this_thread::yield too strong
+Section: 30.3.2 [thread.thread.this] Status: Tentatively Ready + Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2009-03-09
+View all issues with Tentatively Ready 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'. +I never thought I'd say this, but this_thread::yield seems to be too +strong in specification. The issue is that some systems distinguish +between yielding to another thread in the same process and yielding +to another process. Given that the C++ standard only talks about +a single program, one can infer that the specification allows yielding +only to another thread within the same program. Posix has no +facility for that behavior. Can you please file an issue to weaken +the wording. Perhaps "Offers the operating system the opportunity +to reschedule."
[ -Jens adds: +Post Summit: ]
-+-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: -
-- +Recommend move to Tentatively Ready.atomic_itype a2 { 6 }; -Proposed resolution:
-In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: +Change 30.3.2 [thread.thread.this]/3:
-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.+void this_thread::yield(); +++Effects: Offers the- -operating systemimplementation +the opportunity to reschedule. +another thread.[ -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.@@ -16925,121 +16155,134 @@ 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.
+889. thread::id comparisons
+Section: 30.3.1.1 [thread.thread.id] Status: Open + Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2009-05-24
+View all other issues in [thread.thread.id].
+View all issues with Open 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. -
+Addresses UK 324
-Proposed resolution:
+The thread::id type supports the full set of comparison operators. This +is substantially more than is required for the associative containers that +justified them. Please place an issue against the threads library.
+[ +San Francisco: +]
- - -
-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: +Would depend on proposed extension to POSIX, or non-standard extension. +What about hash? POSIX discussing op. POSIX not known to be considering +support needed for hash, op.
- --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: +Group expresses support for putting ids in both unordered and ordered containers.
+[ +post San Francisco: +]
++-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: +Howard: It turns out the current working paper +N2723 +already has hash<thread::id> +(20.7 [function.objects], 20.7.17 [unord.hash]). We simply +overlooked it in the meeting. It is a good thing we voted in favor of it +(again). :-) +
++Recommend NAD.
--
- if an exception is thrown by...
-[ +Post Summit: +]
+ + ++Recommend to close as NAD. For POSIX, see if we need to add a function to +convert pthread_t to integer. ++ +[ +Post Summit, Alisdair adds: +]
+ + +-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. +The recommendation for LWG-889/UK-324 is NAD, already specified.
--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. +It is not clear to me that the specification is complete.
--The reaction in that group by Niels Dekker, Martin Sebor, and -Bo Persson, was all that this would be worth an LWG issue. +In particular, the synopsis of <functional> in 20.7 [function.objects] does not mention hash< thread::id +> nor hash< error_code >, although their +existence is implied by 20.7.17 [unord.hash], p1.
--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). +I am fairly uncomfortable putting the declaration for the +thread_id specialization into <functional> as +id is a nested class inside std::thread, so it implies +that <functional> would require the definition of the +thread class template in order to forward declared +thread::id and form this specialization.
- - - -Proposed resolution:
-Add a blanket statement in 21.3.1 [string.require]: +It seems better to me that the dependency goes the other way around +(<thread> will more typically make use of +<functional> than vice-versa) and the +hash<thread::id> specialization be declared in the +<thread> header.
- -+-- if any member function or operator of basic_string<charT, traits, Allocator> -throws, that function or operator has no effect. +I think hash<error_code> could go into either +<system_error> or <functional> and have no +immediate preference either way. However, it should clearly appear in +the synopsis of one of these two.
-- no erase() or pop_back() function throws. +Recommend moving 889 back to open, and tying in a reference to UK-324.
[ +Batavia (2009-05): +]
+ ++Howard observes that thread::id need not be a nested class; +it could be a typedef for a more visible type. ++ +[ +2009-05-24 Alisdair adds: +]
+ ++I do not believe this is correct. thread::id is explicitly documents as a +nested class, rather than as an unspecified typedef analogous to an +iterator. If the intent is that this is not implemented as a nested class +(under the as-if freedoms) then this is a novel form of standardese. ++ + +Proposed resolution:
-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. +Move to NAD.
@@ -17047,283 +16290,407 @@ 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.
+890. Improving <system_error> initialization
+Section: 19.5.1 [syserr.errcat] Status: Tentatively Ready + Submitter: Beman Dawes Opened: 2008-09-14 Last modified: 2009-03-09
+View all issues with Tentatively 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. +The static const error_category objects generic_category and +system_category in header <system_error> are currently declared:
+-const error_category& get_generic_category(); +const error_category& get_system_category(); -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>>; +static const error_category& generic_category = get_generic_category(); +static const error_category& system_category = get_system_category();-Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: +This formulation has several problems:
--... and std::string, std::u16string, std::u32string, std::wstring, -std::error_code, std::thread::id, std::bitset, and std::vector<bool>. -- ++
+- +Implementation details are exposed, since initialization is specified in +the interface. This over-constrains implementations without offsetting +user benefits. The form of initialization specified may be less than +maximally efficient on some platforms. +
+- +Use of the objects is more expensive in terms of number of machine level +instructions. See Implementation experience below. +
+- +Depending on the compiler, some cost may be incurred by each translation unit +that includes the header, even if the objects are not used. This is a +common scenario in user code, since the header is included by other +standard library headers. It should be mentioned that at least one +compilers is able to optimize this cost away, however. +
++IO streams uses a somewhat different formulation for iostream_category, but +still suffer much the same problems. +
++The original plan was to eliminate these problems by applying the C++0x +constexpr feature. See LWG issue 832. However, that approach turned out +to be unimplementable, since it would require a constexpr object of a +class with virtual functions, and that is not allowed by the core +language. +
++The proposed resolution was developed as an alternative. It mitigates the above +problems by removing initialization from the visible interface, allowing +implementations flexibility. +
++Implementation experience: +
-
-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. +Prototype implementations of the current WP interface and proposed +resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft +compilers on Windows. The code generated by the Microsoft compiler was studied +at length; the WP and proposal versions generated very similar code. For both versions +the compiler did make use of static +initialization; apparently the compiler applied an implicit constexpr +where useful, even in cases where constexpr would not be permitted by +the language!
-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. +Acknowledgements:
-If the computation can not be done, the traits should fall back on an -identity transformation. I expect this gives the best overall usability. +Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
+[ +San Francisco: +]
+ -Proposed resolution:
++ + +-Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": +Martin: prefers not to create more file-scope static objects, and would +like to see get_* functions instead.
+[Pre-Summit:]
+ +--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 +Beman: The proposed resolution has been reworked to remove the file-scope +static objects, per Martin's suggestions. The get_ prefix has been +eliminated from the function names as no longer necessary and to conform with +standard library naming practice.
--+-
- -Template Condition Comments -- -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. -[ +Post Summit: +]
++Agreement that this is wise and essential, text provided works and has +been implemented. Seems to be widespread consensus. Move to Tentative Ready. +-
-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:
+Proposed resolution:
+ +Change 17.6.4.12 [value.error.codes] Value of error codes as indicated:
+++Certain functions in the C++ standard library report errors via a + std::error_code (19.4.2.2) object. That object's category() member shall + return
+a reference tostd::system_category
()
for errors originating from the + operating system, or a reference to an implementation-defined error_category + object for errors originating elsewhere. The implementation shall define the + possible values of value() for each of these error categories. [Example: For + operating systems that are based on POSIX, implementations are encouraged to + define thestd::system_category
()
values as identical to the POSIX errno values, + with additional values as defined by the operating system's documentation. + Implementations for operating systems that are not based on POSIX are + encouraged to define values identical to the operating system's values. For + errors that do not originate from the operating system, the implementation may + provide enums for the associated values --end example]-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. +Change 19.5.1.1 [syserr.errcat.overview] Class error_category overview +error_category synopsis as indicated:
+ +++const error_category&+get_generic_category(); +const error_category&get_system_category(); + +static storage-class-specifier const error_category& generic_category = get_generic_category(); +static storage-class-specifier const error_category& system_category = get_system_category();+-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. +Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
+ +++ + +const error_category&+ +get_generic_category(); +++-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. +Returns: A reference to an object of a type derived from class error_category.
+-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. +Remarks: The object's default_error_condition and equivalent virtual +functions shall behave as specified for the class error_category. The +object's name virtual function shall return a pointer to the string +"GENERIC".
+const error_category&-get_system_category(); +Proposed resolution:
++-To Class template deque 23.2.2 [deque] synopsis, add: +Returns: A reference to an object of a type derived from class error_category.
-void shrink_to_fit(); --To deque capacity 23.2.2.2 [deque.capacity], add: +Remarks: The object's equivalent virtual functions shall behave as +specified for class error_category. The object's name virtual function +shall return a pointer to the string "system". The object's +default_error_condition virtual function shall behave as follows:
-+ +void shrink_to_fit(); -++If the argument ev corresponds to a POSIX errno value posv, the function +shall return error_condition(posv, generic_category()). Otherwise, the +function shall return error_condition(ev, system_category()). What +constitutes correspondence for any given operating system is +unspecified. [Note: The number of potential system error codes is large +and unbounded, and some may not correspond to any POSIX errno value. +Thus implementations are given latitude in determining correspondence. +-- end note] ++Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors +as indicated:
+++error_code();+++Effects: Constructs an object of type error_code.
+Postconditions:
+val_ == 0
andcat_ == &system_category
().Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as +indicated:
+++void clear();+++Postconditions:
+value() == 0
andcategory() == + system_category
().Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member +functions as indicated:
+++error_code make_error_code(errc e);+++Returns:
+error_code(static_cast<int>(e), generic_category
())
.Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition +constructors as indicated:
+++error_condition();+++Effects: Constructs an object of type
+error_condition
.Postconditions:
+val_ == 0
andcat_ == &generic_category
().Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition +modifiers as indicated:
-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] ++void clear();++Postconditions:
+value() == 0
andcategory() == + generic_category
().Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition +non-member functions as indicated:
+++error_condition make_error_condition(errc e);+++Returns: error_condition(static_cast<int>(e), generic_category()).
+Change 27.5 [iostreams.base] Iostreams base classes, Header <ios> + synopsis as indicated:
+++concept_map ErrorCodeEnum<io_errc> { }; +error_code make_error_code(io_errc e); +error_condition make_error_condition(io_errc e); ++storage-class-specifierconst error_category& iostream_category();Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as +indicated:
+++When throwing ios_base::failure exceptions, implementations should provide +values of ec that identify the specific reason for the failure. [ Note: Errors +arising from the operating system would typically be reported as +system_category() errors with an error value of the +error number reported by the operating system. Errors arising from within the +stream library would typically be reported as error_code(io_errc::stream, +iostream_category()). --end note ]
+Change 27.5.5.5 [error.reporting] Error reporting as indicated:
+++ +error_code make_error_code(io_errc e);+++Returns:
+error_code(static_cast<int>(e), iostream_category
())
.error_condition make_error_condition(io_errc e);+++Returns:
+error_condition(static_cast<int>(e), + iostream_category
())
.+storage-class-specifierconst error_category& iostream_category();++The implementation shall initialize iostream_category. Its storage-class-specifier + may be static or extern. It is unspecified whether initialization is static + or dynamic (3.6.2). If initialization is dynamic, it shall occur before + completion of the dynamic initialization of the first translation unit + dynamically initialized that includes header <system_error>.
+Returns: A reference to an object of a type derived from class error_category. +
+Remarks: The object's default_error_condition and equivalent virtual functions shall +behave as specified for the class error_category. The object's name virtual +function shall return a pointer to the string "iostream".
+
-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.
+891. std::thread, std::call_once issue
+Section: 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] Status: Open + Submitter: Peter Dimov Opened: 2008-09-15 Last modified: 2009-03-22
+View other active issues in [thread.thread.constr].
+View all other issues in [thread.thread.constr].
+View all issues with Open 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. +I notice that the vararg overloads of std::thread and std::call_once +(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of +std::bind; instead, some of the std::bind wording has been inlined into +the specification.
--In "C," this array usage is possible: +There are two problems with this.
- --int ar[] = {1, 4, 6}; --But for C++, +First, the specification (and implementation) in terms of std::bind allows, for example:
--std::array<int> a = { 1, 4, 6 }; // error +std::thread th( f, 1, std::bind( g ) );-Instead, the second parameter of the array template must be -explicit, like so: +which executes f( 1, g() ) in a thread. This can be useful. The +"inlined" formulation changes it to execute f( 1, bind(g) ) in a thread.
- --std::array<int, 3> a = { 1, 4, 6 }; --Doug Gregor proposes the following solution, that assumes -generalized initializer lists. +Second, assuming that we don't want the above, the specification has copied the wording
-+template<typename T, typename... Args> -inline array<T, sizeof...(Args)> -make_array(Args&&... args) -{ return { std::forward<Args>(args)... }; } -+INVOKE(func, w1, w2, ..., wN) (20.6.2) shall be a valid +expression for some values w1, w2, ..., wN +-Then, the way to build an array from a list of unknown size is: +but this is not needed since we know that our argument list is args; it should simply be
-+auto a = make_array<T>(1, 4, 6); -+INVOKE(func, args...) (20.6.2) shall be a valid expression ++[ +Summit: +]
-Proposed resolution:
--Add to the array synopis in 23.2 [sequences]: -
++Move to open. +-+template<typename T, typename... Args> - requires Convertible<Args, T>... - array<T, sizeof...(Args)> - make_array(Args&&... args); -[ +Post Summit Anthony provided proposed wording. +]
+ + +Proposed resolution:
-Append after 23.2.1.6 [array.tuple] Tuple interface to class template array the -following new section. +Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
++template <class F> explicit thread(F f); +template <class F, class ...Args> thread(F&& f, Args&&... args); +++-4- Requires: F and each Ti in Args +shall be CopyConstructible if an lvalue and otherwise +MoveConstructible. INVOKE(f,+w1, w2, ..., wNargs...) +(20.6.2) shall be a valid expressionfor some values w1, w2, ..., +wN, where N == sizeof...(Args). +-23.2.1.7 Convenience interface to class template array [array.tuple] +Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
-template<typename T, typename... Args> - requires Convertible<Args, T>... - array<T, sizeof...(Args)> - make_array(Args&&... args); +@@ -17332,2386 +16699,21183 @@ following new section.template<class Callable, class ...Args> + void call_once(once_flag& flag, Callable func, Args&&... args);---Returns: {std::forward<Args>(args)...} -
+-1- Requires: The template parameters Callable> and each +Ti in Args shall be CopyConstructible if an +lvalue and otherwise MoveConstructible. INVOKE(func, +w1, w2, ..., wNargs...) (20.6.2) shall be a +valid expressionfor some values w1, w2, ..., wN, where +N == sizeof...(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.
+893. std::mutex issue
+Section: 30.4.1.1 [thread.mutex.class] Status: Open + Submitter: Peter Dimov Opened: 2008-09-15 Last modified: 2009-03-22
+View other active issues in [thread.mutex.class].
+View all other issues in [thread.mutex.class].
+View all issues with Open status.
+Duplicate of: 905
Discussion:
-In 3 of the four unordered containers the local begin member is mistakenly declared const: +30.4.1.1 [thread.mutex.class]/27 (in +N2723) +says that the behavior is undefined if: +
++
+- a thread that owns a mutex object calls lock() or +try_lock() on that object
++I don't believe that this is right. Calling lock() or try_lock() on a +locked mutex is well defined in the general case. try_lock() is required +to fail and return false. lock() is required to either throw an +exception (and is allowed to do so if it detects deadlock) or to block +until the mutex is free. These general requirements apply regardless of +the current owner of the mutex; they should apply even if it's owned by +the current thread. +
++Making double lock() undefined behavior probably can be justified (even +though I'd still disagree with the justification), but try_lock() on a +locked mutex must fail.
-+local_iterator begin(size_type n) const; -[ +Summit: +]
+ +++Move to open. Proposed resolution: +
++
+- +In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error +condition for resource_deadlock_would_occur to: "if the implementation +detects that a deadlock would occur" +
+- +Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object +calls lock() or try_lock() on that object, or" +
+Proposed resolution:
-Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: +In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
-+local_iterator begin(size_type n)const; -++ ++
+- ...
+- +resource_deadlock_would_occur -- if the
+current thread already owns the mutex and is able +to detect itimplementation detects that a deadlock would occur. +- ...
++Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2: +
+++ ++-3- The behavior of a program is undefined if: +
++
+- ...
+- +
+a thread that owns a mutex object calls lock() or try_lock() on that object, or+- ...
+
-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.
+895. "Requires:" on std::string::at et al
+Section: 17.5.1.4 [structure.specifications] Status: Open + Submitter: James Dennett Opened: 2008-09-16 Last modified: 2009-03-11
+View other active issues in [structure.specifications].
+View all other issues in [structure.specifications].
+View all issues with Open status.
Discussion:
-Issue 396 adds defaulted arguments to the to_string member, but neglects to update -the three newer to_string overloads. +Per discussion, we need an issue open to cover looking at "Requires" +clauses which are not constraints on user code, such as that on +std::basic_string::at.
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.
+896. Library thread safety issue
+Section: 20.8.13.2 [util.smartptr.shared] Status: Open + Submitter: Hans Boehm Opened: 2008-09-16 Last modified: 2008-09-25
+View other active issues in [util.smartptr.shared].
+View all other issues in [util.smartptr.shared].
+View all issues with Open 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. +It is unclear whether shared_ptr is thread-safe in the sense that +multiple threads may simultaneously copy a shared_ptr. However this +is a critical piece of information for the client, and it has significant +impact on usability for many applications. (Detlef Vollman thinks it +is currently clear that it is not thread-safe. Hans Boehm thinks +it currently requires thread safety, since the use_count is not an +explicit field, and constructors and assignment take a const reference +to an existing shared_ptr.)
+-Rules out cross-casting. +Pro thread-safety:
-The requirements for unique_ptr conversions should be the same as those on the deleter. +Many multi-threaded usages are impossible. A thread-safe version can +be used to destroy an object when the last thread drops it, something +that is often required, and for which we have no other easy mechanism.
- - -Proposed resolution:
-Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: +Against thread-safety:
- --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; - }; -} --... +The thread-safe version is well-known to be far more expensive, even +if used by a single thread. Many applications, including all single-threaded +ones, do not care.
-- - - - +template <class U> - requires Convertible<U*, T*> && HasVirtualDestructor<T> - default_delete(const default_delete<U>& other); -[ +San Francisco: +]
-
-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. +Beman: this is a complicated issue, and would like to move this to Open +and await comment from Peter Dimov; we need very careful and complete +rationale for any decision we make; let's go slow
-A simple picture of a deque: +Detlef: I think that shared_ptr should not be thread-safe.
-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)). +Hans: When you create a thread with a lambda, it in some cases makes it +very difficult for the lambda to reference anything in the heap. It's +currently ambiguous as to whether you can use a shared_ptr to get at an +object.
-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). +Leave in Open. Detlef will submit an alternative proposed resolution +that makes shared_ptr explicitly unsafe.
-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: +A third option is to support both threadsafe and non-safe share_ptrs, +and to let the programmer decide which behavior they want.
- - -Proposed resolution:
--Add new signatures to synopsis in 23.2.2 [deque]: +Beman: Peter, do you support the PR?
--size_type capacity() const; -bool reserve(size_type n); --Add new signatures to 23.2.2.2 [deque.capacity]: +Peter:
- --- -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. +Yes, I support the proposed resolution, and I certainly oppose any +attempts to make shared_ptr thread-unsafe.
-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. +I'd mildly prefer if
--+ +bool reserve(size_type n); -+[Note: This is true in spite of that fact that such functions often +modify use_count() --end note] +-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. +is changed to
++[Note: This is true in spite of that fact that such functions often +cause a change in use_count() --end note] +-4 Complexity: It does not change the size of the sequence and takes -at most linear time in n. +(or something along these lines) to emphasise that use_count() is not, +conceptually, a variable, but a return value.
+Proposed resolution:
-5 Throws: length_error if n > max_size(). +Make it explicitly thread-safe, in this weak sense, as I believe was intended:
-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(). +Insert in 20.8.13.2 [util.smartptr.shared], before p5:
+--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. +For purposes of determining the presence of a data race, +member functions do not modify const shared_ptr and +const weak_ptr arguments, nor any objects they +refer to. [Note: This is true in spite of that fact that such functions often +cause a change in use_count() --end note]
-And 23.2.2.3 [deque.modifiers] para 1, can be enhanced: +On looking at the text, I'm not sure we need a similar disclaimer +anywhere else, since nothing else has the problem with the modified +use_count(). I think Howard arrived at a similar conclusion.
--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.
+897. Forward_list issues... Part 2
+Section: 23.3.3.4 [forwardlist.modifiers] Status: Review + Submitter: Howard Hinnant Opened: 2008-09-22 Last modified: 2009-05-23
+View all issues with Review 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. +This issue was split off from 892 at the request of the LWG.
+[ +San Francisco: +]
+ -Proposed resolution:
+-Remove the following signature from 20.5.2 [meta.type.synop]: +This issue is more complicated than it looks.
--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: +paragraph 47: replace each (first, last) with (first, last]
- -- - - - - -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. +add a statement after paragraph 48 that complexity is O(1)
-It might be simpler to change the return type to a scoped enum: +remove the complexity statement from the first overload of splice_after
-+enum class timeout { not_reached, reached }; -+We may have the same problems with other modifiers, like erase_after. +Should it require that all iterators in the range (position, last] be +dereferenceable? +
+-That's the same cost as returning a bool, but not subject to mistakes. Your example below would be: +There are actually 3 issues here:
-+ +if (cv.wait_until(lk, time_limit) == timeout::reached ) - throw time_out(); ++
+- +
++What value should erase_after return? With list, code often +looks like: +
+- -for (auto i = l.begin(); i != l.end();) +{ + // inspect *i and decide if you want to erase it + // ... + if (I want to erase *i) + i = l.erase(i); + else + ++i; +}[ -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 +I.e. the iterator returned from erase is useful for setting up the +logic for operating on the next element. For forward_list this might +look something like:
--... for all non-null p referencing the argument is no longer declared reachable... -+auto i = fl.before_begin(); +auto ip1 = i; +for (++ip1; ip1 != fl.end(); ++ip1) +{ + // inspect *(i+1) and decide if you want to erase it + // ... + if (I want to erase *(i+1)) + i = fl.erase_after(i); + else + ++i; + ip1 = i; +} +-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. +In the above example code, it is convenient if erase_after returns +the element prior to the erased element (range) instead of the element +after the erase element (range).
-I don't know what "shall be live" in the Requires clause means. +Existing practice:
++
- SGI slist returns an iterator referencing the element after the erased range.
+- CodeWarrior slist returns an iterator referencing the element before the erased range.
+-In the final Note for undeclare_reachable, what does "cannot be -deallocated" mean? Is this different from "will not be able to collect"? +There is not a strong technical argument for either solution over the other.
+- +
-For the wording on nesting of declare_reachable and -undeclare_reachable, the words for locking and unlocking recursive -mutexes probably are a good model. +With all other containers, operations always work on the range +[first, last) and/or prior to the given position.
- - -Proposed resolution:
+With forward_list, operations sometimes work on the range +(first, last] and/or after the given position.
- - - - - -
-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. +This is simply due to the fact that in order to operate on +*first (with forward_list) one needs access to +*(first-1). And that's not practical with +forward_list. So the operating range needs to start with (first, +not [first (as the current working paper says).
-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 +Additionally, if one is interested in splicing the range (first, last), +then (with forward_list), one needs practical (constant time) access to +*(last-1) so that one can set the next field in this node to +the proper value. As this is not possible with forward_list, one must +specify the last element of interest instead of one past the last element of +interest. The syntax for doing this is to pass (first, last] instead +of (first, last).
- -wait_until(lock, chrono::monotonic_clock::now() + rel_time) ++With erase_after we have a choice of either erasing the range +(first, last] or (first, last). Choosing the latter +enables: +
+x.erase_after(pos, x.end());-when monotonic_clock is not required to exist? +With the former, the above statement is inconvenient or expensive due to the lack +of constant time access to x.end()-1. However we could introduce:
+-iterator erase_to_end(const_iterator position); +Proposed resolution:
+to compensate.
++The advantage of the former ((first, last]) for erase_after +is a consistency with splice_after which uses (first, last] +as the specified range. But this either requires the addition of erase_to_end +or giving up such functionality. +
+- +As stated in the discussion of 892, and reienforced by point 2 above, +a splice_after should work on the source range (first, last] +if the operation is to be Ο(1). When splicing an entire list x the +algorithm needs (x.before_begin(), x.end()-1]. Unfortunately x.end()-1 +is not available in constant time unless we specify that it must be. In order to +make x.end()-1 available in constant time, the implementation would have +to dedicate a pointer to it. I believe the design of +N2543 +intended a nominal overhead of foward_list of 1 pointer. Thus splicing +one entire forward_list into another can not be Ο(1). +
+[ +Batavia (2009-05): +]
-
-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. +We agree with the proposed resolution. +
++Move to Review.
+Proposed resolution:
+Wording below assumes issue 878 is accepted, but this issue is +independent of that issue.
- - - - -
-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: +Change 23.3.3.4 [forwardlist.modifiers]:
-== is an equivalence relation. a.size() == b.size() && -equal(a.begin(), a.end(), b.begin() -- +iterator erase_after(const_iterator position); ++--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. +Requires: The iterator following position is dereferenceable.
-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. +Effects: Erases the element pointed to by the iterator following position.
-I propose to apply one of the following resolutions, which are described as: +Returns:
+An iterator pointing to the element following the one that was erased, or end() if no such +element exists+An iterator equal to position.-
+ +- -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. -
-- -The simple fix where the usual test is adapted such that size() is replaced -by distance with corresponding performance disadvantages. -
-iterator erase_after(const_iterator position, const_iterator last); ++-Both proposal choices are discussed, the preferred choice of the author is -to apply (A). +Requires: All iterators in the range +
- - -[(position,last) +are dereferenceable.Proposed resolution:
-Common part: +Effects: Erases the elements in the range +
-[(position,last).-
+- -
-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"): +Returns: An iterator equal to position
-last-forwardlist comparison operators [forwardlist.compare]--Option (A): -
----
-- -
--Add to the new section [forwardlist.compare] the following paragraphs: +Change 23.3.3.5 [forwardlist.ops]:
--template <class T, class Allocator> -bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +void splice_after(const_iterator position, forward_list<T,Allocator>&& x);--Requires: Type T is EqualityComparable ([equalitycomparable]). -
--Returns: true if +Requires: position is before_begin() or a +dereferenceable iterator in the range [begin(), end)). &x != this.
--
- -
-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: +Effects: Inserts the contents of x after position, and +x becomes empty. Pointers and references to +the moved elements of x now refer to those same elements but as members of *this. +Iterators referring to the moved elements will continue to refer to their elements, +but they now behave as iterators into *this, not into x.
--*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. +Throws: Nothing.
-Complexity: At most M comparisons. +Complexity:
Ο(1)Ο(distance(x.begin(), x.end()))template <class T, class Allocator> -bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); ---Returns: !(x == y). ---Option (B): -
+...
+ +void splice_after(const_iterator position, forward_list<T,Allocator>&& x, + const_iterator first, const_iterator last); +-+-
+- -
-Add to the new section [forwardlist.compare] the following paragraphs: +Requires: position is before_begin() or a +dereferenceable iterator in the range [begin(), end)). +(first,last]
-)is a valid range in +x, and all iterators in the range +(first,last])are dereferenceable. +position is not an iterator in the range (first,last]).--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]). +Effects: Inserts elements in the range (first,last]
)+after position and removes the elements from x. +Pointers and references to the moved elements of x now refer to +those same elements but as members of *this. Iterators +referring to the moved elements will continue to refer to their +elements, but they now behave as iterators into *this, not into +x.-Returns: distance(x.begin(), x.end()) == distance(y.begin(), y.end()) -&& equal(x.begin(), x.end(), y.begin()). +Complexity: Ο(1).
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.
+898. Small contradiction in n2723 to forward to committee
+Section: 23.3.3.5 [forwardlist.ops] Status: Tentatively Ready + Submitter: Arch Robison Opened: 2008-09-08 Last modified: 2009-05-23
+View other active issues in [forwardlist.ops].
+View all other issues in [forwardlist.ops].
+View all issues with Tentatively Ready 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! +I ran across a small contradiction in working draft n2723.
- ++-This same issue also applies to: +23.3.3 [forwardlist]p2: A forward_list satisfies all of the +requirements of a container (table 90), except that the size() member +function is not provided.
- --
- - -- set_union
-- set_intersection
-- set_difference
-- set_symmetric_difference
-- merge
-Proposed resolution:
+23.3.3.5 [forwardlist.ops]p57: Complexity: At most size() + x.size() - 1 +comparisons. +
++Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use +size(), or note that it is used there only for sake of notational convenience.
+[ +2009-03-29 Beman provided proposed wording. +]
+[ +Batavia (2009-05): +]
- -
-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. +We agree with the proposed resolution.
-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? +Move to Tentatively Ready.
+Proposed resolution:
--
+Change 23.3.3.5 [forwardlist.ops], +forward_list operations, paragraph 19, merge complexity as indicated: +
+Complexity: At mostsize() + x.size()+distance(begin(), end()) + distance(x.begin(), x.end()) - 1 +comparisons. +
-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.
+899. Adjusting shared_ptr for nullptr_t
+Section: 20.8.13.2.2 [util.smartptr.shared.dest] Status: Tentatively Ready + Submitter: Peter Dimov Opened: 2008-09-18 Last modified: 2009-05-23
+View all other issues in [util.smartptr.shared.dest].
+View all issues with Tentatively Ready status.
Discussion:
-There's an error in 29.4 [atomics.types.operations]/p9: +James Dennett, message c++std-lib-22442:
---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. -
+The wording below addresses one case of this, but opening an +issue to address the need to sanity check uses of the term "pointer" +in 20.8.13.2 [util.smartptr.shared] would be a good thing.-I believe that this should state +There's one more reference, in ~shared_ptr; we can apply your suggested change to it, too. That is:
--shall not be memory_order_release. ---There's also an error in 29.4 [atomics.types.operations]/p17: +Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet from:
--... 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 ... +Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.-I believe this should state +to:
-shall be replaced by the value memory_order_acquire ... +Otherwise, if *this owns an object p and a deleter d, d(p) is called.+[ +Post Summit: +]
-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; -+Recommend Review. +[ +Batavia (2009-05): +]
+--Requires: The order argument shall not be
+memory_order_acquire-memory_order_release nor memory_order_acq_rel. +Peter Dimov notes the analogous change has already been made +to "the new nullptr_t taking constructors +in 20.8.13.2.1 [util.smartptr.shared.const] p9-13." ++We agree with the proposed resolution. +Move to Tentatively Ready.
Proposed resolution:
-Change 29.4 [atomics.types.operations]/p17: +Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet:
--... 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_requirememory_order_acquire ... ++
- ...
+- +Otherwise, if *this owns
+a pointer+an object p and a +deleter d, d(p) is called. +
-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.
+900. stream move-assignment
+Section: 27.9.1.8 [ifstream.assign] Status: Open + Submitter: Niels Dekker Opened: 2008-09-20 Last modified: 2009-05-23
+View all issues with Open 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: +It +appears that we have an issue similar to issue 675 regarding the move-assignment of +stream types. For example, when assigning to an std::ifstream, +ifstream1, it seems preferable to close the file originally held by +ifstream1:
--
- -
+template<class OutputIterator, class Size, class T> -void fill_n(OutputIterator first, Size n, const T& value);-ifstream1 = std::move(ifstream2); +- -
-template<class OutputIterator, class Size, class Generator> -void generate_n(OutputIterator first, Size n, Generator gen);-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. +The current Draft +(N2723) +specifies that the move-assignment of +stream types like ifstream has the same effect as a swap:
- -Proposed resolution:
--
- +
---Replace the current declaration of fill_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.6 [alg.fill] by +Assign and swap 27.9.1.8 [ifstream.assign]
+basic_ifstream& operator=(basic_ifstream&& rhs); +++Effects: swap(rhs). +++template<class OutputIterator, class Size, class T> -voidOutputIterator fill_n(OutputIterator first, Size n, const T& value); -[ +Batavia (2009-05): +]
+ +-Just after the effects clause p.2 add a new returns clause saying: +Howard agrees with the analysis and the direction proposed.
--Returns: first + n for fill_n. ---Replace the current declaration of generate_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.7 [alg.generate] by +Move to Open pending specific wording to be supplied by Howard.
-+template<class OutputIterator, class Size, class Generator> -voidOutputIterator generate_n(OutputIterator first, Size n, Generator gen); -Proposed resolution:
-Just after the effects clause p.1 add a new returns clause saying:
--Returns: first + n for generate_n. -- -
-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.
+901. insert iterators can move from lvalues
+Section: 24.7.5 [insert.iterator] Status: Tentatively NAD + Submitter: Alisdair Meredith Opened: 2008-09-24 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
Discussion:
+Addresses UK 282
+-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: +The requires clause on the const T & overloads in +back_insert_iterator/front_insert_iterator/insert_iterator mean that the +assignment operator will implicitly move from lvalues of a move-only type.
--
+-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: +Suggested resolutions are:
-+new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first); -+
- +Add another overload with a negative constraint on copy-constructible +and flag it "= delete".
- -
--in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression: -
-+Drop the copy-constructible overload entirely and rely on perfect +forwarding to catch move issues one level deeper.new (pv) T(std::forward<Args>(args)...), -+This is a fundamental problem in move-syntax that relies on the +presence of two overloads, and we need to look more deeply into this +area as a whole - do not solve this issue in isolation. + + + +[ +Post Summit, Alisdair adds: +]
+ + ++ +-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. +Both comment and issue have been resolved by the adoption of +N2844 +(rvalue references safety fix) at the last meeting.
+-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. +Suggest resolve as NAD Editorial with a reference to the paper.
+[ +Batavia (2009-05): +]
+ ++We agree that this has been resolved in the latest Working Draft. +Move to NAD. +Proposed resolution:
-Replace "new" with "::new" in: +Recommend NAD, addressed by N2844.
--
-- -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.
+902. Regular is the wrong concept to constrain numeric_limits
+Section: 18.3.1 [limits] Status: Open + Submitter: Alisdair Meredith Opened: 2008-09-24 Last modified: 2009-03-11
+View all other issues in [limits].
+View all issues with Open 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. --Addresses FR 32 and DE 16
-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: +numeric_limits has functions specifically designed to return NaNs, which +break the model of Regular (via its axioms.) While floating point types +will be acceptible in many algorithms taking Regular values, it is not +appopriate for this specific API and we need a less refined constraint.
+FR 32:
+-The elements of the array are constructed using the default constructor for the instantiating type T. +The definition of numeric_limits<> as requiring a regular +type is both conceptually wrong and operationally illogical. As we +pointed before, this mistake needs to be corrected. For example, the +template can be left unconstrained. In fact this reflects a much more +general problem with concept_maps/axioms and their interpretations. It +appears that the current text heavily leans toward experimental academic +type theory.--with -
+ +DE 16:
+-The elements of the array are value-initialized. +The class template numeric_limits should not specify the Regular concept +requirement for its template parameter, because it contains functions +returning NaN values for floating-point types; these values violate the +semantics of EqualityComparable.--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). -
- +[ +Summit: +]
-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+Move to Open. Alisdair and Gaby will work on a solution, along with the new +treatment of axioms in clause 14.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] -Proposed resolution:
++
-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.
+903. back_insert_iterator issue
+Section: 24.7.1 [back.insert.iterator] Status: Tentatively NAD + Submitter: Dave Abrahams Opened: 2008-09-19 Last modified: 2009-05-30
+View all issues with Tentatively NAD 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. +I just noticed this; don't know how far the problem(?) extends or +whether it's new or existing: back_insert_iterator's operator* is not +const, so you can't dereference a const one.
+[ +Post Summit Daniel adds: +]
-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])": +If done, this change should be applied for front_insert_iterator, +insert_iterator, ostream_iterator, and ostreambuf_iterator as well.
+-
- - - - +- 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
-[ +Batavia (2009-05): +]
-
-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? +Alisdair notes that these all are output iterators. +Howard points out that ++*i +would no longer work if we made this change.
- --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. +Move to NAD.
+[ +2009-05-25 Daniel adds: +]
-Proposed resolution:
--Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]: -
--+-
-Table 97: Unordered associative container requirements -- -expression return type assertion/note pre/post-condition complexity -- -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 -+
+ +- +If 1009 is accepted, OutputIterator does no longer support post increment. +
+- +To support backward compatibility a second overload of operator* +can be added. +Note that the HasDereference concept (and the HasDereference part of concept +Iterator) was specifically refactored to cope with optional const +qualification and +to properly reflect the dual nature of built-in operator* as of +13.5.8 [over.literal]/6. +
+Proposed resolution:
-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.
+904. result_of argument types
+Section: 20.7.4 [func.ret] Status: Tentatively Ready + Submitter: Jonathan Wakely Opened: 2008-09-10 Last modified: 2009-03-09
+View all issues with Tentatively Ready 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: +The WP and TR1 have the same text regarding the argument types of a +result_of expression:
--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 values ti are lvalues when the corresponding type Ti is a +reference type, and rvalues otherwise.--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: +I read this to mean that this compiles:
- -++typedef int (*func)(int&); +result_of<func(int&&)>::type i = 0; +-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.[..] +even though this doesn't:
+int f(int&); +f( std::move(0) ); +-A hash function is a function object that takes a single argument of -type Key and returns a -value of type std::size_t. +Should the text be updated to say "when Ti is an lvalue-reference +type" or am I missing something?
-Two values k1 and k2 of type Key are considered equal if the -container's equality function object -returns true when passed those values.[..] +I later came up with this self-contained example which won't compile, +but I think it should:
-+ +struct X { + void operator()(int&); + int operator()(int&&); +} x; + +std::result_of< X(int&&) >::type i = x(std::move(0)); +[ +Post Summit: +]
--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. +Recommend Tentatively Ready.--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: +Change 20.7.4 [func.ret], p1:
-Both Hash and Pred may be pointers to function or objects of a type -with an appropriate function call operator. +... The values ti are lvalues +when the corresponding type Ti is an lvalue-reference type, +and rvalues otherwise.--[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.
+906. ObjectType is the wrong concept to constrain initializer_list
+Section: 18.9 [support.initlist] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-09-26 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
Discussion:
-According to the recent WP -N2691, -26.6.5 [numeric.iota]/1, the requires clause -of std::iota says: +The currently proposed constraint on initializer_list's element type +E is that is has to meet ObjectType. This is an underspecification, +because both core language and library part of initializer_list +make clear, that it references an implicitly allocated array: +
++8.5.4 [dcl.init.list]/4:
--T shall meet the requirements of CopyConstructible and Assignable types, and -shall be convertible to ForwardIterator's value type.[..] +When an initializer list is implicitly converted to a +std::initializer_list<E>, the object passed is constructed as if the +implementation allocated an array of N elements of type E, where +N is the number of elements in the initializer list.[..]-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. +18.9 [support.initlist]/2.
++An object of type initializer_list<E> provides access to an array of +objects of type const E.[..] ++-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. +Therefore, E needs to fulfill concept ValueType (thus excluding +abstract class types). This stricter requirement should be added +to prevent deep instantiation errors known from the bad old times, +as shown in the following example:
++// Header A: (Should concept-check even in stand-alone modus) +template <DefaultConstructible T> +requires MoveConstructible<T> +void generate_and_do_3(T a) { + std::initializer_list<T> list{T(), std::move(a), T()}; + ... +} -Proposed resolution:
+void do_more(); +void do_more_or_less(); --Change the first sentence of 26.6.5 [numeric.iota]/1: -
+template <DefaultConstructible T> +requires MoveConstructible<T> +void more_generate_3() { + do_more(); + generate_and_do_3(T()); +} --Requires: T shall+template <DefaultConstructible T> +requires MoveConstructible<T> +void something_and_generate_3() { + do_more_or_less(); + more_generate_3(); +} +// Test.cpp +#include "A.h" +class Abstract { +public: + virtual ~Abstract(); + virtual void foo() = 0; // abstract type + Abstract(Abstract&&){} // MoveConstructible + Abstract(){} // DefaultConstructible +}; +int main() { + // The restricted template *accepts* the argument, but + // causes a deep instantiation error in the internal function + // generate_and_do_3: + something_and_generate_3<Abstract>(); +} +meet the requirements of -CopyConstructible and Assignable types,- -be MoveConstructible (Table 34) - -and shall be -convertible to ForwardIterator's value type. [..] -+The proposed stricter constraint does not minimize the aim to +support more general containers for which ObjectType would be +sufficient. If such an extended container (lets assume it's still a +class template) provides a constructor that accepts an initializer_list +only this constructor would need to be restricted on ValueType: +
-
-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.
++ +template<ObjectType T> +class ExtContainer { +public: + requires ValueType<T> + ExtContainer(std::initializer_list<T>); + ... +}; +[ +Batavia (2009-05): +]
+ ++Move to Tentatively Ready. ++ + + +Proposed resolution:
++
+ + + + + + +- +In 18.9 [support.initlist]/p.1 replace in "header <initializer_list> synopsis" +the constraint "ObjectType" in the template parameter list by the +constraint "ValueType". +
+
+907. Bitset's immutable element retrieval is inconsistently defined
+Section: 20.3.6.2 [bitset.members] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-09-26 Last modified: 2009-05-23
+View all other issues in [bitset.members].
+View all issues with Tentatively Ready status.
Discussion:
-move_iterator's operator[] is declared as: +The current standard 14882::2003(E) as well as the current draft +N2723 +have in common a contradiction of the operational semantics +of member function test 20.3.6.2 [bitset.members]/56-58 and the immutable +member operator[] overload 20.3.6.2 [bitset.members]/64-66 (all references +are defined in terms of +N2723): +
+ ++
+ +- +
bool test(size_t pos) const; +++++Requires: pos is valid +
++Throws: out_of_range if pos does not correspond +to a valid bit position. +
++Returns: true if the bit at position pos in *this +has the value one. +
+- +
constexpr bool operator[](size_t pos) const; +++++Requires: pos shall be valid. +
++Throws: nothing. +
++Returns: test(pos). +
++Three interpretations: +
+ ++
+ +- +The operator[] overload is indeed allowed to throw an exception +(via test(), if pos corresponds to an invalid bit position) which does +not leave the call frame. In this case this function cannot be a +constexpr function, because test() is not, due to +5.19 [expr.const]/2, last bullet. +
+- +The intend was not to throw an exception in test in case of an +invalid bit position. There is only little evidence for this interpretation. +
+- +The intend was that operator[] should not throw any exception, +but that test has the contract to do so, if the provided bit position +is invalid. +
++The problem became worse, because issue 720 +recently voted into WP argued that member test logically must be +a constexpr function, because it was used to define the semantics +of another constexpr function (the operator[] overload). +
+ ++Three alternatives are proposed, corresponding to the three bullets +(A), (B), and (C), the author suggests to follow proposal (C). +
+ + +Proposed alternatives: + + ++
+ +- +
++Remove the constexpr specifier in front of operator[] overload and +undo that of member test (assuming 720 is accepted) in both the +class declaration 20.3.6 [template.bitset]/1 and in the member description +before 20.3.6.2 [bitset.members]/56 and before /64 to read: +
++ +constexprbool test(size_t pos) const; +.. +constexprbool operator[](size_t pos) const; ++Change the throws clause of p. 65 to read: +
+ ++Throws:+nothing+out_of_range if pos does not correspond to a valid bit +position. +- +
++Replace the throws clause p. 57 to read: +
+ ++Throws:+out_of_range if pos does not correspond to a valid bit +positionnothing. +- +
++Undo the addition of the constexpr specifier to the test member +function in both class declaration 20.3.6 [template.bitset]/1 and in the +member description before 20.3.6.2 [bitset.members]/56, assuming that 720 +was applied.
-reference operator[](difference_type n) const; +constexprbool test(size_t pos) 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. +Change the returns clause p. 66 to read: +
+ ++Returns:+test(pos)true if the bit at position pos in *this +has the value one, otherwise false. +[ +Post Summit: +]
+ + +++ ++Lawrence: proposed resolutions A, B, C are mutually exclusive. +
++Recommend Review with option C.
+[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. +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: +Undo the addition of the constexpr specifier to the test member +function in both class declaration 20.3.6 [template.bitset]/1 and in the +member description before 20.3.6.2 [bitset.members]/56, assuming that 720 +was applied.
-referenceunspecified operator[](difference_type n) const; ++constexprbool test(size_t pos) const;+Change the returns clause p. 66 to read: +
+ ++Returns:+test(pos)true if the bit at position pos in *this +has the value one, otherwise false. +
-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.
+908. Deleted assignment operators for atomic types must be volatile
+Section: 29.5 [atomics.types] Status: Open + Submitter: Anthony Williams Opened: 2008-09-26 Last modified: 2009-03-22
+View all other issues in [atomics.types].
+View all issues with Open 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
andwchar_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, ifT
isunsigned char
, the - expressionmake_signed<T>::type
, is supposed to - name a signed integral type. There are potentially two types that - satisfy this requirement, namelysigned char
and -char
(assumingCHAR_MIN < 0
). -Addresses US 90
-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... -
--+-
-
- -- - 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 asstd::ptrdiff_t
in the -<cstdint>
header (18.1)... -+The deleted copy-assignment operators for the atomic types are not +marked as volatile in N2723, whereas the assignment operators from the +associated non-atomic types are. e.g. +
+-atomic_bool& operator=(atomic_bool const&) = delete; +atomic_bool& operator=(bool) volatile; +- 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 -+- -
-- - - -expression -return type -assertion/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. -+This leads to ambiguity when assigning a non-atomic value to a +non-volatile instance of an atomic type: +
+-atomic_bool b; +b=false; +- 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 -+- -
-- - - -Template -Comments -- -- template <class T> struct make_signed; - -- If -T
names a (possibly cv-qualified)signed - integral typesigned integer type (3.9.1) then - the member typedeftype
shall name the type -T
; otherwise, ifT
names a (possibly - cv-qualified)unsigned integral typeunsigned - integer type thentype
shall name the - correspondingsigned 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 whichsizeof(T) == - sizeof(type)
, with the same cv-qualifiers as -T
. ++Both assignment operators require a standard conversions: the +copy-assignment operator can use the implicit atomic_bool(bool) +conversion constructor to convert false to an instance of +atomic_bool, or b can undergo a qualification conversion in order to +use the assignment from a plain bool. +
- 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 typedeftype
- shall name the typeT
; otherwise, if -T
names a (possibly cv-qualified)signed - integral typesigned integer type then -type
shall name the correspondingunsigned - integral typeunsigned integer type, with the - same cv-qualifiers asT
; otherwise, -type
shall name theunsigned integral - typeunsigned integer type with the smallest - rank (4.13) for whichsizeof(T) == sizeof(type)
, - with the same cv-qualifiers asT
. ++This is only a problem once issue 845 is applied. +
- Requires:T
shall be a (possibly - cv-qualified) integral type or enumeration but not a -bool
type. -[ +Summit: +]
++Move to open. Assign to Lawrence. Related to US 90 comment. +-- 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. +
Proposed resolution:
++Add volatile qualification to the deleted copy-assignment operator of +all the atomic types: +
- 22.2.2.1.2 [facet.num.get.virtuals] table 78... - -- Table 78: Integer Conversions -+- -
-- - - -State -stdio equivalent -- -basefield == oct -%o -- -basefield == hex -%X -- -basefield == 0 -%i -- -- signed integral typesigned integer - type%d -- - -- unsigned integral typeunsigned integer - type%u -- - -atomic_bool& operator=(atomic_bool const&) volatile = delete; +atomic_itype& operator=(atomic_itype const&) volatile = delete; +- Rationale is same as above. - 22.2.2.2.2 [facet.num.put.virtuals] table 80... -
-- Table 80: Integer Conversions -+- -
-- - - -State -stdio 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 -+etc. +
++This will mean that the deleted copy-assignment operator will require +two conversions in the above example, and thus be a worse match than +the assignment from plain bool. +
- -- 23.1 [container.requirements] table 80... -
-- Table 89: Container requirements --- -
-- - - -expression -return type -operational semantics -assertion/note/pre/post-condition -complexity -- -X::difference_type -- signed integral typesigned integer type- is identical to the difference type of X::iterator - and X::const_iterator -compile time -- - -X::size_type -- unsigned integral typeunsigned integer type- size_type can represent any non-negative value of - difference_type -compile 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 typeT
, - called the value type of the iterator. All output iterators - support the expression*i = o
whereo
is a - value of some type that is in the set of types that are - writable to the particular iterator type ofi
. All - iteratorsi
for which the expression(*i).m
- is well-defined, support the expressioni->m
with the - same semantics as(*i).m
. For every iterator type -X
for which equality is defined, there is a corresponding -signed integral typesigned 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 asm - 1
. If the - template parameterm
is 0, the modulusm
- 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
andc < - 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 anunsigned 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. -
+909. regex_token_iterator should use initializer_list
+Section: 28.13.2 [re.tokiter] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-09-26 Last modified: 2009-05-23
+View all other issues in [re.tokiter].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 319
++Construction of a regex_token_iterator (28.13.2 [re.tokiter]/6+) usually +requires the provision of a sequence of integer values, which +can currently be done via a std::vector<int> or +a C array of int. Since the introduction of initializer_list in the +standard it seems much more reasonable to provide a +corresponding constructor that accepts an initializer_list<int> +instead. This could be done as a pure addition or one could +even consider replacement. The author suggests the +replacement strategy (A), but provides an alternative additive +proposal (B) as a fall-back, because of the handiness of this +range type: +
+ +[ +Batavia (2009-05): +]
+ ++We strongly recommend alternative B of the proposed resolution +in order that existing code not be broken. +With that understanding, move to Tentatively Ready. ++ +Original proposed wording:
+ ++
+ + + +- + +
++
+- +
+ ++In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 change the +constructor declaration: +
+ ++template <std::size_t N>+regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, +const int (&submatches)[N]initializer_list<int> submatches, + regex_constants::match_flag_type m = + regex_constants::match_default); +- +
++In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence +
+ ++The third constructor initializes the member subs to hold +a copy of the sequence of integer values pointed to by the +iterator range [+&submatches.begin(), +&submatches.end()+ N). +- + +
++
+- +
++In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 insert the +following constructor declaration between the already existing ones +accepting a std::vector and a C array of int, resp.: +
+ ++regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + initializer_list<int> submatches, + regex_constants::match_flag_type m = + regex_constants::match_default); +- +
++In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence +
+ ++The third and fourth constructor initialize+sthe member subs +to hold a copy of the sequence of integer values pointed to +by the iterator range [&submatches,&submatches + N) +and [submatches.begin(),submatches.end()), respectively. +Proposed resolution:
+ ++ +
+ + + + + + +- + +
++
+- +
++In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 insert the +following constructor declaration between the already existing ones +accepting a std::vector and a C array of int, resp.: +
+ ++regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + initializer_list<int> submatches, + regex_constants::match_flag_type m = + regex_constants::match_default); +- +
++In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence +
+ ++The third and fourth constructor initialize+sthe member subs +to hold a copy of the sequence of integer values pointed to +by the iterator range [&submatches,&submatches + N) +and [submatches.begin(),submatches.end()), respectively. +
+910. Effects of MoveAssignable
+Section: 20.2.9 [concept.copymove] Status: Tentatively Ready + Submitter: Alberto Ganesh Barbati Opened: 2008-09-29 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+Addresses UK 150
+ ++The description of the effect of operator= in the MoveAssignable +concept, given in paragraph 7 is: +
+ ++ +result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&> ++ ++Postconditions: the constructed T object is equivalent to the value of +rv before the assignment. [Note: there is no +requirement on the value of rv after the assignment. --end note] +++The sentence contains a typo (what is the "constructed T object"?) +probably due to a cut&paste from MoveConstructible. Moreover, the +discussion of LWG issue 675 shows that the postcondition is too generic +and might not reflect the user expectations. An implementation of the +move assignment that just calls swap() would always fulfill the +postcondition as stated, but might have surprising side-effects in case +the source rvalue refers to an object that is not going to be +immediately destroyed. See LWG issue 900 for another example. Due to +the sometimes intangible nature of the "user expectation", it seems +difficult to have precise normative wording that could cover all cases +without introducing unnecessary restrictions. However a non-normative +clarification could be a very helpful warning sign that swapping is not +always the correct thing to do. +
+ +[ +2009-05-09 Alisdair adds: +]
+ + +++ ++Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150. +
++The post-conditions after assignment are at a minimum that the object +referenced by rv must be safely destructible, and the transaction should not +leak resources. Ideally it should be possible to simply assign rv a new +valid state after the call without invoking undefined behaviour, but any +other use of the referenced object would depend upon additional guarantees +made by that type. +
+[ +2009-05-09 Howard adds: +]
+ + +++ ++The intent of the rvalue reference work is that the moved from rv is +a valid object. Not one in a singular state. If, for example, the moved from +object is a vector, one should be able to do anything on that moved-from +vector that you can do with any other vector. However you would +first have to query it to find out what its current state is. E.g. it might have capacity, +it might not. It might have a non-zero size, it might not. But regardless, +you can push_back on to it if you want. +
+ ++That being said, most standard code is now conceptized. That is, the concepts +list the only operations that can be done with templated types - whether or not +the values have been moved from. +
+ ++Here is user-written code which must be allowed to be legal: +
++ +#include <vector> +#include <cstdio> + +template <class Allocator> +void +inspect(std::vector<double, Allocator>&& v) +{ + std::vector<double, Allocator> result(move(v)); + std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity()); + std::printf("The contents of the vector are:\n"); + typedef typename std::vector<double, Allocator>::iterator I; + for (I i = v.begin(), e = v.end(); i != e; ++i) + printf("%f\n", *i); +} + +int main() +{ + std::vector<double> v1(100, 5.5); + inspect(move(v1)); +} ++The above program does not treat the moved-from vector as singular. It +only treats it as a vector with an unknown value. +
++I believe the current proposed wording is consistent with my view on this. +
+[ +Batavia (2009-05): +]
+ ++We agree that the proposed resolution +is an improvement over the current wording. ++ + + +Proposed resolution:
++In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with: +
+ ++Postconditions: *this is equivalent to the value of rv before the +assignment. [Note: there is no requirement on the value of rv after the +assignment, but the +effect should be unsurprising to the user even in case rv is not +immediately destroyed. This may require that resources previously owned +by *this are released instead of transferred to rv. -- end note] ++ + + + + +
+911. I/O streams and move/swap semantic
+Section: 27.7.1 [input.streams], 27.7.2 [output.streams] Status: Open + Submitter: Alberto Ganesh Barbati Opened: 2008-09-29 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++Class template basic_istream, basic_ostream and basic_iostream +implements public move constructors, move assignment operators and swap +method and free functions. This might induce both the user and the +compiler to think that those types are MoveConstructible, MoveAssignable +and Swappable. However, those class templates fail to fulfill the user +expectations. For example: +
+ ++ +std::ostream os(std::ofstream("file.txt")); +assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed + +std::vector<std::ostream> v; +v.push_back(std::ofstream("file.txt")); +v.reserve(100); // causes reallocation +assert(v[0].rdbuf() == 0); // file.txt has been closed! + +std::ostream&& os1 = std::ofstream("file1.txt"); +os1 = std::ofstream("file2.txt"); +os1 << "hello, world"; // still writes to file1.txt, not to file2.txt! + +std::ostream&& os1 = std::ofstream("file1.txt"); +std::ostream&& os2 = std::ofstream("file2.txt"); +std::swap(os1, os2); +os1 << "hello, world"; // writes to file1.txt, not to file2.txt! ++This is because the move constructor, the move assignment operator and +swap are all implemented through calls to std::basic_ios member +functions move() and swap() that do not move nor swap the controlled +stream buffers. That can't happen because the stream buffers may have +different types. +
+ ++Notice that for basic_streambuf, the member function swap() is +protected. I believe that is correct and all of basic_istream, +basic_ostream, basic_iostream should do the same as the move ctor, move +assignment operator and swap member function are needed by the derived +fstreams and stringstreams template. The free swap functions for +basic_(i|o|io)stream templates should be removed for the same reason. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We note that the rvalue swap functions have already been removed. +
++Bill is unsure about making the affected functions protected; +he believes they may need to be public. +
++We are also unsure about removing the lvalue swap functions as proposed. +
++Move to Open. +
+Proposed resolution:
++27.7.1.1 [istream]: make the following member functions protected: +
+ ++ +basic_istream(basic_istream&& rhs); +basic_istream& operator=(basic_istream&& rhs); +void swap(basic_istream&& rhs); ++Ditto: remove the three swap free functions signatures +
+ ++ +// swap: +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);++27.7.1.1.2 [istream.assign]: remove paragraph 4 +
+ ++ ++template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);+++Effects: x.swap(y).++27.7.1.5 [iostreamclass]: make the following member function protected: +
+ ++ +basic_iostream(basic_iostream&& rhs); +basic_iostream& operator=(basic_iostream&& rhs); +void swap(basic_iostream&& rhs); ++Ditto: remove the three swap free functions signatures +
+ ++ +template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);++27.7.1.5.3 [iostream.assign]: remove paragraph 3 +
+ ++ ++template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);+++Effects: x.swap(y).++27.7.2.1 [ostream]: make the following member function protected: +
+ ++ +basic_ostream(basic_ostream&& rhs); +basic_ostream& operator=(basic_ostream&& rhs); +void swap(basic_ostream&& rhs); ++Ditto: remove the three swap free functions signatures +
+ ++ +// swap: +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);++27.7.2.3 [ostream.assign]: remove paragraph 13 (The paragraphs seems to +be misnumbered in the whole section 27.7.2 [output.streams] in +N2723. +The paragraph to +remove is the one that describes the three swap free functions). +
+ ++ + + + + + ++template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);+++Effects: x.swap(y).+
+912. Array swap needs to be conceptualized
+Section: 25.4.3 [alg.swap] Status: Tentatively NAD + Submitter: Daniel Krügler Opened: 2008-10-01 Last modified: 2009-05-23
+View all other issues in [alg.swap].
+View all issues with Tentatively NAD status.
+Discussion:
++With the adaption of 809 +we have a new algorithm swap for C-arrays, which needs to be conceptualized. +
+ +[ +Post Summit Daniel adds: +]
+ + ++Recommend as NAD Editorial: The changes have already been applied to the WP +N2800. ++ +[ +Batavia (2009-05): +]
+ ++Move to NAD; the changes have already been made. ++ + +Proposed resolution:
++Replace in 25.4.3 [alg.swap] before p. 3 until p. 4 by +
+ ++ + + + + + +template <+classValueType T, size_t N> +requires Swappable<T> +void swap(T (&a)[N], T (&b)[N]); ++++
+Requires: T shall be Swappable.++Effects: swap_ranges(a, a + N, b); +
+
+913. Superfluous requirements for replace algorithms
+Section: 25.4.5 [alg.replace] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-10-03 Last modified: 2009-05-23
+View other active issues in [alg.replace].
+View all other issues in [alg.replace].
+View all issues with Tentatively Ready status.
+Discussion:
++(A) 25.4.5 [alg.replace]/1: +
+ ++Requires: The expression *first = new_value shall be valid. ++ ++(B) 25.4.5 [alg.replace]/4: +
+ ++Requires: The results of the expressions *first and new_value shall +be writable to the result output iterator.[..] ++ ++Since conceptualization, the quoted content of these clauses is covered +by the existing requirements +
+ ++(A) OutputIterator<Iter, const T&> +
+ ++and +
+ ++(B) OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&> +
+ ++resp, and thus should be removed. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++
+ + + + + +- +
++Remove 25.4.5 [alg.replace]/1. +
++template<ForwardIterator Iter, class T> + requires OutputIterator<Iter, Iter::reference> + && OutputIterator<Iter, const T&> + && HasEqualTo<Iter::value_type, T> + void replace(Iter first, Iter last, + const T& old_value, const T& new_value); + +template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> + requires OutputIterator<Iter, Iter::reference> + && OutputIterator<Iter, const T&> + && CopyConstructible<Pred> + void replace_if(Iter first, Iter last, + Pred pred, const T& new_value); ++++1 Requires: The expression *first = new_value shall be valid.+- +
++25.4.5 [alg.replace]/4: Remove the sentence "The results of the +expressions *first and +new_value shall be writable to the result output iterator.". +
++template<InputIterator InIter, typename OutIter, class T> + requires OutputIterator<OutIter, InIter::reference> + && OutputIterator<OutIter, const T&> + && HasEqualTo<InIter::value_type, T> + OutIter replace_copy(InIter first, InIter last, + OutIter result, + const T& old_value, const T& new_value); + +template<InputIterator InIter, typename OutIter, + Predicate<auto, InIter::value_type> Pred, class T> + requires OutputIterator<OutIter, InIter::reference> + && OutputIterator<OutIter, const T&> + && CopyConstructible<Pred> + OutIter replace_copy_if(InIter first, InIter last, + OutIter result, + Pred pred, const T& new_value); +++4 Requires:+The results of the expressions *first and +new_value shall be writable to the result output +iterator.The ranges [first,last) and [result,result + +(last - first)) shall not overlap. +
+914. Superfluous requirement for unique
+Section: 25.4.9 [alg.unique] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-10-03 Last modified: 2009-05-23
+View other active issues in [alg.unique].
+View all other issues in [alg.unique].
+View all issues with Tentatively Ready status.
+Discussion:
++25.4.9 [alg.unique]/2: "Requires: The comparison function shall be an +equivalence relation." +
+ ++The essence of this is already covered by the given requirement +
+ ++ +EquivalenceRelation<auto, Iter::value_type> Pred ++and should thus be removed. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Remove 25.4.9 [alg.unique]/2 +
+ ++ + + + + +template<ForwardIterator Iter> + requires OutputIterator<Iter, Iter::reference> + && EqualityComparable<Iter::value_type> + Iter unique(Iter first, Iter last); + +template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> + requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> + && CopyConstructible<Pred> + Iter unique(Iter first, Iter last, + Pred pred); +++++1 Effects: ... +
++
+2 Requires: The comparison function shall be an equivalence relation.+
+915. minmax with initializer_list should return +pair of T, not pair of const T&
+Section: 25.5.7 [alg.min.max] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2008-10-04 Last modified: 2009-05-23
+View other active issues in [alg.min.max].
+View all other issues in [alg.min.max].
+View all issues with Tentatively Ready status.
+Discussion:
++It seems that the proposed changes for +N2772 +were not clear enough in +this point: +
+ ++25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return +type of the minmax overloads with an initializer_list is +pair<const T&, const T&>, +which is inconsistent with the decision for the other min/max overloads which take +a initializer_list as argument and return a T, not a const T&. +Doing otherwise for minmax would easily lead to unexpected life-time +problems by using minmax instead of min and max separately. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++
+ + + + + + +- +
++In 25 [algorithms]/2, header <algorithm> synopsis change as indicated: +
+ ++template<classLessThanComparable T> +requires CopyConstructible<T> +pair<constT&,constT&> +minmax(initializer_list<T> t); + +template<class T,classStrictWeakOrder<auto, T> Compare> +requires CopyConstructible<T> +pair<constT&,constT&> +minmax(initializer_list<T> t, Compare comp); +- +
++In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20): +
++template<+classLessThanComparable T> + requires CopyConstructible<T> + pair<constT&,constT&> + minmax(initializer_list<T> t); +++ ++
+-20- Requires: T is LessThanComparable and +CopyConstructible.++-21- Returns: pair<
+constT&,const +T&>(x, y) where x is the +smallest value and y the largest value in the initializer_list. +[..]
+template<class T,+ +classStrictWeakOrder<auto, T> Compare> + requires CopyConstructible<T> + pair<constT&,constT&> + minmax(initializer_list<T> t, Compare comp); ++++
+-24- Requires: type T is LessThanComparable and CopyConstructible.++-25- Returns: pair<
+constT&,const +T&>(x, y) where x is the +smallest value and y largest value in the initializer_list. +
+916. Redundant move-assignment operator of pair should be removed
+Section: 20.3.3 [pairs] Status: Open + Submitter: Daniel Krügler Opened: 2008-10-04 Last modified: 2009-05-23
+View other active issues in [pairs].
+View all other issues in [pairs].
+View all issues with Open status.
+Discussion:
+see also 917.
+ ++The current WP provides the following assignment operators for pair +in 20.3.3 [pairs]/1: +
+ ++
+ +- +
+template<class U , class V> +requires HasAssign<T1, const U&> && HasAssign<T2, const V&> +pair& operator=(const pair<U , V>& p); ++- +
+requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p ); ++- +
+template<class U , class V> +requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type> +pair& operator=(pair<U , V>&& p); +++It seems that the functionality of (2) is completely covered by (3), therefore +(2) should be removed. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Bill believes the extra assignment operators are necessary for resolving +ambiguities, but that does not mean it needs to be part of the specification. +
++Move to Open. +We recommend this be looked at in the context of the ongoing work +related to the pair templates. +
+Proposed resolution:
++
+ + + + + +- +
+ ++In 20.3.3 [pairs] p. 1, class pair and just before p. 13 remove the declaration: +
+ ++requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p ); +- +Remove p.13+p.14 +
+ +
+917. Redundant move-assignment operator of tuple should be removed
+Section: 20.5.2.1 [tuple.cnstr] Status: Open + Submitter: Daniel Krügler Opened: 2008-10-04 Last modified: 2009-05-23
+View other active issues in [tuple.cnstr].
+View all other issues in [tuple.cnstr].
+View all issues with Open status.
+Discussion:
+see also 916.
++N2770 (and thus now the WP) removed the +non-template move-assignment operator from tuple's class definition, +but the latter individual member description does still provide this +operator. Is this (a) an oversight and can it (b) be solved as part of an +editorial process? +
+ +[ +Post Summit Daniel provided wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + + ++We believe that the proposed resolution's part 1 is editorial. +
++Regarding part 2, we either remove the specification as proposed, +or else add back the declaration to which the specification refers. +Alisdair and Bill prefer the latter. +It is not immediately obvious whether the function is intended to be present. +
++We recommend that the Project Editor restore the missing declaration +and that we keep part 2 of the issue alive. +
++Move to Open. +
+Proposed resolution:
++
+ + + + + +- +
++In 20.5.2 [tuple.tuple], class tuple just before member swap please +change as indicated: +
+[ +This fixes an editorial loss between N2798 to N2800 +]
+ ++template <class... UTypes> +requires HasAssign<Types, const UTypes&>... +tuple& operator=(const pair<UTypes...>&); + +template <class... UTypes> +requires HasAssign<Types, RvalueOf<UTypes>::type>... +tuple& operator=(pair<UTypes...>&&); +- +
++In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove +as indicated: +
+ +++requires MoveAssignable<Types>... tuple& operator=(tuple&& u);++++
+-11- Effects: Move-assigns each element of u to the corresponding +element of *this.++
+-12- Returns: *this.+
+918. Swap for tuple needs to be conceptualized
+Section: 20.5.2.6 [tuple.swap] Status: Tentatively NAD + Submitter: Daniel Krügler Opened: 2008-10-04 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
+Discussion:
++Issue 522 was accepted after tuple had been conceptualized, +therefore this step needs to be completed. +
+ +[ +Post Summit Daniel adds +]
+ + ++This is now NAD Editorial (addressed by +N2844) +except for item 3 in the proposed wording. ++ +[ +2009-05-01 Daniel adds: +]
+ + ++As of the recent WP +(N2857), +this issue is now completely covered by editorial +changes (including the third bullet), therefore I unconditionally recommend +NAD. ++ +[ +Batavia (2009-05): +]
+ +++ + + ++We observed that all the proposed changes have already been applied to the +Working Draft, rendering this issue moot. +
++Move to NAD. +
+Proposed resolution:
++
+ + + + + + +- +
+ ++In both 20.5.1 [tuple.general]/2 and 20.5.2.7 [tuple.special] change +
+ ++ +template <classSwappable... Types> +void swap(tuple<Types...>& x, tuple<Types...>& y); +- +
+ ++In 20.5.2 [tuple.tuple], class tuple definition and in +20.5.2.6 [tuple.swap], change +
+ ++ +requires Swappable<Types>...void swap(tuple&); +- +
+ ++In 20.5.2.6 [tuple.swap] remove the current requires-clause, which says: +
+ +++Requires: Each type in Types shall be Swappable+
+919. (forward_)list specialized remove algorithms are over constrained
+Section: 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] Status: Review + Submitter: Daniel Krügler Opened: 2008-10-06 Last modified: 2009-05-23
+View other active issues in [forwardlist.ops].
+View all other issues in [forwardlist.ops].
+View all issues with Review status.
+Discussion:
++The signatures of forwardlist::remove and list::remove +defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15: +
+ ++ +requires EqualityComparable<T> void remove(const T& value); ++are asymmetric to their predicate variants (which only require +Predicate, not EquivalenceRelation) and with the free algorithm +remove (which only require HasEqualTo). Also, nothing in the +pre-concept WP +N2723 +implies that EqualityComparable should +be the intended requirement. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution, +but would like additional input from concepts experts. +
++Move to Review. +
+Proposed resolution:
++
+ + + + + + +- +
++Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15 +
+ ++requiresEqualityComparable<T>HasEqualTo<T, T> void remove(const T& value); +
+920. Ref-qualification support in the library
+Section: 20.7.15 [func.memfn] Status: Open + Submitter: Bronek Kozicki Opened: 2008-10-06 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++Daniel Krügler wrote: +
+ +++ ++Shouldn't above list be completed for &- and &&-qualified +member functions This would cause to add: +
++ +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const volatile &&); ++yes, absolutely. Thanks for spotting this. Without this change mem_fn +cannot be initialized from pointer to ref-qualified member function. I +believe semantics of such function pointer is well defined. +
+ +[ +Post Summit Daniel provided wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++We need to think about whether we really want to go down the proposed path +of combinatorial explosion. +Perhaps a Note would suffice. +
++We would really like to have an implementation before proceeding. +
++Move to Open, and recommend this be deferred until after the next +Committee Draft has been issued. +
+Proposed resolution:
++
+- +
++In 20.7 [function.objects]/2, header <functional> synopsis, just after +the section "// 20.6.15, member function adaptors::" add the following +declarations to the existing list: +
++template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const volatile &&); +- +
++In 20.7.15 [func.memfn] add the following declarations to the existing +list: +
++template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> + unspecified mem_fn(R (T::* pm)(Args...) const volatile &&); ++The following text, most notably p.2 and p.3 which discuss influence +of the cv-qualification on the definition of the base class's first template +parameter remains unchanged. +
+ + + + + +
+921. Rational Arithmetic should use template aliases
+Section: 20.4.1 [ratio.ratio] Status: Review + Submitter: Pablo Halpern Opened: 2008-10-07 Last modified: 2009-05-23
+View other active issues in [ratio.ratio].
+View all other issues in [ratio.ratio].
+View all issues with Review status.
+Discussion:
++The compile-time functions that operate on ratio<N,D> require the +cumbersome and error-prone "evaluation" of a type member using a +meta-programming style that predates the invention of template aliases. +Thus, multiplying three ratios a, b, and c requires the expression: +
+ ++ +ratio_multiply<a, ratio_multiply<b, c>::type>::type ++The simpler expression: +
+ ++ +ratio_multiply<a, ratio_multiply<b, c>> ++Could be used by if template aliases were employed in the definitions. +
+ +[ +Post Summit: +]
+ + +++ ++Jens: not a complete proposed resolution: "would need to make similar change" +
++Consensus: We agree with the direction of the issue. +
++Recommend Open. +
+[ +2009-05-11 Daniel adds: +]
+ + +++ ++Personally I'm not in favor for the addition of: +
++typedef ratio type; ++For a reader of the +standard it's usage or purpose is unclear. I haven't seen similar examples +of attempts to satisfy non-feature complete compilers. +
+[ +2009-05-11 Pablo adds: +]
+ + +++ ++The addition of type to the ratio template allows the previous style +(i.e., in the prototype implementations) to remain valid and permits the +use of transitional library implementations for C++03 compilers. I do +not feel strongly about its inclusion, however, and leave it up to the +reviewers to decide. +
+[ +Batavia (2009-05): +]
+ ++Bill asks for additional discussion in the issue +that spells out more details of the implementation. +Howard points us to issue 948 +which has at least most of the requested details. +Tom is strongly in favor of overflow-checking at compile time. +Pete points out that there is no change of functionality implied. +We agree with the proposed resolution, +but recommend moving the issue to Review +to allow time to improve the discussion if needed. ++ + +Proposed resolution:
+ + ++
+ + + + + +- +
++In 20.4 [ratio]/3 change as indicated: +
+ ++// ratio arithmetic +template <class R1, class R2>structusing ratio_add = see below; +template <class R1, class R2>structusing ratio_subtract = see below; +template <class R1, class R2>structusing ratio_multiply = see below; +template <class R1, class R2>structusing ratio_divide = see below; +- +
++In 20.4.1 [ratio.ratio], change as indicated: +
++namespace std { + template <intmax_t N, intmax_t D = 1> + class ratio { + public: + typedef ratio type; + static const intmax_t num; + static const intmax_t den; + }; +} +- +
++In 20.4.2 [ratio.arithmetic] change as indicated: +
+ ++template <class R1, class R2>+ +structusing ratio_add = see below{ + typedef see below type; +}; ++++1 The
+nested typedeftype ratio_add<R1, R2> +shall be a synonym for ratio<T1, T2> +where T1 has the value R1::num * R2::den + R2::num * R1::den and T2 +has the value R1::den * R2::den. ++template <class R1, class R2>+structusing ratio_subtract = see below{ + typedef see below type; +}; ++++2 The
+nested typedeftype ratio_subtract<R1, R2> +shall be a synonym for ratio<T1, T2> +where T1 has the value R1::num * R2::den - R2::num * R1::den and T2 +has the value R1::den * R2::den. ++template <class R1, class R2>+structusing ratio_multiply = see below{ + typedef see below type; +}; ++++3 The
+nested typedeftype ratio_multiply<R1, R2> +shall be a synonym for ratio<T1, T2> +where T1 has the value R1::num * R2::num and T2 has the value R1::den * R2::den. ++template <class R1, class R2>+structusing ratio_divide = see below{ + typedef see below type; +}; ++++4 The
+nested typedeftype ratio_divide<R1, R2> +shall be a synonym for ratio<T1, T2> +where T1 has the value R1::num * R2::den and T2 has the value R1::den * R2::num. +- +
++In 20.9.3.1 [time.duration.cons]/4 change as indicated: +
++++Requires: treat_as_floating_point<rep>::value shall be true or +ratio_divide<Period2, period>::
+type::den shall be 1.[..] +- +
++In 20.9.3.7 [time.duration.cast]/2 change as indicated: +
++++Returns: Let CF be ratio_divide<Period, typename +ToDuration::period>
+::type, and [..] +
+922. [func.bind.place] Number of placeholders
+Section: B [implimits] Status: Tentatively Ready + Submitter: Sohail Somani Opened: 2008-10-11 Last modified: 2009-03-13
+View all issues with Tentatively Ready status.
+Discussion:
+Addresses DE 24
+ ++With respect to the section 20.7.12.1.4 [func.bind.place]: +
++TR1 dropped some suggested implementation quantities for the number of +placeholders. The purpose of this defect is to put these back for C++0x. +
+ +[ +Post Summit: +]
+ + +++ +Original proposed resolution: + ++see DE 24 +
++Recommend applying the proposed resolution from DE 24, with that +Tentatively Ready. +
++Add 20.7.12.1.4 [func.bind.place]/2: +
+ ++While the exact number of placeholders (_M) is implementation defined, +this number shall be at least 10. ++ + + +Proposed resolution:
+ ++Add to B [implimits]: +
+ ++
+ + + + + + +- +Number of placeholders (20.7.12.1.4 [func.bind.place]) [10]. +
+
+923. atomics with floating-point
+Section: 29 [atomics] Status: Open + Submitter: Herb Sutter Opened: 2008-10-17 Last modified: 2009-05-01
+View other active issues in [atomics].
+View all other issues in [atomics].
+View all issues with Open status.
+Discussion:
++Right now, C++0x doesn't have atomic<float>. We're thinking of adding +the words to support it for TR2 (note: that would be slightly +post-C++0x). If we need it, we could probably add the words. +
++Proposed resolutions: Using atomic<FP>::compare_exchange (weak or +strong) should be either: +
+ ++
+ +- +ill-formed, or +
+- +well-defined. +
++I propose Option 1 for C++0x for expediency. If someone wants to argue +for Option 2, they need to say what exactly they want compare_exchange +to mean in this case (IIRC, C++0x doesn't even assume IEEE 754). +
+ +[ +Summit: +]
+ + ++Move to open. Blocked until concepts for atomics are addressed. ++ +[ +Post Summit Anthony adds: +]
+ + +++ + + ++Recommend NAD. C++0x does have std::atomic<float>, and both +compare_exchange_weak and compare_exchange_strong are well-defined in +this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to: +
+ +++ ++[Note: The effect of the compare-and-exchange operations is +
++ +if (!memcmp(object,expected,sizeof(*object))) + *object = desired; +else + *expected = *object; ++This may result in failed comparisons for values that compare equal if +the underlying type has padding bits or alternate representations of +the same value. -- end note] +
+Proposed resolution:
++Change the note in 29.6 [atomics.types.operations] paragraph 20 to: +
+ +++ + + + + + ++[Note: The effect of the compare-and-exchange operations is +
++ +if (*object == *expected!memcmp(object,expected,sizeof(*object))) + *object = desired; +else + *expected = *object; ++This may result in failed comparisons for values that compare equal if +the underlying type has padding bits or alternate representations of +the same value. -- end note] +
+
+924. structs with internal padding
+Section: 29 [atomics] Status: Open + Submitter: Herb Sutter Opened: 2008-10-17 Last modified: 2009-03-22
+View other active issues in [atomics].
+View all other issues in [atomics].
+View all issues with Open status.
+Discussion:
++Right now, the compare_exchange_weak loop should rapidly converge on the +padding contents. But compare_exchange_strong will require a bit more +compiler work to ignore padding for comparison purposes. +
++Note that this isn't a problem for structs with no padding, and we do +already have one portable way to ensure that there is no padding that +covers the key use cases: Have elements be the same type. I suspect that +the greatest need is for a structure of two pointers, which has no +padding problem. I suspect the second need is a structure of a pointer +and some form of an integer. If that integer is intptr_t, there will be +no padding. +
++Related but separable issue: For unused bitfields, or other unused +fields for that matter, we should probably say it's the programmer's +responsibility to set them to zero or otherwise ensure they'll be +ignored by memcmp. +
+ ++Proposed resolutions: Using +atomic<struct-with-padding>::compare_exchange_strong should be either: +
+ ++
+ +- +ill-formed, or +
+- +well-defined. +
++I propose Option 1 for C++0x for expediency, though I'm not sure how to +say it. I would be happy with Option 2, which I believe would mean that +compare_exchange_strong would be implemented to avoid comparing padding +bytes, or something equivalent such as always zeroing out padding when +loading/storing/comparing. (Either implementation might require compiler +support.) +
+ +[ +Summit: +]
+ + ++Move to open. Blocked until concepts for atomics are addressed. ++ +[ +Post Summit Anthony adds: +]
+ + ++The resoultion of LWG 923 should resolve this issue as well. ++ + + +Proposed resolution:
++
+ + + + + +
+925. shared_ptr's explicit conversion from unique_ptr
+Section: 20.8.13.2.1 [util.smartptr.shared.const] Status: Tentatively Ready + Submitter: Rodolfo Lima Opened: 2008-10-12 Last modified: 2009-05-23
+View other active issues in [util.smartptr.shared.const].
+View all other issues in [util.smartptr.shared.const].
+View all issues with Tentatively Ready status.
+Discussion:
++The current working draft +(N2798), +section 20.8.13.2.1 [util.smartptr.shared.const] declares +shared_ptr's constructor that takes a rvalue reference to unique_ptr and +auto_ptr as being explicit, affecting several valid smart pointer use +cases that would take advantage of this conversion being implicit, for +example: +
+ ++ +class A; +std::unique_ptr<A> create(); +void process(std::shared_ptr<A> obj); + +int main() +{ + process(create()); // use case #1 + std::unique_ptr<A> uobj = create(); + process(std::move(uobj)); // use case #2 + return 0; +} ++If unique_ptr to shared_ptr conversions are explicit, the above lines +should be written: +
+ ++ +process(std::shared_ptr<A>(create())); // use case #1 +process(std::shared_ptr<A>(std::move(uobj))); // use case #2 ++The extra cast required doesn't seems to give any benefits to the user, +nor protects him of any unintended conversions, this being the raison +d'etre of explicit constructors. +
+ ++It seems that this constructor was made explicit to mimic the conversion +from auto_ptr in pre-rvalue reference days, which accepts both lvalue and +rvalue references. Although this decision was valid back then, C++0x +allows the user to express in a clear and non verbose manner when he wants +move semantics to be employed, be it implicitly (use case 1) or explicitly +(use case 2). +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Howard and Alisdair like the motivating use cases +and the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++In both 20.8.13.2 [util.smartptr.shared] paragraph 1 and +20.8.13.2.1 [util.smartptr.shared.const] change: +
+ ++ + + + + + +template <class Y>explicitshared_ptr(auto_ptr<Y> &&r); +template <class Y, class D>explicitshared_ptr(unique_ptr<Y, D> &&r); +
+926. Sequentially consistent fences, relaxed operations and modification order
+Section: 29.3 [atomics.order] Status: Open + Submitter: Anthony Williams Opened: 2008-10-19 Last modified: 2009-03-22
+View all other issues in [atomics.order].
+View all issues with Open status.
+Discussion:
+Addresses UK 313
+ ++There was an interesting issue raised over on comp.programming.threads +today regarding the following example +
+ ++ +// Thread 1: +x.store(1, memory_order_relaxed); // SX +atomic_thread_fence(memory_order_seq_cst); // F1 +y.store(1, memory_order_relaxed); // SY1 +atomic_thread_fence(memory_order_seq_cst); // F2 +r1 = y.load(memory_order_relaxed); // RY + +// Thread 2: +y.store(0, memory_order_relaxed); // SY2 +atomic_thread_fence(memory_order_seq_cst); // F3 +r2 = x.load(memory_order_relaxed); // RX ++is the outcome r1 == 0 and r2 == 0 possible? +
++I think the intent is that this is not possible, but I am not sure the +wording guarantees that. Here is my analysis: +
++Since all the fences are SC, there must be a total order between them. +F1 must be before F2 in that order since they are in +the same thread. Therefore F3 is either before F1, +between F1 and F2 or after F2. +
++If F3 is after F2, then we can apply 29.3 [atomics.order]p5 from +N2798: +
+ ++For atomic operations A and B on an atomic object +M, where A modifies M and B takes +its value, if there are memory_order_seq_cst fences X +and Y such that A is sequenced before X, +Y is sequenced before B, and X precedes +Y in S, then B observes either the effects of +A or a later modification of M in its modification +order. ++ ++In this case, A is SX, B is RX, the +fence X is F2 and the fence Y is F3, +so RX must see 1. +
++If F3 is before F2, this doesn't apply, but +F3 can therefore be before or after F1. +
++If F3 is after F1, the same logic applies, but this +time the fence X is F1. Therefore again, RX +must see 1. +
++Finally we have the case that F3 is before F1 +in the SC ordering. There are now no guarantees about RX, and +RX can see r2==0. +
++We can apply 29.3 [atomics.order]p5 again. This time, +A is SY2, B is RY, X is +F3 and Y is F1. Thus RY must observe +the effects of SY2 or a later modification of y in its +modification order. +
++Since SY1 is sequenced before RY, RY must +observe the effects of SY1 or a later modification of +y in its modification order. +
++In order to ensure that RY sees (r1==1), we must see +that SY1 is later in the modification order of y than +SY2. +
++We're now skating on thin ice. Conceptually, SY2 happens-before +F3, F3 is SC-ordered before F1, F1 +happens-before SY1, so SY1 is later in the +modification order M of y, and RY must see +the result of SY1 (r1==1). However, I don't think the +words are clear on that. +
+ +[ +Post Summit Hans adds: +]
+ + +++ ++In my (Hans') view, our definition of fences will always be weaker than +what particular hardware will guarantee. Memory_order_seq_cst fences +inherently don't guarantee sequential consistency anyway, for good +reasons (e.g. because they can't enforce a total order on stores). + Hence I don't think the issue demonstrates a gross failure to achieve +what we intended to achieve. The example in question is a bit esoteric. + Hence, in my view, living with the status quo certainly wouldn't be a +disaster either. +
++In any case, we should probably add text along the lines of the +following between p5 and p6 in 29.3 [atomics.order]: +
++[Note: Memory_order_seq_cst only ensures sequential consistency for a +data-race-free program that uses exclusively memory_order_seq_cst +operations. Any use of weaker ordering will invalidate this guarantee +unless extreme care is used. In particular, memory_order_seq_cst fences +only ensure a total order for the fences themselves. They cannot, in +general, be used to restore sequential consistency for atomic operations +with weaker ordering specifications.] ++ ++Also see thread beginning at c++std-lib-23271. +
+ +[ +Herve's correction: +]
+ +++ + + ++Minor point, and sorry for the knee jerk reaction: I admit to having +no knowledge of Memory_order_seq_cst, but my former boss (John Lakos) +has ingrained an automatic introspection on the use of "only". I +think you meant: +
+ ++[Note: Memory_order_seq_cst ensures sequential consistency only +for . . . . In particular, memory_order_seq_cst fences ensure a +total order only for . . . +++Unless, of course, Memory_order_seq_cst really do nothing but ensure +sequential consistency for a data-race-free program that uses +exclusively memory_order_seq_cst operations. +
+Proposed resolution:
++Add a new paragraph after 29.3 [atomics.order]p5 that says +
+ ++For atomic operations A and B on an atomic object +M, where A and B modify M, if there +are memory_order_seq_cst fences X and Y such +that A is sequenced before X, Y is sequenced +before B, and X precedes Y in S, +then B occurs later than A in the modifiction order of +M. ++ + + + + +
+927. Dereferenceable should be HasDereference
+Section: 20.8.2.2 [allocator.concepts] Status: Tentatively NAD Editorial + Submitter: Pablo Halpern Opened: 2008-10-23 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++20.8.2.2 [allocator.concepts] contains a reference to a concept named +Dereferenceable. No such concept exists. +
+ +[ +Daniel adds 2009-02-14: +]
+ + ++The proposal given in the paper +N2829 +would automatically resolve this issue. ++ + +[ +Batavia (2009-05): +]
+ +++ + ++This particular set of changes has already been made. +There are two related changes later on (and possibly also an earlier Example); +these can be handled editorially. +
++Move to NAD Editorial. +
+Proposed resolution:
++Change all uses of the concept Dereferenceable to +HasDereference in 20.8.2.2 [allocator.concepts]. +
+ + + + + +
+928. Wrong concepts used for tuple's comparison operators
+Section: 20.5.2.5 [tuple.rel] Status: Tentatively Ready + Submitter: Joe Gottman Opened: 2008-10-28 Last modified: 2009-03-09
+View all other issues in [tuple.rel].
+View all issues with Tentatively Ready status.
+Discussion:
++In the latest working draft for C++0x, tuple's operator== and operator< +are declared as +
+ ++ +template<class... TTypes, class... UTypes> + requires EqualityComparable<TTypes, UTypes>... + bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u); ++and +
+ ++ +template<class... TTypes, class... UTypes> + requires LessThanComparable<TTypes, UTypes>... + bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u); ++But the concepts EqualityComparable and LessThanComparable only take one +parameter, not two. Also, even if LessThanComparable could take two +parameters, the definition of tuple::operator<() should also require +
+ ++ +LessThanComparable<UTypes, TTypes>... // (note the order) ++since the algorithm for tuple::operator< is the following (pseudo-code) +
+ ++ +for (size_t N = 0; N < sizeof...(TTypes); ++N) { + if (get<N>(t) < get<N>(u) return true; + else if ((get<N>(u) < get<N>(t)) return false; +} + +return false; ++Similar problems hold for tuples's other comparison operators. +
+ +[ +Post Summit: +]
+ + ++Recommend Tentatively Ready. ++ + + +Proposed resolution:
++In 20.5.1 [tuple.general] and 20.5.2.5 [tuple.rel] change: +
+ ++ + + + + +template<class... TTypes, class... UTypes> + requiresEqualityComparableHasEqualTo<TTypes, UTypes>... + bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requiresLessThanComparableHasLess<TTypes, UTypes>... && HasLess<UTypes, TTypes>... + bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requiresEqualityComparableHasEqualTo<TTypes, UTypes>... + bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requiresLessThanComparableHasLess<UTTypes,TUTypes>... && HasLess<UTypes, TTypes>... + bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requiresLessThanComparableHasLess<UTTypes,TUTypes>... && HasLess<UTypes, TTypes>... + bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requiresLessThanComparableHasLess<TTypes, UTypes>... && HasLess<UTypes, TTypes>... + bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&); +
+929. Thread constructor
+Section: 30.3.1.2 [thread.thread.constr] Status: Review + Submitter: Anthony Williams Opened: 2008-10-23 Last modified: 2009-05-23
+View other active issues in [thread.thread.constr].
+View all other issues in [thread.thread.constr].
+View all issues with Review status.
+Discussion:
+ +Addresses UK 323
+ ++The thread constructor for starting a new thread with a function and +arguments is overly constrained by the signature requiring rvalue +references for func and args and the CopyConstructible requirements +for the elements of args. The use of an rvalue reference for the +function restricts the potential use of a plain function name, since +the type of the bound parameter will be deduced to be a function +reference and decay to pointer-to-function will not happen. This +therefore complicates the implementation in order to handle a simple +case. Furthermore, the use of rvalue references for args prevents the +array to pointer decay. Since arrays are not CopyConstructible or even +MoveConstructible, this essentially prevents the passing of arrays as +parameters. In particular it prevents the passing of string literals. +Consequently a simple case such as +
+ ++ +void f(const char*); +std::thread t(f,"hello"); ++is ill-formed since the type of the string literal is const char[6]. +
+ ++By changing the signature to take all parameters by value we can +eliminate the CopyConstructible requirement and permit the use of +arrays, as the parameter passing semantics will cause the necessary +array-to-pointer decay. They will also cause the function name to +decay to a pointer to function and allow the implementation to handle +functions and function objects identically. +
+ ++The new signature of the thread constructor for a function and +arguments is thus: +
+ ++ +template<typename F,typename... Args> +thread(F,Args... args); ++Since the parameter pack Args can be empty, the single-parameter +constructor that takes just a function by value is now redundant. +
+ +[ +Howard adds: +]
+ + +++ ++I agree with everything Anthony says in this issue. However I believe we +can optimize in such a way as to get the pass-by-value behavior with the +pass-by-rvalue-ref performance. The performance difference is that the latter +removes a move when passing in an lvalue. +
+ ++This circumstance is very analogous to make_pair (20.3.3 [pairs]) +where we started with passing by const reference, changed to pass by value to +get pointer decay, and then changed to pass by rvalue reference, but modified with +decay<T> to retain the pass-by-value behavior. If we were to +apply the same solution here it would look like: +
+ ++ ++template <class F> explicit thread(F f);+template <class F, class ...Args> thread(F&& f, Args&&... args); ++++-4- Requires: F and each Ti in Args shall be
+CopyConstructible +if an lvalue and otherwiseMoveConstructible. +INVOKE(f, w1, w2, ..., wN) (20.7.2 [func.require]) shall be a valid expression for +some values w1, w2, ... , wN, where N == sizeof...(Args). ++-5- Effects: Constructs an object of type thread +
+and executes INVOKE(f, t1, t2, ..., tN) in a new +thread of execution, where t1, t2, ..., tN are the values in args.... +Constructs +the following objects in memory which is accessible to a new thread of execution +as if: ++typename decay<F>::type g(std::forward<F>(f)); +tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...); ++The new thread of +execution executes INVOKE(g, wi...) where the wi... refers +to the elements stored in the tuple w. +Any return value from g is ignored. +
+If f terminates with an uncaught exception, std::terminate() shall be called.+If the evaluation of INVOKE(g, wi...) terminates +with an uncaught exception, std::terminate() shall be called [Note: +std::terminate() could be called before entering g. -- end note]. Any +exception thrown before the evaluation of INVOKE has started shall be +catchable in the calling thread. ++Text referring to when terminate() is called was contributed by Ganesh. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution, +but would like the final sentence to be reworded +since "catchable" is not a term of art (and is used nowhere else). ++ + +Proposed resolution:
++Modify the class definition of std::thread in 30.3.1 [thread.thread.class] to remove the +following signature: +
+ ++ +template<class F> explicit thread(F f);+template<class F, class ... Args> explicit thread(F&& f, Args&& ... args); ++Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with +the single constructor as above. Replace paragraph 4 - 6 with the +following: +
+ +++ + + + + + ++-4- Requires: F and each Ti in Args shall be
+CopyConstructible +if an lvalue and otherwiseMoveConstructible. +INVOKE(f, w1, w2, ..., wN) (20.7.2 [func.require]) shall be a valid expression for +some values w1, w2, ... , wN, where N == sizeof...(Args). ++-5- Effects: Constructs an object of type thread +
+and executes INVOKE(f, t1, t2, ..., tN) in a new +thread of execution, where t1, t2, ..., tN are the values in args.... +Constructs +the following objects: ++typename decay<F>::type g(std::forward<F>(f)); +tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...); ++and executes INVOKE(g, wi...) in a new thread of execution. +These objects shall be destroyed when the new thread of execution completes. +Any return value from g is ignored. +
+If f terminates with an uncaught exception, std::terminate() shall be called.+If the evaluation of INVOKE(g, wi...) terminates +with an uncaught exception, std::terminate() shall be called [Note: +std::terminate() could be called before entering g. -- end note]. Any +exception thrown before the evaluation of INVOKE has started shall be +catchable in the calling thread. ++-6- Synchronization: The invocation of the constructor happens before the +invocation of
+fg. +
+930. Access to std::array data as built-in array type
+Section: 23.3.1 [array] Status: Open + Submitter: Niels Dekker Opened: 2008-11-17 Last modified: 2009-06-01
+View other active issues in [array].
+View all other issues in [array].
+View all issues with Open status.
+Discussion:
+ ++The Working Draft (N2798) allows access to the elements of +std::array by its data() member function: +
+ ++ ++ +23.2.1.4 array::data [array.data]
+T *data(); + const T *data() const; +++
- + Returns: elems. +
+Unfortunately, the result of std::array::data() cannot be bound +to a reference to a built-in array of the type of array::elems. +And std::array provides no other way to get a reference to +array::elems. +This hampers the use of std::array, for example when trying to +pass its data to a C style API function: +
+ +// Some C style API function. + void set_path( char (*)[MAX_PATH] ); + + std::array<char,MAX_PATH> path; + set_path( path.data() ); // error + set_path( &(path.data()) ); // error ++ ++Another example, trying to pass the array data to an instance of another +C++ class: +
+ +// Represents a 3-D point in space. + class three_d_point { + public: + explicit three_d_point(const double (&)[3]); + }; + + const std::array<double,3> coordinates = { 0, 1, 2 }; + three_d_point point1( coordinates.data() ); // error. + three_d_point point2( *(coordinates.data()) ); // error. ++ ++A user might be tempted to use std::array::elems instead, but +doing so isn't recommended, because std::array::elems is "for +exposition only". Note that Boost.Array users might already use +boost::array::elems, as its documentation doesn't explicitly +state that boost::array::elems is for exposition only: +http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html +
++I can think of three options to solve this issue: +
++
- +Remove the words "exposition only" from the definition of +std::array::elems, as well as the note saying that "elems is +shown for exposition only." +
- +Change the signature of std::array::data(), so that it would +return a reference to the built-in array, instead of a pointer to its +first element. +
- +Add extra member functions, returning a reference to the built-in array. +
+Lawrence Crowl wrote me that it might be better to leave +std::array::elems "for exposition only", to allow alternate +representations to allocate the array data dynamically. This might be +of interest to the embedded community, having to deal with very limited +stack sizes. +
++The second option, changing the return type of +std::array::data(), would break backward compatible to current +Boost and TR1 implementations, as well as to the other contiguous +container (vector and string) in a very subtle way. +For example, the following call to std::swap currently swap two +locally declared pointers (data1, data2), for any container +type T that has a data() member function. When +std::array::data() is changed to return a reference, the +std::swap call may swap the container elements instead. +
+ +template <typename T> + void func(T& container1, T& container2) + { + // Are data1 and data2 pointers or references? + auto data1 = container1.data(); + auto data2 = container2.data(); + + // Will this swap two local pointers, or all container elements? + std::swap(data1, data2); + } ++ ++The following concept is currently satisfied by all contiguous +containers, but it no longer is for std::array, when +array::data() +is changed to return a reference (tested on ConceptGCC Alpha 7): +
+ +auto concept ContiguousContainerConcept<typename T> + { + typename value_type = typename T::value_type; + const value_type * T::data() const; + } ++ ++Still it's worth considering having std::array::data() return a +reference, because it might be the most intuitive option, from a user's +point of view. Nicolai Josuttis (who wrote boost::array) +mailed me that he very much prefers this option. +
++Note that for this option, the definition of data() would also +need to be revised for zero-sized arrays, as its return type cannot be a +reference to a zero-sized built-in array. Regarding zero-sized array, +data() could throw an exception. Or there could be a partial +specialization of std::array where data() returns +T* or gets removed. +
++Personally I prefer the third option, adding a new member function to +std::array, overloaded for const and non-const access, +returning a reference to the built-in array, to avoid those compatible +issues. I'd propose naming the function std::array::c_array(), +which sounds intuitive to me. Note that boost::array already +has a c_array() member, returning a pointer, but Nicolai told +me that this one is only there for historical reasons. (Otherwise a name +like std::array::native_array() or +std::array::builtin_array() would also be fine with me.) +According to my proposed resolution, a zero-sized std::array does not need +to have c_array(), while it is still required to have +data() functions. +
+ +[ +Post Summit: +]
+ + ++ ++ ++Alisdair: Don't like p4 suggesting implementation-defined behaviour. +
++Walter: What about an explicit conversion operator, instead of adding +the new member function? +
++Alisdair: Noodling about: +
++ +template<size_t N, ValueType T> +struct array +{ + T elems[N]; + +// fantasy code starts here + +// crazy decltype version for grins only +//requires True<(N>0)> +//explict operator decltype(elems) & () { return elems; } + +// conversion to lvalue ref +requires True<(N>0)> +explict operator T(&)[N] () & { return elems; } + +// conversion to const lvalue ref +requires True<(N>0)> +explict operator const T(&)[N] () const & { return elems; } + +// conversion to rvalue ref using ref qualifiers +requires True<(N>0)> +explict operator T(&&)[N] () && { return elems; } + +// fantasy code ends here + +explicit operator bool() { return true; } +}; ++This seems legal but odd. Jason Merrill says currently a CWG issue 613 +on the non-static data member that fixes the error that current G++ +gives for the non-explicit, non-conceptualized version of this. Verdict +from human compiler: seems legal. +
++Some grumbling about zero-sized arrays being allowed and supported. +
++Walter: Would this address the issue? Are we inclined to go this route? +
++Alan: What would usage look like? +
++ +// 3-d point in space +struct three_d_point +{ + explicit three_d_point(const double (&)[3]); +}; + +void sink(double*); + +const std::array<double, 3> coordinates = { 0, 1, 2 }; +three_d_point point1( coordinates.data() ); //error +three_d_point point2( *(coordinates.data()) ); // error +three_d_point point3( coordinates ); // yay! + +sink(cooridinates); // error, no conversion ++Recommended Open with new wording. Take the required clause and add the +explicit conversion operators, not have a typedef. At issue still is use +decltype or use T[N]. In favour of using T[N], even though use of +decltype is specially clever. +
+ +[ +Post Summit, further discussion in the thread starting with c++std-lib-23215. +]
+ + + + +Proposed resolution:
++Add to the template definition of array, 23.3.1 [array]/3: +
+ +++ ++typedef T c_array_type[N]; +c_array_type & c_array() &; +c_array_type && c_array() &&; +const c_array_type & c_array() const &; + +++Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]: +
+ +++ +23.2.1.5 array::c_array [array.c_array]
++c_array_type & c_array() &; +c_array_type && c_array() &&; +const c_array_type & c_array() const &; ++++ ++Returns: elems. +
++Add to Zero sized arrays 23.3.1.6 [array.zero]: +
+ ++4. The presence of c_array_type and c_array() and +their semantics are implementation defined, for a zero-sized array. ++ + + + + +
+931. type trait extent<T, I>
+Section: 20.6.4.3 [meta.unary.prop] Status: Tentatively Ready + Submitter: Yechezkel Mett Opened: 2008-11-04 Last modified: 2009-03-09
+View other active issues in [meta.unary.prop].
+View all other issues in [meta.unary.prop].
+View all issues with Tentatively Ready status.
+Discussion:
++The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44: +
+++ ++
+Table 44 -- Type property queries ++ Template Value + ++template <class T, unsigned I = 0> struct extent; + ++If T is not an array type (8.3.4), or if it has rank less than +I, or if I is 0 +and T has type "array of unknown bound of U", then 0; otherwise, the +size of the I'th dimension of T + ++Firstly it isn't clear from the wording if I is 0-based or 1-based +("the I'th dimension" sort of implies 1-based). From the following +example it is clear that the intent is 0-based, in which case it +should say "or if it has rank less than or equal to I". +
++Sanity check: +
++The example says assert((extent<int[2], 1>::value) == 0); +
++Here the rank is 1 and I is 1, but the desired result is 0. +
+ +[ +Post Summit: +]
+ + +++ + + ++Do not use "size" or "value", use "bound". Also, move the +cross-reference to 8.3.4 to just after "bound". +
++Recommend Tentatively Ready. +
+Proposed resolution:
++In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value", +change the cell content: +
+ +++ ++
+Table 44 -- Type property queries ++ Template Value + ++template <class T, unsigned I = 0> struct extent; + ++If T is not an array type +(8.3.4), or if it has rank less than + or equal to I, or if I is 0 +and T has type "array of unknown bound of U", then 0; otherwise, the +sizebound (8.3.4) of the I'th dimension of T, +where indexing of I is zero-based. +[ +Wording supplied by Daniel. +]
+ + + + + + + +
+932. unique_ptr(pointer p) for pointer deleter types
+Section: 20.8.12.2.1 [unique.ptr.single.ctor] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2008-11-26 Last modified: 2009-03-12
+View other active issues in [unique.ptr.single.ctor].
+View all other issues in [unique.ptr.single.ctor].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses US 79
+ ++20.8.12.2.1 [unique.ptr.single.ctor]/5 no longer requires for D +not to be a pointer type. I believe this restriction was accidently removed +when we relaxed the completeness reuqirements on T. The restriction +needs to be put back in. Otherwise we have a run time failure that could +have been caught at compile time: +
+ ++ +{ +unique_ptr<int, void(*)(void*)> p1(malloc(sizeof(int))); // should not compile +} // p1.~unique_ptr() dereferences a null function pointer +unique_ptr<int, void(*)(void*)> p2(malloc(sizeof(int)), free); // ok +[ +Post Summit: +]
+ + ++Recommend Tentatively Ready. ++ + + +Proposed resolution:
++Change 20.8.12.2.1 [unique.ptr.single.ctor]/5: +
+ ++ + + + + +unique_ptr(pointer p); +++Requires: D shall not be a pointer type (diagnostic required). +D shall be default constructible, and that construction shall not throw an exception. ++
+933. Unique_ptr defect
+Section: 20.8.12.2.5 [unique.ptr.single.modifiers] Status: Open + Submitter: Alisdair Meredith Opened: 2008-11-27 Last modified: 2009-05-23
+View other active issues in [unique.ptr.single.modifiers].
+View all other issues in [unique.ptr.single.modifiers].
+View all issues with Open status.
+Discussion:
++If we are supporting stateful deleters, we need an overload for +reset that +takes a deleter as well. +
+ ++ +void reset( pointer p, deleter_type d); ++We probably need two overloads to support move-only deleters, and +this +sounds uncomfortably like the two constructors I have been ignoring +for +now... +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Howard comments that we have the functionality via move-assigment. +
++Move to Open. +
+Proposed resolution:
++
+ + + + + +
+934. duration is missing operator%
+Section: 20.9.3 [time.duration] Status: Tentatively Ready + Submitter: Terry Golubiewski Opened: 2008-11-30 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses US 81
+ ++duration is missing operator%. This operator is convenient +for computing where in a time frame a given duration lies. A +motivating example is converting a duration into a "broken-down" +time duration such as hours::minutes::seconds: +
+ ++ +class ClockTime +{ + typedef std::chrono::hours hours; + typedef std::chrono::minutes minutes; + typedef std::chrono::seconds seconds; +public: + hours hours_; + minutes minutes_; + seconds seconds_; + + template <class Rep, class Period> + explicit ClockTime(const std::chrono::duration<Rep, Period>& d) + : hours_ (std::chrono::duration_cast<hours> (d)), + minutes_(std::chrono::duration_cast<minutes>(d % hours(1))), + seconds_(std::chrono::duration_cast<seconds>(d % minutes(1))) + {} +}; +[ +Summit: +]
+ + ++Agree except that there is a typo in the proposed resolution. The member +operators should be operator%=. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Add to the synopsis in 20.9 [time]: +
+ ++ +template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator%(const duration<Rep1, Period>& d, const Rep2& s); +template <class Rep1, class Period1, class Rep2, class Period2> + typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type + operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs); ++Add to the synopsis of duration in 20.9.3 [time.duration]: +
+ ++ +template <class Rep, class Period = ratio<1>> +class duration { +public: + ... + duration& operator%=(const rep& rhs); + duration& operator%=(const duration& d); + ... +}; ++Add to 20.9.3.3 [time.duration.arithmetic]: +
+ +++ +duration& operator%=(const rep& rhs); ++++ ++Effects: rep_ %= rhs. +
++Returns: *this. +
+duration& operator%=(const duration& d); +++++Effects: rep_ %= d.count(). +
++Returns: *this. +
++Add to 20.9.3.5 [time.duration.nonmember]: +
+ ++ ++ + + + + + +template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator%(const duration<Rep1, Period>& d, const Rep2& s); ++++ ++Requires: Rep2 shall be implicitly convertible to CR(Rep1, Rep2) and +Rep2 shall not be an instantiation of duration. Diagnostic required. +
++Returns: duration<CR, Period>(d) %= s. +
+template <class Rep1, class Period1, class Rep2, class Period2> + typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type + operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs); ++++ ++Returns: common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type(lhs) %= rhs. +
+
+935. clock error handling needs to be specified
+Section: 20.9.5 [time.clock] Status: Open + Submitter: Beman Dawes Opened: 2008-11-24 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++Each of the three clocks specified in Clocks 20.9.5 [time.clock] +provides the member function: +
+ ++ +static time_point now(); ++The semantics specified by Clock requirements 20.9.1 [time.clock.req] +make no mention of error handling. Thus the function may throw bad_alloc +or an implementation-defined exception (17.6.4.10 [res.on.exception.handling] +paragraph 4). +
+ ++Some implementations of these functions on POSIX, Windows, and +presumably on other operating systems, may fail in ways only detectable +at runtime. Some failures on Windows are due to supporting chipset +errata and can even occur after successful calls to a clock's now() +function. +
+ ++These functions are used in cases where exceptions are not appropriate +or where the specifics of the exception or cause of error need to be +available to the user. See +N2828, +Library Support for hybrid error +handling (Rev 1), for more specific discussion of use cases. Thus some change in +the interface of now is required. +
+ ++The proposed resolution has been implemented in the Boost version of the +chrono library. No problems were encountered. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We recommend this issue be deferred until the next Committee Draft +has been issued and the prerequisite paper has been accepted. +
++Move to Open. +
+Proposed resolution:
++Accept the proposed wording of +N2828, +Library Support for hybrid error handling (Rev 1). +
+ ++Change Clock requirements 20.9.1 [time.clock.req] as indicated: +
+ +++ ++-2- In Table 55 C1 and C2 denote clock types. t1 and +t2 are values returned by C1::now() where the call +returning t1 happens before (1.10) the call returning t2 and +both of these calls happen before C1::time_point::max(). +ec denotes an object of type error_code +(19.5.2.2 [syserr.errcode.overview]). +
+ ++
+Table 55 -- Clock requirements ++ + +Expression Return type Operational semantics ++ + +... +... +... ++ + +C1::now() +C1::time_point +Returns a time_point object representing the current point in time. + ++ +C1::now(ec) +C1::time_point +Returns a time_point object representing the current point in time. + ++Change Class system_clock 20.9.5.1 [time.clock.system] as indicated: +
+ ++ +static time_point now(error_code& ec=throws()); ++Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated: +
+ ++ +static time_point now(error_code& ec=throws()); ++Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated: +
+ ++ + + + + + +static time_point now(error_code& ec=throws()); +
+936. Mutex type overspecified
+Section: 30.4.1 [thread.mutex.requirements] Status: Open + Submitter: Pete Becker Opened: 2008-12-05 Last modified: 2009-03-22
+View other active issues in [thread.mutex.requirements].
+View all other issues in [thread.mutex.requirements].
+View all issues with Open status.
+Discussion:
++30.4.1 [thread.mutex.requirements] describes the requirements for a type to be +a "Mutex type". A Mutex type can be used as the template argument for +the Lock type that's passed to condition_variable_any::wait (although +Lock seems like the wrong name here, since Lock is given a different +formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say +so, as the template argument for lock_guard and unique_lock. +
+ ++The requirements for a Mutex type include: +
+ ++
+ +- +m.lock() shall be well-formed and have [described] semantics, including a return type of void. +
+- +m.try_lock() shall be well-formed and have [described] semantics, including a return type of bool. +
+- +m.unlock() shall be well-formed and have [described] semantics, including a return type of void. +
++Also, a Mutex type "shall not be copyable nor movable". +
+ ++The latter requirement seems completely irrelevant, and the three +requirements on return types are tighter than they need to be. For +example, there's no reason that lock_guard can't be instantiated with a +type that's copyable. The rule is, in fact, that lock_guard, etc. won't +try to copy objects of that type. That's a constraint on locks, not on +mutexes. Similarly, the requirements for void return types are +unnecessary; the rule is, in fact, that lock_guard, etc. won't use any +returned value. And with the return type of bool, the requirement should +be that the return type is convertible to bool. +
+ +[ +Summit: +]
+ + +++ ++Move to open. Related to conceptualization and should probably be tackled as part of that. +
++
+- +The intention is not only to place a constraint on what types such as +lock_guard may do with mutex types, but on what any code, including user +code, may do with mutex types. Thus the constraints as they are apply to +the mutex types themselves, not the current users of mutex types in the +standard. +
+- +This is a low priority issue; the wording as it is may be overly +restrictive but this may not be a real issue. +
+[ +Post Summit Anthony adds: +]
+ + +++ + + ++Section 30.4.1 [thread.mutex.requirements] conflates the +requirements on a generic Mutex type (including user-supplied mutexes) +with the requirements placed on the standard-supplied mutex types in an +attempt to group everything together and save space. +
++When applying concepts to chapter 30, I suggest that the concepts +Lockable and TimedLockable embody the requirements for +*use* of a mutex type as required by +unique_lock/lock_guard/condition_variable_any. These should be +relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of +std::mutex, std::timed_mutex, +std::recursive_mutex and std::recursive_timed_mutex, +and should be rephrased as such. +
+Proposed resolution:
++
+ + + + + +
+938. default_delete<T[]>::operator() should only accept T*
+Section: 20.8.12.1.2 [unique.ptr.dltr.dflt1] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2008-12-07 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++Consider: +
+ ++ +derived* p = new derived[3]; +std::default_delete<base[]> d; +d(p); // should fail ++Currently the marked line is a run time failure. We can make it a compile +time failure by "poisoning" op(U*). +
+ +[ +Post Summit: +]
+ + ++Recommend Review. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Add to 20.8.12.1.2 [unique.ptr.dltr.dflt1]: +
+ ++ + + + + +namespace std { + template <class T> struct default_delete<T[]> { + void operator()(T*) const; + template <class U> void operator()(U*) const = delete; +}; +} +
+939. Problem with std::identity and reference-to-temporaries
+Section: 20.7.6 [identity.operation] Status: Review + Submitter: Alisdair Meredith Opened: 2008-12-11 Last modified: 2009-06-02
+View all issues with Review status.
+Discussion:
++std::identity takes an argument of type T const & +and returns a result of T const &. +
++Unfortunately, this signature will accept a value of type other than T that +is convertible-to-T, and then return a reference to the dead temporary. The +constraint in the concepts version simply protects against returning +reference-to-void. +
++Solutions: +
++++i/ Return-by-value, potentially slicing bases and rejecting non-copyable +types +
++ii/ Provide an additional overload: +
++template< typename T > +template operator( U & ) = delete; ++This seems closer on intent, but moves beyond the original motivation for +the operator, which is compatibility with existing (non-standard) +implementations. +
++iii/ Remove the operator() overload. This restores the original definition +of the identity, although now effectively a type_trait rather than part of +the perfect forwarding protocol. +
++iv/ Remove std::identity completely; its original reason to exist is +replaced with the IdentityOf concept. +
++My own preference is somewhere between (ii) and (iii) - although I stumbled +over the issue with a specific application hoping for resolution (i)! +
+ +[ +Batavia (2009-05): +]
+ +++ ++We dislike options i and iii, and option ii seems like overkill. +If we remove it (option iv), implementers can still provide it under a +different name. +
++Move to Open pending wording (from Alisdair) for option iv. +
+[ +2009-05-23 Alisdair provided wording for option iv. +]
+ + + + +Proposed resolution:
++Strike 20.2.1 [concept.transform] p3: +
+ +++ +-4- Note: concept form of the identity type metafunction (20.7.6).++Strike from 20.7 [function.objects] p2: +
+ ++ +// 20.7.6, identity operation:+template <IdentityOf T> struct identity;++Remove 20.7.6 [identity.operation] (whole subclause): +
+ +++ + + + + + ++template <IdentityOf 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;+++-1- Returns: x+
+940. std::distance
+Section: 24.4 [iterator.operations] Status: Tentatively Ready + Submitter: Thomas Opened: 2008-12-14 Last modified: 2009-05-23
+View other active issues in [iterator.operations].
+View all other issues in [iterator.operations].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 270
+ ++Regarding the std::distance - function, 24.4 [iterator.operations] +/ 4 says: +
++Returns the +number of increments or decrements needed to get from first to last. +++This sentence is completely silent about the sign of the return value. +24.4 [iterator.operations] / 1 gives more information about the +underlying operations, but +again no inferences about the sign can be made. +Strictly speaking, that is taking that sentence literally, I think this +sentence even implies a positive return value in all cases, as the +number of increments or decrements is clearly a ratio scale variable, +with a natural zero bound. +
++Practically speaking, my implementations did what common sense and +knowledge based on pointer arithmetic forecasts, namely a positive sign +for increments (that is, going from first to last by operator++), and a +negative sign for decrements (going from first to last by operator--). +
++Here are my two questions: +
++First, is that paragraph supposed to be interpreted in the way what I +called 'common sense', that is negative sign for decrements ? I am +fairly sure that's the supposed behavior, but a double-check here in +this group can't hurt. +
++Second, is the present wording (2003 standard version - no idea about +the draft for the upcoming standard) worth an edit to make it a bit more +sensible, to mention the sign of the return value explicitly ? +
+ +[ +Daniel adds: +]
+ + +++ ++My first thought was that resolution 204 would already cover the +issue report, but it seems that current normative wording is in +contradiction to that resolution: +
+ ++Referring to +N2798, +24.4 [iterator.operations]/ p.4 says: +
+ ++Effects: Returns the number of increments or decrements needed to get +from first to last. ++ ++IMO the part " or decrements" is in contradiction to p. 5 which says +
+ ++Requires: last shall be reachable from first. ++ ++because "reachable" is defined in 24.2 [iterator.concepts]/7 as +
+ ++An iterator j is called reachable from an iterator i if and only if +there is a finite +sequence of applications of the expression ++i that makes i == j.[..] ++ ++Here is wording that would be consistent with this definition of "reachable": +
+ ++Change 24.4 [iterator.operations] p4 as follows: +
+ ++Effects: Returns the number of increments+ +or decrements+needed to get from first to last. ++Thomas adds more discussion and an alternative view point +here. +
+ +[ +Summit: +]
+ + ++The proposed wording below was verbally agreed to. Howard provided. ++ +[ +Batavia (2009-05): +]
+ +++ + ++Pete reports that a recent similar change has been made +for the advance() function. +
++We agree with the proposed resolution. +Move to Tentatively Ready. +
+Proposed resolution:
++Change 24.4 [iterator.operations]: +
+ +++ + + + + + +template <InputIterator Iter> + Iter::difference_type + distance(Iter first, Iter last); ++ +template <RandomAccessIterator Iter> + Iter::difference_type distance(Iter first, Iter last);+++ ++-4- Effects: Returns the number of increments
+or decrements+needed to get from first to last. ++-5- Requires: last shall be reachable from first. +
+template <RandomAccessIterator Iter> + Iter::difference_type distance(Iter first, Iter last); ++ +++ + ++-6- Effects: Returns the number of increments or decrements +needed to get from first to last. +
++-7- Requires: last shall be reachable from first +or first shall be reachable from last. +
+
+941. Ref-qualifiers for assignment operators
+Section: 17 [library] Status: Open + Submitter: Niels Dekker Opened: 2008-12-18 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
++The assignment and equality operators = and == are easily confused, just +because of their visual similarity, and in this case a simple typo can cause +a serious bug. When the left side of an operator= is an rvalue, it's +highly unlikely that the assignment was intended by the programmer: +
++if ( func() = value ) // Typical typo: == intended! ++Built-in types don't support assignment to an rvalue, but unfortunately, +a lot of types provided by the Standard Library do. +
++Fortunately the language now offers a syntax to prevent a certain member +function from having an rvalue as *this: by adding a ref-qualifier (&) +to the member function declaration. Assignment operators are explicitly +mentioned as a use case of ref-qualifiers, in "Extending Move Semantics +To *this (Revision 1)", +N1821 by Daveed +Vandevoorde and Bronek Kozicki +
++Hereby I would like to propose adding ref-qualifiers to all appropriate +assignment operators in the library. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open. +We recommend this be deferred until after the next Committee Draft. ++ + +Proposed resolution:
++A proposed resolution is provided by the paper on this subject, +N2819, +Ref-qualifiers for assignment operators of the Standard Library +
+ + + + + +
+943. ssize_t undefined
+Section: 29.5.2 [atomics.types.address] Status: Tentatively Ready + Submitter: Holger Grund Opened: 2008-12-19 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++There is a row in "Table 122 - Atomics for standard typedef types" +in 29.5.1 [atomics.types.integral] with atomic_ssize_t +and ssize_t. Unless, I'm missing something ssize_t +is not defined by the standard. +
+ +[ +Summit: +]
+ + ++Move to review. Proposed resolution: Remove the typedef. Note: ssize_t +is a POSIX type. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Remove the row containing ssize_t from Table 119 +"Atomics for standard typedef types" in 29.5.2 [atomics.types.address]. +
+ + + + + +
+944. atomic<bool> derive from atomic_bool?
+Section: 29.5.3 [atomics.types.generic] Status: Open + Submitter: Holger Grund Opened: 2008-12-19 Last modified: 2009-03-22
+View all other issues in [atomics.types.generic].
+View all issues with Open status.
+Discussion:
++I think it's fairly obvious that atomic<bool> is supposed to be derived +from atomic_bool (and otherwise follow the atomic<integral> interface), +though I think the current wording doesn't support this. I raised this +point along with atomic<floating-point> privately with Herb and I seem +to recall it came up in the resulting discussion on this list. However, +I don't see anything on the current libs issue list mentioning this +problem. +
+ ++29.5.3 [atomics.types.generic]/3 reads +
+ ++There are full specializations over the integral types on the atomic +class template. For each integral type integral in the second column of +table 121 or table 122, the specialization atomic<integral> shall be +publicly derived from the corresponding atomic integral type in the +first column of the table. These specializations shall have trivial +default constructors and trivial destructors. ++ ++Table 121 does not include (atomic_bool, bool), +so that this should probably be mentioned explicitly in the quoted paragraph. +
+ +[ +Summit: +]
+ + ++Move to open. Lawrence will draft a proposed resolution. Also, ask +Howard to fix the title. ++ +[ +Post Summit Anthony provided proposed wording. +]
+ + + +Proposed resolution:
++Replace paragraph 3 in 29.5.3 [atomics.types.generic] with +
+ ++-3- There are full specializations over the integral types on the atomic +class template. For each integral type integral in the second column of +table 121 or table 122, the specialization atomic<integral> shall be +publicly derived from the corresponding atomic integral type in the first +column of the table. +In addition, the specialization atomic<bool> +shall be publicly derived from atomic_bool. +These specializations shall have trivial default +constructors and trivial destructors. ++ + + + + +
+945. system_clock::rep not specified
+Section: 20.9.5.1 [time.clock.system] Status: Tentatively NAD Editorial + Submitter: Pete Becker Opened: 2008-12-19 Last modified: 2009-05-23
+View other active issues in [time.clock.system].
+View all other issues in [time.clock.system].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++In 20.9.5.1 [time.clock.system], the declaration of system_clock::rep says "see +below", but there is nothing below that describes it. +
+ +[ +Howard adds: +]
+ + +++ ++This note refers to: +
+ ++-2- system_clock::duration::min() < system_clock::duration::zero() shall be true. ++ ++I.e. this is standardeze for "system_clock::rep is signed". +Perhaps an editorial note along the lines of: +
+ ++-2- system_clock::duration::min() < system_clock::duration::zero() +shall be true. [Note: system_clock::rep shall be signed. -- end note]. ++ ++? +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the direction of the proposed resolution. +Move to NAD Editorial. ++ + + +Proposed resolution:
++Add a note to 20.9.5.1 [time.clock.system], p2: +
++-2- system_clock::duration::min() < system_clock::duration::zero() +shall be true. [Note: system_clock::rep shall be signed. -- end note]. ++ + + + + +
+946. duration_cast improperly specified
+Section: 20.9.3.7 [time.duration.cast] Status: Tentatively NAD + Submitter: Pete Becker Opened: 2008-12-20 Last modified: 2009-05-23
+View other active issues in [time.duration.cast].
+View all other issues in [time.duration.cast].
+View all issues with Tentatively NAD status.
+Discussion:
+20.9.3.7 [time.duration.cast]/3: + ++.... All intermediate computations shall be +carried out in the widest possible representation... . ++ ++So ignoring +floating-point types for the moment, all this arithmetic has to be done +using the implementation's largest integral type, even if both arguments +use int for their representation. This seems excessive. And it's not at +all clear what this means if we don't ignore floating-point types. +
+ ++This issue is related to 952. +
+ +[ +Howard adds: +]
+ + +++ ++The intent of this remark is that intermediate computations are carried out +using: +
+ ++ +common_type<typename ToDuration::rep, Rep, intmax_t>::type ++The Remark was intended to be clarifying prose supporting the rather algorithmic description +of the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph +3 (Remarks) would be better dropped? +
+[ +Batavia (2009-05): +]
+ +++ + + ++We view this as a specific case of issue 952, +and should be resolved when that issue is resolved. +
++Move to NAD. +
+Proposed resolution:
++
+ + + + + +
+947. duration arithmetic: contradictory requirements
+Section: 20.9.3.5 [time.duration.nonmember] Status: Open + Submitter: Pete Becker Opened: 2008-12-20 Last modified: 2009-05-23
+View all other issues in [time.duration.nonmember].
+View all issues with Open status.
+Discussion:
++In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling +dur / rep +when rep is an instantiation of duration requires a diagnostic. +That's followed by an operator/ that takes two durations. +So dur1 / dur2 is legal under the second version, +but requires a diagnostic under the first. +
+ +[ +Howard adds: +]
+ + ++Please see the thread starting with c++std-lib-22980 for more information. ++ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending proposed wording (and preferably an implementation). ++ + +Proposed resolution:
++
+ + + + + +
+948. ratio arithmetic tweak
+Section: 20.4.2 [ratio.arithmetic] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2008-12-26 Last modified: 2009-03-09
+View other active issues in [ratio.arithmetic].
+View all other issues in [ratio.arithmetic].
+View all issues with Tentatively Ready status.
+Discussion:
++N2800, +20.4.2 [ratio.arithmetic] lacks a paragraph from the proposal +N2661: +
+ +++ +ratio arithmetic [ratio.arithmetic]
+ ++... If the implementation is unable to form the indicated ratio due to +overflow, a diagnostic shall be issued. +
++The lack of a diagnostic on compile-time overflow is a significant lack of +functionality. This paragraph could be put back into the WP simply editorially. +However in forming this issue I realized that we can do better than that. This +paragraph should also allow alternative formulations which go to extra lengths +to avoid overflow when possible. I.e. we should not mandate overflow when the +implementation can avoid it. +
+ ++For example: +
+ +++ +template <class R1, class R2> struct ratio_multiply { + typedef see below} type; ++ ++The nested typedef type shall be a synonym for ratio<T1, T2> where +T1 has the value R1::num * R2::num and T2 has the +value R1::den * R2::den. ++ ++Consider the case where intmax_t is a 64 bit 2's complement signed integer, +and we have: +
+ ++ +typedef std::ratio<0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0> R1; +typedef std::ratio<8, 7> R2; +typedef std::ratio_multiply<R1, R2>::type RT; ++According to the present formulation the implementaiton will multiply +0x7FFFFFFFFFFFFFFF * 8 which will result in an overflow and subsequently +require a diagnostic. +
+ ++However if the implementation is first allowed to divde 0x7FFFFFFFFFFFFFFF +by 7 obtaining 0x1249249249249249 / 1 and divide +8 by 0x7FFFFFFFFFFFFFF0 obtaining 1 / 0x0FFFFFFFFFFFFFFE, +then the exact result can then be computed without overflow: +
+ ++ +[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE] ++Example implmentation which accomplishes this: +
+ ++ +template <class R1, class R2> +struct ratio_multiply +{ +private: + typedef ratio<R1::num, R2::den> _R3; + typedef ratio<R2::num, R1::den> _R4; +public: + typedef ratio<__ll_mul<_R3::num, _R4::num>::value, + __ll_mul<_R3::den, _R4::den>::value> type; +}; +[ +Post Summit: +]
+ + ++Recommend Tentatively Ready. ++ + + + +Proposed resolution:
++Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]: +
+ ++Implementations may use other algorithms to compute the indicated ratios to avoid overflow. +If overflow occurs, a diagnostic shall be issued. ++ + + + + +
+949. owner_less
+Section: 20.8.13.4 [util.smartptr.ownerless] Status: Tentatively Ready + Submitter: Thomas Plum Opened: 2008-12-30 Last modified: 2009-03-10
+View all issues with Tentatively Ready status.
+Discussion:
++20.8.13.4 [util.smartptr.ownerless] (class template owner_less) says that +operator()(x,y) shall return x.before(y). +
++However, shared_ptr and weak_ptr have an owner_before() but not a +before(), and there's no base class to provide a missing before(). +
++Being that the class is named owner_less , I'm guessing that +"before()" should be "owner_before()", right? +
+ +[ +Herve adds: +]
+ + ++Agreed with the typo, it should be "shall return x.owner_before(y)". ++ +[ +Post Summit: +]
+ + ++Recommend Tentatively Ready. ++ + + +Proposed resolution:
++Change 20.8.13.4 [util.smartptr.ownerless] p2: +
+ ++-2- operator()(x,y) shall return +x.owner_before(y). [Note: ... ++ + + + + +
+950. unique_ptr converting ctor shouldn't accept array form
+Section: 20.8.12.2.1 [unique.ptr.single.ctor] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [unique.ptr.single.ctor].
+View all other issues in [unique.ptr.single.ctor].
+View all issues with Tentatively Ready status.
+Discussion:
++unique_ptr's of array type should not convert to +unique_ptr's which do not have an array type. +
+ ++ +struct Deleter +{ + void operator()(void*) {} +}; + +int main() +{ + unique_ptr<int[], Deleter> s; + unique_ptr<int, Deleter> s2(std::move(s)); // should not compile +} +[ +Post Summit: +]
+ + +++ ++Walter: Does the "diagnostic required" apply to both arms of the "and"? +
++Tom Plum: suggest to break into several sentences +
++Walter: suggest "comma" before the "and" in both places +
++Recommend Review. +
+[ +Batavia (2009-05): +]
+ ++The post-Summit comments have been applied to the proposed resolution. +We now agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 20.8.12.2.1 [unique.ptr.single.ctor]: +
+ +++ +template <class U, class E> unique_ptr(unique_ptr<U, E>&& u); +++++-20- 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). unique_ptr<U, E>::pointer shall be +implicitly convertible to pointer (diagnostic required). U shall not be +an array type (diagnostic required). [Note: These requirements +imply that T and U are complete types. -- end note] +
++Change 20.8.12.2.3 [unique.ptr.single.asgn]: +
+ +++ + + + + + +template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u); +++++-6- Requires: Assignment of the deleter D from an rvalue +D shall not throw an exception. unique_ptr<U, +E>::pointer shall be implicitly convertible to pointer +(diagnostic required). U shall not be an array type (diagnostic required). +[Note: These requirements imply that T and U +are complete types. -- end note] +
+
+951. Various threading bugs #1
+Section: 20.9.2.1 [time.traits.is_fp] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
+ ++Related to 953. +
+ ++20.9.2.1 [time.traits.is_fp] says that the type Rep "is +assumed to be ... a class emulating an integral type." What are the +requirements for such a type? +
+[ +2009-05-10 Howard adds: +]
+ + ++IntegralLike. ++ +[ +Batavia (2009-05): +]
+ +++ + ++As with issue 953, +we recommend this issue be addressed in the context of providing concepts for the entire thread header. +
++We look forward to proposed wording. +
++Move to Open. +
+Proposed resolution:
++
+ + + + + +
+952. Various threading bugs #2
+Section: 20.9.3.7 [time.duration.cast] Status: Tentatively NAD Editorial + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [time.duration.cast].
+View all other issues in [time.duration.cast].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++20.9.3.7 [time.duration.cast] specifies an implementation and imposes +requirements in text (and the implementation doesn't satisfy all of the +text requirements). Pick one. +
+ ++This issue is related to 946. +
+ +[ +2009-05-10 Howard adds: +]
+ + +++ ++The Remarks paragraph is an English re-statement of the preceeding +Returns clause. It was meant to be clarifying and motivating, not +confusing. I'm not aware with how the Remarks contradicts the Returns clause +but I'm ok with simply removing the Remarks. +
+[ +Batavia (2009-05): +]
+ +++ + ++Pete suggests that this could be resolved +by rephrasing the Remarks to Notes. +
++Move to NAD Editorial. +
+Proposed resolution:
++
+ + + + + +
+953. Various threading bugs #3
+Section: 20.9.1 [time.clock.req] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [time.clock.req].
+View all other issues in [time.clock.req].
+View all issues with Open status.
+Discussion:
+ ++Related to 951. +
+ ++20.9.1 [time.clock.req] says that a clock's rep member is "an +arithmetic type or a class emulating an arithmetic type." What are the +requirements for such a type? +
+ +[ +2009-05-10 Howard adds: +]
+ + ++This wording was aimed directly at the ArithmeticLike concept. ++ +[ +Batavia (2009-05): +]
+ +++ + ++We recommend this issue be addressed in the context of providing concepts +for the entire thread header. +
++May resolve for now by specifying arithmetic types, +and in future change to ArithmeticLike. +However, Alisdair believes this is not feasible. +
++Bill disagrees. +
++We look forward to proposed wording. Move to Open. +
+Proposed resolution:
++
+ + + + + +
+954. Various threading bugs #4
+Section: 20.9.1 [time.clock.req] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-30
+View other active issues in [time.clock.req].
+View all other issues in [time.clock.req].
+View all issues with Open status.
+Discussion:
++Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req]) +
+ ++
+ +- +the requirements for C1::time_point require C1 and C2 +to "refer to the same epoch", but "epoch" is not defined. +
+- +"Different clocks may share a time_point definition if it is +valid to compare their time_points by comparing their +respective durations." What does "valid" mean here? And, since +C1::rep is "**THE** representation type of the native +duration and time_point" (emphasis added), there +doesn't seem to be much room for some other representation. +
+- +C1::is_monotonic has type "const bool". The +"const" should be removed. +
+- +C1::period has type ratio. ratio isn't a type, +it's a template. What is the required type? +
+[ +2009-05-10 Howard adds: +]
+ + ++
+ +- +
++"epoch" is purposefully not defined beyond the common English +definition. The C standard +also chose not to define epoch, though POSIX did. I believe it is a strength +of the C standard that epoch is not defined. When it is known that two time_points +refer to the same epoch, then a definition of the epoch is not needed to compare +the two time_points, or subtract them. +
++A time_point and a Clock implicitly refer to an (unspecified) epoch. +The time_point represents an offset (duration) from an epoch. +
+- +
++The sentence: +
++Different clocks +may share a time_point +definition if it is valid to +compare their time_points by +comparing their respective +durations. ++ ++is redundant and could be removed. I believe the sentence which follows the above: +
+ ++C1 and C2 shall refer to the same epoch. ++ ++is sufficient. If two clocks share the same epoch, then by definition, comparing +their time_points is valid. +
+- +is_monotonic is meant to never change (be const). It is also +desired that this value be usable in compile-time computation and branching. +
+- +
++This should probably instead be worded: +
++An instantiation of ratio. ++[ +Batavia (2009-05): +]
+ +++ ++Re (a): It is not clear to us whether "epoch" is a term of art. +
++Re (b), (c), and (d): We agree with Howard's comments, +and would consider adding to (c) a static constexpr requirement. +
++Move to Open pending proposed wording. +
+[ +2009-05-25 Daniel adds: +]
+ + ++In regards to (d) I suggest to say "a specialization of ratio" instead of +"An instantiation of ratio". This seems to be the better matching standard +core language term for this kind of entity. ++ +[ +2009-05-25 Ganesh adds: +]
+ + +++ + + + ++Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording: +
+ + ++which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)". +
+Proposed resolution:
++
+- +
++Change 20.9.1 [time.clock.req] p1: +
++-1- A clock is a bundle consisting of a native duration, a native time_point, and a function now() to get the +current time_point. The origin of the clock's time_point is referred to as the clock's epoch as defined in +section 6.3 of ISO/IEC 18026. +A clock shall meet the requirements in Table 45. ++- +
++Remove the sentence from the time_point row of the table "Clock Requirements": +
++
+Clock requirements ++ ++C1::time_point + ++chrono::time_point<C1> or chrono::time_point<C2, C1::duration> + ++The native time_point type of the clock. + +Different clocks may share a time_point definition if it is valid to compare their time_points by comparing their respective durations.+C1 and C2 shall refer to the same epoch. ++
+ + + + + +- +
++Change the row starting with C1::period of the table "Clock Requirements": +
++
+ +Clock requirements ++ ++C1::period + ++a specialization of ratio + ++The tick period of the clock in seconds. + +
+955. Various threading bugs #5
+Section: 20.9.1 [time.clock.req] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-06-07
+View other active issues in [time.clock.req].
+View all other issues in [time.clock.req].
+View all issues with Open status.
+Discussion:
++20.9.1 [time.clock.req] requires that a clock type have a member +typedef named time_point that names an instantiation of the +template time_point, and a member named duration that +names an instantiation of the template duration. This mixing of +levels is confusing. The typedef names should be different from the +template names. +
+ +[ +Post Summit, Anthony provided proposed wording. +]
+ + +[ +2009-05-04 Howard adds: +]
+ + +++ ++The reason that the typedef names were given the same name as the class templates +was so that clients would not have to stop and think about whether they were +using the clock's native time_point / duration or the class +template directly. In this case, one person's confusion is another person's +encapsulation. The detail that sometimes one is referring to the clock's +native types, and sometimes one is referring to an independent type is +purposefully "hidden" because it is supposed to be an unimportant +detail. It can be confusing to have to remember when to type duration +and when to type duration_type, and there is no need to require the +client to remember something like that. +
+ ++For example, here is code that I once wrote in testing out the usability of +this facility: +
+ ++ +template <class Clock, class Duration> +void do_until(const std::chrono::time_point<Clock, Duration>& t) +{ + typename Clock::time_point now = Clock::now(); + if (t > now) + { + typedef typename std::common_type + < + Duration, + typename std::chrono::system_clock::duration + >::type CD; + typedef std::chrono::duration<double, std::nano> ID; + + CD d = t - now; + ID us = duration_cast<ID>(d); + if (us < d) + ++us; + ... + } +} ++I see no rationale to require the client to append _type to some +of those declarations. It seems overly burdensome on the author of do_until: +
+ ++ +template <class Clock, class Duration> +void do_until(const std::chrono::time_point<Clock, Duration>& t) +{ + typename Clock::time_point_type now = Clock::now(); + if (t > now) + { + typedef typename std::common_type + < + Duration, + typename std::chrono::system_clock::duration_type + >::type CD; + typedef std::chrono::duration<double, std::nano> ID; + + CD d = t - now; + ID us = duration_cast<ID>(d); + if (us < d) + ++us; + ... + } +} ++Additionally I'm fairly certain that this suggestion hasn't been implemented. +If it had, it would have been discovered that it is incomplete. time_point +also has a nested type (purposefully) named duration. +
++That is, the current proposed wording would put the WP into an inconsistent state. +++In contrast, +the current WP has been implemented and I've received very favorable feedback +from people using this interface in real-world code. +
+ +[ +Batavia (2009-05): +]
+ +++ ++Bill agrees that distinct names should be used for distinct kinds of entities. +
++Walter would prefer not to suffix type names, +especially for such well-understood terms as "duration". +
++Howard reminds us that the proposed resolution is incomplete, per his comment +in the issue. +
++Move to Open. +
+[ +2009-06-07 Howard adds: +]
+ + +++ + + ++Not meaning to be argumentative, but we have a decade of positive experience +with the precedent of using the same name for the nested type as an external +class representing an identical concept. +
+ ++ +template<class Category, class T, class Distance = ptrdiff_t, + class Pointer = T*, class Reference = T&> +struct iterator +{ + ... +}; + +template <BidirectionalIterator Iter> +class reverse_iterator +{ + ... +}; + +template <ValueType T, Allocator Alloc = allocator<T> > + requires NothrowDestructible<T> +class list +{ +public: + typedef implementation-defined iterator; + ... + typedef reverse_iterator<iterator> reverse_iterator; + ... +}; ++I am aware of zero complaints regarding the use of iterator +and reverse_iterator as nested types of the containers despite these +names also having related meaning at namespace std scope. +
+ ++Would we really be doing programmers a favor by renaming these nested types? +
+ ++ +template <ValueType T, Allocator Alloc = allocator<T> > + requires NothrowDestructible<T> +class list +{ +public: + typedef implementation-defined iterator_type; + ... + typedef reverse_iterator<iterator> reverse_iterator_type; + ... +}; ++I submit that such design contributes to needless verbosity which ends up +reducing readability. +
+Proposed resolution:
++Change 20.9 [time]: +
+ ++ +... +template <class Clock, class Duration = typename Clock::duration_type> class time_point; +... ++Change 20.9.1 [time.clock.req]: +
+ +++ ++
+Table 45 -- Clock requirements ++ +Expression +Return type +Operational semantics ++ +... +... +... ++ +C1::duration_type +chrono::duration<C1::rep, C1::period> +The native duration type of the clock. ++ +C1::time_point_type +chrono::time_point<C1> or chrono::time_point<C2, C1::duration_type< +The native time_point type of the clock. Different clocks may share a time_point_type +definition if it is valid to +compare their time_point_types by +comparing their respective +duration_types. C1 and C2 shall +refer to the same epoch. ++ +... +... +... ++ +C1::now() +C1::time_point_type +Returns a time_point_type object +representing the current point +in time. + ++Change 20.9.5.1 [time.clock.system]: +
+ +++ ++-1- Objects of class system_clock represent wall clock time from the system-wide realtime clock. +
+ ++ +class system_clock { +public: + typedef see below rep; + typedef ratio<unspecified, unspecified> period; + typedef chrono::duration<rep, period> duration_type; + typedef chrono::time_point<system_clock> time_point_type; + static const bool is_monotonic = unspecified ; + + static time_point_type now(); + + // Map to C API + static time_t to_time_t (const time_point_type& t); + static time_point_type from_time_t(time_t t); +}; ++-2- system_clock::duration_type::min() < system_clock::duration_type::zero() shall be true. +
+ +time_t to_time_t(const time_point_type& t); ++ ++-3- Returns: A time_t object that represents the same +point in time as t when both values are truncated to the +coarser of the precisions of time_t and time_point_type. ++ +time_point_type from_time_t(time_t t); ++ ++-4- Returns: A time_point_type object that represents the same point +in time as t when both values are truncated to the coarser of the +precisions of time_t and time_point_type. +++Change 20.9.5.2 [time.clock.monotonic]: +
+ ++ +class monotonic_clock { +public: + typedef unspecified rep; + typedef ratio<unspecified , unspecified> period; + typedef chrono::duration<rep, period> duration_type; + typedef chrono::time_point<unspecified , duration_type> time_point_type; + static const bool is_monotonic = true; + + static time_point_type now(); +}; ++Change 20.9.5.3 [time.clock.hires]: +
+ ++ + + + + + +class high_resolution_clock { +public: + typedef unspecified rep; + typedef ratio<unspecified , unspecified> period; + typedef chrono::duration<rep, period> duration_type; + typedef chrono::time_point<unspecified , duration_type> time_point_type; + static const bool is_monotonic = true; + + static time_point_type now(); +}; +
+956. Various threading bugs #6
+Section: 20.9.1 [time.clock.req] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [time.clock.req].
+View all other issues in [time.clock.req].
+View all issues with Open status.
+Discussion:
++20.9.1 [time.clock.req] uses the word "native" in several places, +but doesn't define it. What is a "native duration"? +
+ +[ +2009-05-10 Howard adds: +]
+ + ++The standard uses "native" in several places without defining it (e.g. +2.14.3 [lex.ccon]). It is meant to mean "that which is defined +by the facility", or something along those lines. In this case it refers +to the nested time_point and duration types of the clock. +Better wording is welcome. ++ +[ +Batavia (2009-05): +]
+ ++Move to Open pending proposed wording from Pete. ++ + +Proposed resolution:
++
+ + + + + +
+957. Various threading bugs #7
+Section: 20.9.5.1 [time.clock.system] Status: Review + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [time.clock.system].
+View all other issues in [time.clock.system].
+View all issues with Review status.
+Discussion:
++20.9.5.1 [time.clock.system]: to_time_t is overspecified. It +requires truncation, but should allow rounding. For example, suppose a +system has a clock that gives times in milliseconds, but time() rounds +those times to the nearest second. Then system_clock can't use any +resolution finer than one second, because if it did, truncating times +between half a second and a full second would produce the wrong time_t +value. +
+ +[ +Post Summit Anthony Williams provided proposed wording. +]
+ + +[ +Batavia (2009-05): +]
+ ++Move to Review pending input from Howard. and other stakeholders. ++ +[ +2009-05-23 Howard adds: +]
+ + ++I am in favor of the wording provided by Anthony. ++ + +Proposed resolution:
++In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with: +
+ +++ + + + + +time_t to_time_t(const time_point& t); +++-3- Returns: A time_t object that represents the same +point in time as t when both values are+ +truncated+restricted to the coarser of the precisions of +time_t and time_point. It is implementation +defined whether values are rounded or truncated to the required +precision. +time_point from_time_t(time_t t); +++-4- Returns: A time_point object that represents the +same point in time as t when both values are+truncated+restricted to the +coarser of the precisions of time_t and time_point. +It is implementation defined whether values are +rounded or truncated to the required precision. +
+958. Various threading bugs #8
+Section: 30.5.1 [thread.condition.condvar] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Open status.
+Discussion:
++30.5.1 [thread.condition.condvar]: the specification for wait_for +with no predicate has an effects clause that says it calls wait_until, +and a returns clause that sets out in words how to determine the return +value. Is this description of the return value subtly different from the +description of the value returned by wait_until? Or should the effects +clause and the returns clause be merged? +
+ +[ +Summit: +]
+ + ++Move to open. Associate with LWG 859 and any other monotonic-clock +related issues. ++ + +Proposed resolution:
++
+ + + + + +
+959. Various threading bugs #9
+Section: 30.5.1 [thread.condition.condvar] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Open status.
+Discussion:
++30.5.1 [thread.condition.condvar]: condition_variable::wait_for +is required to compute the absolute time by adding the duration value to +chrono::monotonic_clock::now(), but monotonic_clock is not required to +exist. +
+ +[ +Summit: +]
+ + ++Move to open. Associate with LWG 859 and any other monotonic-clock +related issues. ++ + +Proposed resolution:
++
+ + + + + +
+960. Various threading bugs #10
+Section: 30.4.1 [thread.mutex.requirements] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-27
+View other active issues in [thread.mutex.requirements].
+View all other issues in [thread.mutex.requirements].
+View all issues with Open status.
+Discussion:
++30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled +"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error +conditions:" specifies "the error conditions for error codes reported by +the function." It's not clear what this should mean when there is no +function in sight. +
+ +[ +Summit: +]
+ + ++Move to open. ++ +[ +Beman provided proposed wording. +]
+ + + +Proposed resolution:
++Change 30.4.1 [thread.mutex.requirements] Mutex requirements, +paragraph 4 as indicated: +
+ +++ + + + + ++-4-
+Error conditions:+The error conditions for error codes, if any, reported by member +functions of type Mutex shall be: ++
+- +not_enough_memory -- if there is not enough memory to construct +the mutex object. +
+- +resource_unavailable_try_again -- if any native handle type +manipulated is not available. +
+- +operation_not_permitted -- if the thread does not have the +necessary permission to change the state of the mutex object. +
+- +device_or_resource_busy -- if any native handle type +manipulated is already locked. +
+- +invalid_argument -- if any native handle type manipulated as +part of mutex construction is incorrect. +
+
+961. Various threading bugs #11
+Section: 30.4.1 [thread.mutex.requirements] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.mutex.requirements].
+View all other issues in [thread.mutex.requirements].
+View all issues with Open status.
+Discussion:
++30.4.1 [thread.mutex.requirements] describes required member +functions of mutex types, and requires that they throw exceptions under +certain circumstances. This is overspecified. User-defined types can +abort on such errors without affecting the operation of templates +supplied by standard-library. +
+ +[ +Summit: +]
+ ++Move to open. Related to conceptualization and should probably be +tackled as part of that. ++ + +Proposed resolution:
++
+ + + + + +
+962. Various threading bugs #12
+Section: 30.4.3.2.2 [thread.lock.unique.locking] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View all issues with Open status.
+Discussion:
++30.4.3.2.2 [thread.lock.unique.locking]: unique_lock::lock is +required to throw an object of type std::system_error "when the +postcondition cannot be achieved." The postcondition is owns == true, +and this is trivial to achieve. Presumably, the requirement is intended +to mean something more than that. +
+ +[ +Summit: +]
+ ++Move to open. ++ +[ +Beman has volunteered to provide proposed wording. +]
+ + + + +Proposed resolution:
++
+ + + + + +
+963. Various threading bugs #13
+Section: 30.3.1.5 [thread.thread.member] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.thread.member].
+View all other issues in [thread.thread.member].
+View all issues with Open status.
+Discussion:
++30.3.1.5 [thread.thread.member]: thread::detach is required to +throw an exception if the thread is "not a detachable thread". +"Detachable" is never defined. +
+ +[ +Howard adds: +]
+ + ++Due to a mistake on my part, 3 proposed resolutions appeared at approximately +the same time. They are all three noted below in the discussion. ++ +[ +Summit, proposed resolution: +]
+ + +++ ++In 30.3.1.5 [thread.thread.member] change: +
+ ++ +void detach(); ++++ +...
+-14- Error conditions:
++
+- no_such_process -- if the thread is not
+avalidthread.- invalid_argument -- if the thread is not
+a detachablejoinablethread.[ +Post Summit, Jonathan Wakely adds: +]
+ + +++ ++A thread is detachable if it is joinable. As we've defined joinable, +we can just use that. +
++This corresponds to the pthreads specification, where pthread_detach +fails if the thread is not joinable: +
++EINVAL: The implementation has detected that the value specified by +thread does not refer to a joinable thread. +++Jonathan recommends this proposed wording: +
++++In 30.3.1.5 [thread.thread.member] change: +
+ ++void detach(); ++++ +...
+-14- Error conditions:
++
+- ...
+- invalid_argument -- not a
+detachablejoinable thread.[ +Post Summit, Anthony Williams adds: +]
+ + +++ + + ++This is covered by the precondition that joinable() be true. +
++Anthony recommends this proposed wording: +
+ +++ ++In 30.3.1.5 [thread.thread.member] change: +
+ ++ +void detach(); ++++ +...
+-14- Error conditions:
++
+- ...
+- +
invalid_argument -- not a detachable thread.Proposed resolution:
+ + + + + +
+964. Various threading bugs #14
+Section: 30.5.2 [thread.condition.condvarany] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View all issues with Open status.
+Discussion:
++The requirements for the constructor for condition_variable has several +error conditions, but the requirements for the constructor for +condition_variable_any has none. Is this difference intentional? +
+ +[ +Summit: +]
+ + ++Move to open, pass to Howard. If this is intentional, a note may be +helpful. If the error conditions are to be copied from +condition_variable, this depends on LWG 965. ++ +[ +Post Summit Howard adds: +]
+ + ++The original intention +(N2447) +was to let the OS return whatever errors it was going to return, and for +those to be translated into exceptions, for both +condition_variable and condition_variable_any. I have not +received any complaints about specific error conditions from vendors on +non-POSIX platforms, but such complaints would not surprise me if they surfaced. ++ + +Proposed resolution:
+ + + + + +
+965. Various threading bugs #15
+Section: 30.5.1 [thread.condition.condvar] Status: Tentatively Ready + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Tentatively Ready status.
+Discussion:
++30.5.1 [thread.condition.condvar]: the constructor for +condition_variable throws an exception with error code +device_or_resource_busy "if attempting to initialize a +previously-initialized but as of yet undestroyed condition_variable." +How can this occur? +
+ +[ +Summit: +]
+ +++ ++Move to review. Proposed resolution: strike the device_or_resource_busy +error condition from the constructor of condition_variable. +
++
+- +This is a POSIX error that cannot occur in this interface because the +C++ interface does not separate declaration from initialization. +
+[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 30.5.1 [thread.condition.condvar] p3: +
+ +++ + + + + ++
+- ...
+- +
+device_or_resource_busy -- if attempting to initialize a +previously-initialized but as of yet undestroyed +condition_variable.+
+966. Various threading bugs #16
+Section: 30.5.1 [thread.condition.condvar] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.condition.condvar].
+View all other issues in [thread.condition.condvar].
+View all issues with Open status.
+Discussion:
++30.5.1 [thread.condition.condvar]: condition_variable::wait and +condition_variable::wait_until both have a postcondition that lock is +locked by the calling thread, and a throws clause that requires throwing +an exception if this postcondition cannot be achieved. How can the +implementation detect that this lock can never be obtained? +
+ +[ +Summit: +]
+ + ++Move to open. Requires wording. Agreed this is an issue, and the +specification should not require detecting deadlocks. ++ + +Proposed resolution:
+ + + + + +
+967. Various threading bugs #17
+Section: 30.3.1.2 [thread.thread.constr] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.thread.constr].
+View all other issues in [thread.thread.constr].
+View all issues with Open status.
+Discussion:
++the error handling for the constructor for condition_variable +distinguishes lack of memory from lack of other resources, but the error +handling for the thread constructor does not. Is this difference +intentional? +
+ +[ +Beman has volunteered to provide proposed wording. +]
+ + + +Proposed resolution:
++
+ + + + + +
+968. Various threading bugs #18
+Section: 30.4.1 [thread.mutex.requirements] Status: Open + Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-03-22
+View other active issues in [thread.mutex.requirements].
+View all other issues in [thread.mutex.requirements].
+View all issues with Open status.
+Discussion:
++30.4.1 [thread.mutex.requirements]: several functions are +required to throw exceptions "if the thread does not have the necessary +permission ...". "The necessary permission" is not defined. +
+ +[ +Summit: +]
+ ++Move to open. ++ + +[ +Beman has volunteered to provide proposed wording. +]
+ + + +Proposed resolution:
++
+ + + + + +
+969. What happened to Library Issue 475?
+Section: 25.3.4 [alg.foreach] Status: Tentatively NAD Editorial + Submitter: Stephan T. Lavavej Opened: 2009-01-12 Last modified: 2009-05-23
+View other active issues in [alg.foreach].
+View all other issues in [alg.foreach].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++Library Issue 475 has CD1 status, but the non-normative note in +N2723 +was removed in +N2798 +(25.3.4 [alg.foreach] in both drafts). +
+ +[ +Batavia (2009-05): +]
+ ++Move to NAD Editorial. ++ + +Proposed resolution:
++Restore the non-normative note. It might need to be expressed in terms of concepts. +
+ + + + + +
+970. addressof overload unneeded
+Section: 20.8.11.1 [object.addressof] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-01-16 Last modified: 2009-05-23
+View other active issues in [object.addressof].
+View all other issues in [object.addressof].
+View all issues with Tentatively Ready status.
+Discussion:
++20.8.11.1 [object.addressof] specifies: +
+ ++ +template <ObjectType T> T* addressof(T& r); +template <ObjectType T> T* addressof(T&& r); ++The two signatures are ambiguous when the argument is an lvalue. The +second signature seems not useful: what does it mean to take the +address of an rvalue? +
+ +[ +Post Summit: +]
+ + ++Recommend Review. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 20.8.11.1 [object.addressof]: +
+ ++ + + + + + +template <ObjectType T> T* addressof(T& r); +template <ObjectType T> T* addressof(T&& r);+
+971. Spurious diagnostic conversion function
+Section: 19.5.2.6 [syserr.errcode.nonmembers] Status: Open + Submitter: Beman Dawes Opened: 2009-01-19 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++Anthony Williams raised the question in c++std-lib-22987 "why is there +std::make_error_code(std::errc)? What purpose does this serve?" +
++The function make_error_code(errc e) is not required, since +make_error_condition(errc e) is the function that is needed for errc +conversions. make_error_code(errc e) appears to be a holdover from my +initial confusion over the distinction between POSIX and operating +systems that conform to the POSIX spec. +
+ +[ +Post Summit: +]
+ + ++Recommend Review. ++ +[ +Batavia (2009-05): +]
+ ++The designer of the facility (Christopher Kohlhoff) +strongly disagrees that there is an issue here, +and especially disagrees with the proposed resolution. +Bill would prefer to be conservative and not apply this proposed resolution. +Move to Open, and recommend strong consideration for NAD status. ++ +[ +2009-05-21 Beman adds: +]
+ + ++My mistake. Christopher and Bill are correct and the issue should be +NAD. The function is needed by users. ++ + +Proposed resolution:
++Change System error support 19.5 [syserr], Header <system_error> +synopsis, as indicated: +
+ ++ +error_code make_error_code(errc e);+error_condition make_error_condition(errc e); ++Delete from Class error_code non-member functions +19.5.2.6 [syserr.errcode.nonmembers]: +
+ ++ + + + + + ++error_code make_error_code(errc e);+++Returns: error_code(static_cast<int>(e), +generic_category).+
+972. The term "Assignable" undefined but still in use
+Section: 17 [library] Status: Tentatively NAD Editorial + Submitter: Niels Dekker Opened: 2009-01-07 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++Previous versions of the Draft had a table, defining the Assignable +requirement. For example +N2134 +Table 79, "Assignable requirements". But I guess the term "Assignable" +is outdated by now, because the current Committee Draft provides +MoveAssignable, CopyAssignable, and TriviallyCopyAssignable concepts +instead. And as far as I can see, it no longer has a definition of +Assignable. (Please correct me if I'm wrong.) Still the word +"Assignable" is used in eight places in the Draft, +N2800. +
+ ++Are all of those instances of "Assignable" to be replaced by "CopyAssignable"? +
+ +[ +Batavia (2009-05): +]
+ ++Move to NAD Editorial. ++ + +Proposed resolution:
+ ++Change Exception Propagation 18.8.5 [propagation]: +
++exception_ptr shall be DefaultConstructible, CopyConstructible, +CopyAssignable and EqualityComparable. ++ ++Change Class template reference_wrapper 20.7.5 [refwrap]: +
++reference_wrapper<T> is a CopyConstructible and CopyAssignable wrapper around a reference to an object of type T. +++Change Placeholders 20.7.12.1.4 [func.bind.place]: +
++It is implementation defined whether placeholder types are CopyAssignable. CopyAssignable placeholders' copy assignment operators shall not throw exceptions. +++Change Class template shared_ptr 20.8.13.2 [util.smartptr.shared]: +
++Specializations of shared_ptr shall be CopyConstructible, CopyAssignable, and LessThanComparable... +++Change Class template weak_ptr 20.8.13.3 [util.smartptr.weak]: +
++Specializations of weak_ptr shall be CopyConstructible, CopyAssignable, and LessThanComparable... +++Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!): +
++Requires: state_type shall meet the requirements of CopyAssignable+(23.1), CopyConstructible (20.1.8), and DefaultConstructible types. ++Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!): +
++In addition to the requirements set forth below, instances of +seed_seq shall meet the requirements of CopyConstructible (20.1.8) and of CopyAssignable+ +(23.1). ++Note: The proposed resolution of this issue does not deal with the +instance of the term "Assignable" in D.9.1 [auto.ptr], as this is dealt +with more specifically by LWG 973, "auto_ptr characteristics", submitted +by Maarten Hilferink. +
+ + + + + + +
+973. auto_ptr characteristics
+Section: D.9.1 [auto.ptr] Status: Tentatively NAD Editorial + Submitter: Maarten Hilferink Opened: 2009-01-21 Last modified: 2009-05-23
+View other active issues in [auto.ptr].
+View all other issues in [auto.ptr].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++I think that the Note of D.9.1 [auto.ptr], paragraph 3 needs a rewrite +since "Assignable" is no longer defined as a concept. +The relationship of auto_ptr with the new CopyAssignable, MoveAssignable, + and MoveConstructible concepts should be clarified. +Furthermore, since the use of auto_ptr is depreciated anyway, + we can also omit a description of its intended use. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the intent of the proposed resolution. +Move to NAD Editorial. ++ + +Proposed resolution:
++Change D.9.1 [auto.ptr], paragraph 3: +
+ ++The auto_ptr provides a semantics of strict ownership. An +auto_ptr owns the ob ject it holds a pointer to. Copying an +auto_ptr copies the pointer and transfers ownership to the +destination. If more than one auto_ptr owns the same ob ject at +the same time the behavior of the program is undefined. [Note: +The uses of auto_ptr include providing temporary +exception-safety for dynamically allocated memory, passing ownership of +dynamically allocated memory to a function, and returning dynamically +allocated memory from a function. ++ + + + + +auto_ptr does not meet the +CopyConstructible and Assignable requirements for +standard library container elements and thus instantiating a standard +library container with an auto_ptr results in undefined +behavior.+ +Instances of auto_ptr shall +meet the MoveConstructible and MoveAssignable +requirements, but do not meet the CopyConstructible and +CopyAssignable requirements. +-- end note] +
+974. duration<double> should not implicitly convert to duration<int>
+Section: 20.9.3.1 [time.duration.cons] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-01-21 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++The following code should not compile because it involves implicit truncation +errors (against the design philosophy of the duration library). +
+ ++ +duration<double> d(3.5); +duration<int> i = d; // implicit truncation, should not compile ++This intent was codified in the example implementation which drove this proposal +but I failed to accurately translate the code into the specification in this +regard. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change 20.9.3.1 [time.duration.cons], p4: +
+ +++ + + + + +template <class Rep2, class Period2> + duration(const duration<Rep2, Period2>& d); +++-4- Requires: treat_as_floating_point<rep>::value +shall be true or both ratio_divide<Period2, +period>::type::den shall be 1 +and treat_as_floating_point<Rep2>::value +shall be false. +Diagnostic required. +[Note: This requirement prevents implicit truncation error when +converting between integral-based duration types. Such a +construction could easily lead to confusion about the value of the +duration. -- end note] ++
+975. is_convertible cannot be instantiated for non-convertible types
+Section: 20.6.5 [meta.rel] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2009-01-25 Last modified: 2009-05-23
+View other active issues in [meta.rel].
+View all other issues in [meta.rel].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 206 + ++Related to 1114. +
+ ++The current specification of std::is_convertible (reference is draft +N2798) +is basically defined by 20.6.5 [meta.rel]/4: +
+ +++ ++In order to instantiate the template is_convertible<From, +To>, the following code shall be well formed: +
+ ++ +template <class T> + typename add_rvalue_reference<T>::type create(); + +To test() { + return create<From>(); +} ++[Note: This requirement gives well defined results for reference +types, void types, array types, and function types. --end note] +
++The first sentence can be interpreted, that e.g. the expression +
+ ++ +std::is_convertible<double, int*>::value ++is ill-formed because std::is_convertible<double, int*> could not be +instantiated, or in more general terms: The wording requires that +std::is_convertible<X, Y> cannot be instantiated for otherwise valid +argument types X and Y if X is not convertible to Y. +
+ ++This semantic is both unpractical and in contradiction to what the last type +traits paper +N2255 +proposed: +
+ +++ ++If the following test function is well formed code b +is true, else it is false. +
+ ++ +template <class T> + typename add_rvalue_reference<T>::type create(); + +To test() { + return create<From>(); +} ++[Note: This definition gives well defined results for reference +types, void types, array types, and function types. --end note] +
+[ +Post Summit: +]
+ + +++ ++Jens: Checking that code is well-formed and then returning true/false +sounds like speculative compilation. John Spicer would really dislike +this. Please find another wording suggesting speculative compilation. +
++Recommend Open. +
+[ +Post Summit, Howard adds: +]
+ + +++ +Original proposed wording: + ++John finds the following wording clearer: +
++ ++ ++
+ ++ +Template Condition Comments ++ +template <class From, class To> +
struct is_convertible;see below +From and To shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) void types. ++Given the following function prototype: +
+ ++ +template <class T> + typename add_rvalue_reference<T>::type create(); ++is_convertible<From, To>::value shall be true if the +return expression in the following code would be well-formed, including +any implicit conversions to the return type of the function, else +is_convertible<From, To>::value shall be false. +
+ ++ +To test() { + return create<From>(); +} ++In 20.6.5 [meta.rel]/4 change: +
+ +++ +In order to instantiate the template is_convertible<From, To>, the +following code shall be well formedIf the following code +is well formed is_convertible<From, To>::value is true, otherwise +false:[..] +Revision 2
+ ++ ++ ++In 20.6.5 [meta.rel] change: +
+ ++ +++
+ ++ +Template Condition Comments ++ + ... ... ... + template <class From, class To> +
struct is_convertible;+ +The code set out below shall be well formed.+see belowFrom and To shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) void types. ++-4-
+ +In order to instantiate the template is_convertible<From, To>, the +following code shall be well formed:+Given the following function prototype: ++ +template <class T> + typename add_rvalue_reference<T>::type create(); ++is_convertible<From, To>::value inherits either directly or +indirectly from true_type if the +return expression in the following code would be well-formed, including +any implicit conversions to the return type of the function, else +is_convertible<From, To>::value inherits either directly or +indirectly from false_type. +
+ ++ +To test() { + return create<From>(); +} ++[Note: This requirement gives well defined results for reference types, +void types, array types, and function types. -- end note] +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
+ ++In 20.6.5 [meta.rel] change: +
+ ++ ++ + + + + ++
+ ++ +Template Condition Comments ++ + ... ... ... + template <class From, class To> +
struct is_convertible;+ +The code set out below shall be well formed.+see belowFrom and To shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) void types. ++-4-
+ +In order to instantiate the template is_convertible<From, To>, the +following code shall be well formed:+Given the following function prototype: ++ +template <class T> + typename add_rvalue_reference<T>::type create(); ++the predicate condition for a template specialization +is_convertible<From, To> shall be satisfied, if and only +if the return expression in the following code would be well-formed, +including any implicit conversions to the return type of the +function. +
+ ++ +To test() { + return create<From>(); +} ++[Note: This requirement gives well defined results for reference types, +void types, array types, and function types. — end note] +
+ +
+976. Class template std::stack should be movable
+Section: 23.3.5.3.1 [stack.defn] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2009-02-01 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++The synopsis given in 23.3.5.3.1 [stack.defn] does not show up +
+ ++ +requires MoveConstructible<Cont> stack(stack&&); +requires MoveAssignable<Cont> stack& operator=(stack&&); ++although the other container adaptors do provide corresponding +members. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert: +
+ ++ +template <ObjectType T, StackLikeContainer Cont = deque<T> > + requires SameType<Cont::value_type, T> + && NothrowDestructible<Cont> +class stack { +public: + ... + requires CopyConstructible<Cont> explicit stack(const Cont&); + requires MoveConstructible<Cont> explicit stack(Cont&& = Cont()); + requires MoveConstructible<Cont> stack(stack&&); + requires MoveAssignable<Cont> stack& operator=(stack&&); + template <class Alloc> + requires Constructible<Cont, const Alloc&> + explicit stack(const Alloc&); + ... +}; ++[Remark: This change should be done in sync with the resolution of +paper +N2819] +
+ + + + + + +
+977. insert iterators inefficient for expensive to move types
+Section: 24.7 [insert.iterators] Status: Open + Submitter: Howard Hinnant Opened: 2009-02-02 Last modified: 2009-05-23
+View other active issues in [insert.iterators].
+View all other issues in [insert.iterators].
+View all issues with Open status.
+Discussion:
++The new concepts for the insert iterators mandate an extra copy when +inserting an lvalue: +
+ ++ +requires CopyConstructible<Cont::value_type> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); +++-1- Effects: push_back(*container, Cont::value_type(value)); +++The reason is to convert value into an rvalue because the current +BackInsertionContainer concept only handles push_back-ing +rvalues: +
+ ++ +concept BackInsertionContainer<typename C> : Container<C> { + void push_back(C&, value_type&&); +} ++Without the conversion of value to an rvalue, the assignment operator +fails to concept check. +
+ ++A solution is to modify the BackInsertionContainer concept so that +the client can pass in the parameter type for push_back similar to +what is already done for the OutputIterator concept: +
+ ++ +concept BackInsertionContainer<typename C, typename Value = C::value_type&&> + : Container<C> { + void push_back(C&, Value); +} ++This allows the assignment operator to be adjusted appropriately: +
+ ++ +requires BackInsertionContainer<Cont, Cont::value_type const&> && + CopyConstructible<Cont::value_type> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); +++-1- Effects: push_back(*container, value); ++[ +We may want to propagate this fix to other concepts such as StackLikeContainer. +]
+ + +[ +Solution and wording collaborated on by Doug and Howard. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++Howard notes that "these operations behaved efficiently until concepts were added." +
++Alisdair is uncertain that the proposed resolution is syntactically correct. +
++Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +
+Proposed resolution:
++Change 23.2.6.1 [container.concepts.free]: +
+ +++ +concept FrontInsertionContainer<typename C, typename Value = C::value_type&&> + : Container<C> { + void push_front(C&,+ +value_type&&Value); + + axiom FrontInsertion(C c,value_typeValue x) { + x == (push_front(c, x), front(c)); + } +} +...
+ +concept BackInsertionContainer<typename C, typename Value = C::value_type&&> + : Container<C> { + void push_back(C&,+ +value_type&&Value); +} +...
+ +concept InsertionContainer<typename C, typename Value = C::value_type&&> + : Container<C> { + iterator insert(C&, const_iterator,+ +value_type&&Value); + + axiom Insertion(C c, const_iterator position,value_typeValue v) { + v == *insert(c, position, v); + } +} ++Change 23.2.6.2 [container.concepts.member]: +
+ +++ +auto concept MemberFrontInsertionContainer<typename C, typename Value = C::value_type&&> + : MemberContainer<C> { + void C::push_front(+ +value_type&&Value); + + axiom MemberFrontInsertion(C c,value_typeValue x) { + x == (c.push_front(x), c.front()); + } +} +...
+ +auto concept MemberBackInsertionContainer<typename C, typename Value = C::value_type&&> + : MemberContainer<C> { + void C::push_back(+ +value_type&&Value); +} +...
+ +auto concept MemberInsertionContainer<typename C, typename Value = C::value_type&&> + : MemberContainer<C> { + iterator C::insert(const_iterator,+value_type&&Value); + + axiom MemberInsertion(C c, const_iterator position,value_typeValue v) { + v == *c.insert(position, v); + } +} ++Change 23.2.6.3 [container.concepts.maps]: +
+ +++ +template <MemberFrontInsertionContainer C, typename Value = C::value_type&&> +concept_map FrontInsertionContainer<C, Value> { + typedef Container<C>::value_type value_type; + + void push_front(C& c,+ +value_type&&Value v) { c.push_front(static_cast<value_type&&Value>(v)); } +} +...
+ +template <MemberBackInsertionContainer C, typename Value = C::value_type&&> +concept_map BackInsertionContainer<C, Value> { + typedef Container<C>::value_type value_type; + + void push_back(C& c,+ +value_type&&Value v) { c.push_back(static_cast<value_type&&Value>(v)); } +} +...
+ +template <MemberInsertionContainer C, typename Value = C::value_type&&> +concept_map InsertionContainer<C, Value> { + typedef Container<C>::value_type value_type; + Container<C>::iterator insert(C& c, Container<C>::const_iterator i,+ +value_type&&Value v) + { return c.insert(i, static_cast<value_type&&Value>(v)); } +} ++Change 24.7.1 [back.insert.iterator]: +
+ ++ +template <BackInsertionContainer Cont> +class back_insert_iterator { + ... + requires BackInsertionContainer<Cont, const Cont::value_type&> +CopyConstructible<Cont::value_type>+ back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... ++Change 24.7.2.2 [back.insert.iter.op=]: +
+ +++ +requires BackInsertionContainer<Cont, const Cont::value_type&> ++CopyConstructible<Cont::value_type>+ back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); ++-1- Effects: push_back(*container,+Cont::value_type(value)); ++Change 24.7.3 [front.insert.iterator]: +
+ ++ +template <FrontInsertionContainer Cont> +class front_insert_iterator { + ... + requires FrontInsertionContainer<Cont, const Cont::value_type&> +CopyConstructible<Cont::value_type>+ front_insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... ++Change 24.7.4.2 [front.insert.iter.op=]: +
+ +++ +requires FrontInsertionContainer<Cont, const Cont::value_type&> ++CopyConstructible<Cont::value_type>+ front_insert_iterator<Cont>& + operator=(const Cont::value_type& value); ++-1- Effects: push_front(*container,+Cont::value_type(value)); ++Change 24.7.5 [insert.iterator]: +
+ ++ +template <InsertionContainer Cont> +class insert_iterator { + ... + requires InsertionContainer<Cont, const Cont::value_type&> +CopyConstructible<Cont::value_type>+ insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... ++Change 24.7.6.2 [insert.iter.op=]: +
+ +++ + + + + + +requires InsertionContainer<Cont, const Cont::value_type&> ++CopyConstructible<Cont::value_type>+ insert_iterator<Cont>& + operator=(const Cont::value_type& value); ++++-1- Effects: +
++iter = insert(*container, iter,Cont::value_type(value)); +++iter; +
+978. Hashing smart pointers
+Section: 20.7.17 [unord.hash] Status: Open + Submitter: Alisdair Meredith Opened: 2009-02-02 Last modified: 2009-05-31
+View other active issues in [unord.hash].
+View all other issues in [unord.hash].
+View all issues with Open status.
+Discussion:
++I don't see an open issue on supporting std::hash for smart pointers +(unique_ptr and shared_ptr at least). +
++It seems reasonable to at least expect support for the smart +pointers, especially as they support comparison for use in ordered +associative containers. +
+ +[ +Batavia (2009-05): +]
+ +++ ++Howard points out that the client can always supply a custom hash function. +
++Alisdair replies that the smart pointer classes are highly likely +to be frequently used as hash keys. +
++Bill would prefer to be conservative. +
++Alisdair mentions that this issue may also be viewed as a subissue or +duplicate of issue 1025. +
++Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +
+[ +2009-05-31 Peter adds: +]
+ + +++ + + ++Howard points out that the client can always supply a custom hash function. +++Not entirely true. The client cannot supply the function that hashes the +address of the control block (the equivalent of the old operator<, now +proudly carrying the awkward name of 'owner_before'). Only the +implementation can do that, not necessarily via specializing hash<>, of +course. +
++This hash function makes sense in certain situations for shared_ptr +(when one needs to switch from set/map using ownership ordering to +unordered_set/map) and is the only hash function that makes sense for +weak_ptr. +
+Proposed resolution:
++
+ + + + + +
+979. Bad example
+Section: 24.5.3 [move.iterators] Status: Tentatively NAD Editorial + Submitter: Howard Hinnant Opened: 2009-02-03 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++24.5.3 [move.iterators] has an incorrect example: +
+ +++ ++-2- [Example: +
+ ++ +set<string> s; +// populate the set s +vector<string> v1(s.begin(), s.end()); // copies strings into v1 +vector<string> v2(make_move_iterator(s.begin()), + make_move_iterator(s.end())); // moves strings into v2 ++-- end example] +
++One can not move from a set because the iterators return const +references. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. Move to NAD Editorial. ++ + + +Proposed resolution:
++Change 24.5.3 [move.iterators]/2: +
+ +++ + + + + ++-2- [Example: +
+ ++ +setlist<string> s; +// populate thesetlist s +vector<string> v1(s.begin(), s.end()); // copies strings into v1 +vector<string> v2(make_move_iterator(s.begin()), + make_move_iterator(s.end())); // moves strings into v2 ++-- end example] +
+
+981. Unordered container requirements should add initializer_list support
+Section: 23.2.5 [unord.req] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2009-02-08 Last modified: 2009-05-23
+View other active issues in [unord.req].
+View all other issues in [unord.req].
+View all issues with Tentatively Ready status.
+Discussion:
++Refering to +N2800 +all container requirements tables (including those for +associative containers) provide useful member function overloads +accepting std::initializer_list as argument, the only exception is +Table 87. There seems to be no reason for not providing them, because 23.5 [unord] +is already initializer_list-aware. For the sake of +library interface consistency and user-expectations corresponding +overloads should be added to the table requirements of unordered +containers as well. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
+ ++In 23.2.5 [unord.req]/9 insert: +
+ ++... [q1, q2) is a valid range in a, il +designates an object of type initializer_list<value_type>, t is a value of type +X::value_type, ... ++ ++In 23.2.5 [unord.req], Table 87 insert: +
+ +++ + + + + + ++
+Table 87 - Unordered associative container requirements (in addition to container) ++ +Expression Return type Assertion/note
pre-/post-conditionComplexity ++ +X(i, j)
X a(i, j)X ... ... ++ +X(il) X +Same as X(il.begin(), il.end()). +Same as X(il.begin(), il.end()). ++ +... ... ... ... ++ +a = b X ... ... ++ +a = il X& +a = X(il); return *this; +Same as a = X(il). ++ +... ... ... ... ++ +a.insert(i, j) void ... ... ++ +a.insert(il) void +Same as a.insert(il.begin(), il.end()). +Same as a.insert(il.begin(), il.end()). +
+982. Wrong complexity for initializer_list assignment in Table 85
+Section: 23.2.4 [associative.reqmts] Status: Tentatively Ready + Submitter: Daniel Krügler Opened: 2009-02-08 Last modified: 2009-05-23
+View other active issues in [associative.reqmts].
+View all other issues in [associative.reqmts].
+View all issues with Tentatively Ready status.
+Discussion:
++According to +N2800, +the associative container requirements table 85 says + that assigning an initializer_list to such a container is of + constant complexity, which is obviously wrong. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
+ ++In 23.2.4 [associative.reqmts], Table 85 change: +
+ +++ + + + + + ++
+Table 85 - Associative container requirements (in addition to container) ++ +Expression Return type Assertion/note
pre-/post-conditionComplexity ++ +a = il X& a = X(il); +
return *this;+ constantSame as a = X(il).
+983. unique_ptr reference deleters should not be moved from
+Section: 20.8.12.2 [unique.ptr.single] Status: Review + Submitter: Howard Hinnant Opened: 2009-02-10 Last modified: 2009-05-23
+View other active issues in [unique.ptr.single].
+View all other issues in [unique.ptr.single].
+View all issues with Review status.
+Discussion:
++Dave brought to my attention that when a unique_ptr has a non-const reference +type deleter, move constructing from it, even when the unique_ptr containing +the reference is an rvalue, could have surprising results: +
+ ++ +D d(some-state); +unique_ptr<A, D&> p(new A, d); +unique_ptr<A, D> p2 = std::move(p); +// has d's state changed here? ++I agree with him. It is the unique_ptr that is the rvalue, not the +deleter. When the deleter is a reference type, the unique_ptr should +respect the "lvalueness" of the deleter. +
+ ++Thanks Dave. +
+ +[ +Batavia (2009-05): +]
+ ++Seems correct, but complicated enough that we recommend moving to Review. ++ + +Proposed resolution:
++Change 20.8.12.2.1 [unique.ptr.single.ctor], p20-21 +
+ +++ +template <class U, class E> unique_ptr(unique_ptr<U, E>&& u); ++ ++ +++-20- Requires: If
+ +DE 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. + +Otherwise E is a reference type and construction of the deleter +D from an lvalue 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). unique_ptr<U, E>::pointer shall be +implicitly convertible to pointer. [Note: These +requirements imply that T and U are complete types. +-- end note] ++-21- Effects: Constructs a unique_ptr which owns the +pointer which u owns (if any). If the deleter +E is not a reference type,
+ +itthis +deleter is move constructed from u's deleter, otherwise +the referencethis deleter is copy constructed +from u.'s deleter. After the construction, u no longer +owns a pointer. [Note: The deleter constructor can be implemented +with std::forward<DE>. -- end +note] ++Change 20.8.12.2.3 [unique.ptr.single.asgn], p1-3 +
+ +++ +unique_ptr& operator=(unique_ptr&& u); +++ +++-1- Requires: If the deleter D is not a reference type, +
+ +Aassignment of the deleter D from an rvalue D shall not throw an exception. + +Otherwise the deleter D is a reference type, +and assignment of the deleter D from an lvalue D shall not throw an exception. ++-2- Effects: reset(u.release()) followed by +an
+ +moveassignment fromu's deleter to this deleter+std::forward<D>(u.get_deleter()). ++-3- Postconditions: This unique_ptr now owns the pointer +which u owned, and u no longer owns it.
+[Note: If +D is a reference type, then the referenced lvalue deleters are +move assigned. -- end note]++Change 20.8.12.2.3 [unique.ptr.single.asgn], p6-7 +
+ +++ + + + + + +template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u); +++ +++Requires: If the deleter E is not a reference type, +
+ +Aassignment of the deleter D from an rvalue +DE shall not throw an exception. + +Otherwise the deleter E is a reference type, +and assignment of the deleter D from an lvalue E shall not throw an exception. +unique_ptr<U, E>::pointer shall be implicitly convertible to pointer. +[Note: These requirements imply that T and U> +are complete types. -- end note] ++Effects: reset(u.release()) followed by +an
+ +moveassignment fromu's deleter to this deleter+std::forward<E>(u.get_deleter()). +If either +D or E is a reference type, then the referenced lvalue +deleter participates in the move assignment.+
+984. Does <cinttypes> have macro guards?
+Section: 27.9.2 [c.files] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-02-12 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++The C standard says about <inttypes.h>: +
+ ++C++ implementations should define these macros only when __STDC_FORMAT_MACROSis defined +before <inttypes.h> is included. ++ ++The C standard has a similar note about <stdint.h>. For <cstdint> +we adopted a "thanks but no thanks" policy and documented that fact in +18.4.1 [cstdint.syn]: +
+ ++... [Note: The macros defined by <stdint> are +provided unconditionally. In particular, the symbols +__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS +(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. +-- end note] ++ ++I recommend we put a similar note in 27.9.2 [c.files] regarding <cinttypes>. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Add to 27.9.2 [c.files]: +
+ ++Table 112 describes header <cinttypes>. + +[Note: The macros defined by <cintypes> are +provided unconditionally. In particular, the symbol +__STDC_FORMAT_MACROS +(mentioned in C99 footnote 182) plays no role in C++. +-- end note] + ++ + + + + +
+985. Allowing throwing move
+Section: 23.2.1 [container.requirements.general] Status: Open + Submitter: Rani Sharoni Opened: 2009-02-12 Last modified: 2009-05-23
+View other active issues in [container.requirements.general].
+View all other issues in [container.requirements.general].
+View all issues with Open status.
+Discussion:
++Introduction +
+ +This proposal is meant to resolve potential regression of the +N2800 +draft, see +next section, and to relax the requirements for containers of types with +throwing move constructors.
+ +The basic problem is that some containers operations, like push_back, +have a strong exception safety +guarantee (i.e. no side effects upon exception) that are not achievable when +throwing move constructors are used since there is no way to guarantee revert +after partial move. For such operations the implementation can at most provide +the basic guarantee (i.e. valid but unpredictable) as it does with multi +copying operations (e.g. range insert).
+ +For example, vector<T>::push_back() (where T has a move +constructor) might resize the vector and move the objects to the new underlying +buffer. If move constructor throws it might +not be possible to recover the throwing object or to move the old objects back to +the original buffer.
+ +The current draft is explicit by disallowing throwing move +for some operations (e.g. vector<>::reserve) and not clear about other +operations mentioned in 23.2.1 [container.requirements.general]/10 +(e.g. single element insert): it guarantees strong exception +safety without explicitly disallowing a throwing move constructor. +
+ ++Regression +
+ +This section only refers to cases in which the contained object +is by itself a standard container.
+ +Move constructors of standard containers are allowed to throw and therefore +existing operations are broken, compared with C++03, due to move optimization. +(In fact existing implementations like Dinkumware are actually throwing).
+ +For example, vector< list<int> >::reserve yields +undefined behavior since list<int>'s move constructor is allowed to throw. +On the other hand, the same operation has strong exception safety guarantee in +C++03.
+ +There are few options to solve this regression:
+ ++
+ +- +Disallow throwing move and throwing default constructor +
+ +- +Disallow throwing move but disallowing usage after move +
+ +- +Special casing +
+ +- +Disallow throwing move and making it optional +
+ +Option 1 is suggested by proposal +N2815 +but it might not be applicable for existing implementations for which +containers default constructors are throwing.
+ +Option 2 limits the usage significantly and it's error prone +by allowing zombie objects that are nothing but destructible (e.g. no clear() +is allowed after move). It also potentially complicates the implementation by +introducing special state.
+ +Option 3 is possible, for example, using default +construction and swap instead of move for standard containers case. The +implementation is also free to provide special hidden operation for non +throwing move without forcing the user the cope with the limitation of option-2 +when using the public move.
+ +Option 4 impact the efficiency in all use cases due to rare throwing move.
+ +The proposed wording will imply option 1 or 3 though option 2 is also +achievable using more wording. I personally oppose to option 2 that has impact +on usability.
+ ++Relaxation for user types +
+ +Disallowing throwing move constructors in general seems very restrictive +since, for example, common implementation of move will be default construction ++ swap so move will throw if the +default constructor will throw. This is currently the case with the Dinkumware +implementation of node based containers (e.g. std::list) +though this section doesn't refer to standard types.
+ +For throwing move constructors it seem that the implementation should have +no problems to provide the basic guarantee instead of the strong one. It's +better to allow throwing move constructors with basic guarantee than to +disallow it silently (compile and run), via undefined behavior.
+ +There might still be cases in which the relaxation will break existing generic +code that assumes the strong guarantee but it's broken either way given a +throwing move constructor since this is not a preserving optimization.
+ +[ +Batavia (2009-05): +]
+ +++ + ++Bjarne comments (referring to his draft paper): +"I believe that my suggestion simply solves that. +Thus, we don't need a throwing move." +
++Move to Open and recommend it be deferred until after the next +Committee Draft is issued. +
+Proposed resolution:
+ ++23.2.1 [container.requirements.general] paragraph 10 add footnote: +
+ +++ ++-10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and +23.2.6.4) all container types defined in this Clause meet the following +additional requirements: +
++
+ +- ...
++[Note: for compatibility with C++ +2003, when "no effect" is required, standard containers should not use the +value_type's throwing move constructor when the contained object is by itself a +standard container. -- end note] +
+ +23.2.5.1 [unord.req.except] change paragraph 2 to say:
+ +++ ++-2- For unordered associative containers, if an exception is +thrown by any operation other than the container's hash function from within an +insert() function inserting a single element, the insert() +function has no effect unless the exception is thrown by the contained +object move constructor. +
+ ++-4- For unordered associative containers, if an exception is +thrown from within a rehash() function other than by the container's hash +function or comparison function, the rehash() function has no effect +unless the exception is thrown by the contained +object move constructor.
+ ++23.3.2.3 [deque.modifiers] change paragraph 2 to say: +
+ ++-2- Remarks: If an exception is thrown other than by +the copy constructor, move constructor +or assignment operator of T +there are no effects. +If an exception is thrown by push_back() or emplace_back() +function, that function has no effects unless the exception is thrown by +the move constructor of T. ++ ++23.3.2.3 [deque.modifiers] change paragraph 6 to say: +
+ ++-6- Throws: Nothing unless an exception is thrown by the copy +constructor, move constructor or assignment operator of T. ++ ++23.3.6.2 [vector.capacity] remove paragraph 2 +
+ +++ +-2- Requires: If value_type has a move constructor, +that constructor shall not throw any exceptions.++23.3.6.2 [vector.capacity] paragraph 3 change to say: +
+ ++-3- Effects: A directive that informs a vector +of a planned change in size, so +that it can manage the storage allocation accordingly. After reserve(), +capacity() is greater or equal to the argument of reserve +if reallocation happens; and equal +to the previous value of capacity() +otherwise. Reallocation happens at this point if and only if the current +capacity is less than the argument of reserve(). +If an exception is thrown, there are no effects +unless the exception is thrown by the contained object move constructor. ++ ++23.3.6.2 [vector.capacity] paragraph 12 change to say: +
+ ++-12- Requires:+ +If value_type has a move constructor, +that constructor shall not throw any exceptions.+If an exception is thrown, there are no effects unless the exception is thrown by +the contained object move constructor. ++23.3.6.4 [vector.modifiers] change paragraph 1 to say: +
+ ++-1-+ +Requires: If value_type has a move constructor, +that constructor shall not throw any exceptions.+Remarks: If an exception is thrown by push_back() +or emplace_back() function, that function has no effect unless the +exception is thrown by the move constructor of T. ++23.3.6.4 [vector.modifiers] change paragraph 2 to say: +
+ ++-2- Remarks: Causes reallocation if the new size is greater than +the old capacity. If no reallocation happens, all the iterators and +references before the insertion point remain valid. If an exception is +thrown other than by the copy constructor, move constructor +or assignment operator of T or by any InputIterator +operation there are no effects. ++ ++23.3.6.4 [vector.modifiers] change paragraph 6 to say: +
+ ++-6- Throws: Nothing unless an exception is thrown by the copy +constructor, move constructor or assignment operator of T. ++ + + + + + +
+986. Generic try_lock contradiction
+Section: 30.4.4 [thread.lock.algorithm] Status: Tentatively Ready + Submitter: Chris Fairles Opened: 2009-02-14 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++In 30.4.4 [thread.lock.algorithm], the generic try_lock effects (p2) say that a failed +try_lock is when it either returns false or throws an exception. In +the event a call to try_lock does fail, by either returning false or +throwing an exception, it states that unlock shall be called for all +prior arguments. Then the returns clause (p3) goes on to state +in a note that after returning, either all locks are locked or none +will be. So what happens if multiple locks fail on try_lock? +
+ ++Example: +
+ ++ +#include <mutex> + +int main() { + std::mutex m0, m1, m2; + std::unique_lock<std::mutex> l0(m0, std::defer_lock); + std::unique_lock<std::mutex> l1(m1); //throws on try_lock + std::unique_lock<std::mutex> l2(m2); //throws on try_lock + + int result = std::try_lock(l0, l1, l2); + + assert( !l0.owns_lock() ); + assert( l1.owns_lock() ); //?? + assert( l2.owns_lock() ); //?? +} ++The first lock's try_lock succeeded but, being a prior argument to a +lock whose try_lock failed, it gets unlocked as per the effects clause +of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return +clause states that either all arguments shall be locked or none will +be. This seems to be a contradiction unless the intent is for +implementations to make an effort to unlock not only prior arguments, +but the one that failed and those that come after as well. Shouldn't +the note only apply to the arguments that were successfully locked? +
+ ++Further discussion and possible resolutions in c++std-lib-23049. +
+ +[ +Summit: +]
+ ++Move to review. Agree with proposed resolution. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
+ ++Change 30.4.4 [thread.lock.algorithm], p2: +
+ ++-2- Effects: Calls try_lock() for each argument in order +beginning with the first until all arguments have been processed or a +call to try_lock() fails, either by returning false or by throwing an +exception. If a call to try_lock() fails, unlock() shall be called for +all prior arguments and there shall be no further calls to try_lock(). ++ ++Delete the note from 30.4.4 [thread.lock.algorithm], p3 +
+ ++-3- Returns: -1 if all calls to try_lock() returned true, +otherwise a 0-based index value that indicates +the argument for which try_lock() returned false.+ + + + + +[Note: +On return, either all arguments will be +locked or none will be locked. -- end note]+
+987. reference_wrapper and function types
+Section: 20.7.5 [refwrap] Status: Review + Submitter: Howard Hinnant Opened: 2009-02-18 Last modified: 2009-05-23
+View all other issues in [refwrap].
+View all issues with Review status.
+Discussion:
++The synopsis in 20.7.5 [refwrap] says: +
+ ++ +template <ObjectType T> class reference_wrapper +... ++And then paragraph 3 says: +
+ +++ ++The template instantiation reference_wrapper<T> shall be +derived from std::unary_function<T1, R> only if the type +T is any of the following: +
+ ++
+- +a function type or a pointer to function type taking one argument of +type T1 and returning R +
++But function types are not ObjectTypes. +
+ ++Paragraph 4 contains the same contradiction. +
+ +[ +Post Summit: +]
+ + +++ ++Jens: restricted reference to ObjectType +
++Recommend Review. +
+[ +Post Summit, Peter adds: +]
+ + +++ ++In https://svn.boost.org/trac/boost/ticket/1846 +however Eric Niebler makes the very reasonable point that reference_wrapper<F>, +where F is a function type, represents a reference to a function, +a legitimate entity. So boost::ref was changed to allow it. +
++https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp +
++Therefore, I believe an alternative proposed resolution for issue 987 could simply +allow reference_wrapper to be used with function types. +
+[ +Post Summit, Howard adds: +]
+ + +++ + + ++I agree with Peter (and Eric). I got this one wrong on my first try. Here +is code that demonstrates how easy (and useful) it is to instantiate +reference_wrapper with a function type: +
+ ++ +#include <functional> + +template <class F> +void test(F f); + +void f() {} + +int main() +{ + test(std::ref(f)); +} ++Output (link time error shows type of reference_wrapper instantiated +with function type): +
+ ++ +Undefined symbols: + "void test<std::reference_wrapper<void ()()> >(std::reference_wrapper<void ()()>)",... ++I've taken the liberty of changing the proposed wording to allow function types +and set to Open. I'll also freely admit that I'm not positive ReferentType +is the correct concept. +
+ +[ +Batavia (2009-05): +]
+ +++ ++Howard observed that FunctionType, +a concept not (yet?) in the Working Paper, +is likely the correct constraint to be applied. +However, the proposed resolution provides an adequate approximation. +
++Move to Review. +
+[ +2009-05-23 Alisdair adds: +]
+ + +++ + + ++By constraining to PointeeType we rule out the ability for T to be a +reference, and call in reference-collapsing. I'm not sure if this is +correct and intended, but would like to be sure the case was considered. +
++Is dis-allowing reference types and the +implied reference collapsing the intended result? +
+Proposed resolution:
++Change the synopsis in 20.7 [function.objects]: +
+ ++ +// 20.6.5, reference_wrapper: +template <ObjectTypeReferentType T> + requires PointeeType<T> + class reference_wrapper; + +template <ObjectTypePointeeType T> + reference_wrapper<T> ref(T&); + +template <ObjectTypePointeeType T> + reference_wrapper<const T> cref(const T&); + +template <ObjectTypePointeeType T> + reference_wrapper<T> ref(reference_wrapper<T>); +template <ObjectTypePointeeType T> + reference_wrapper<const T> cref(reference_wrapper<T>); ++Change the synopsis in 20.7.5 [refwrap]: +
+ ++ +template <ObjectTypeReferentType T> + requires PointeeType<T> + class reference_wrapper + ... ++Change the prototypes in 20.7.5.5 [refwrap.helpers]: +
+ ++ + + +template <ObjectTypePointeeType T> + reference_wrapper<T> ref(T&); +... +template <ObjectTypePointeeType T> + reference_wrapper<const T> cref(const T&); +... +template <ObjectTypePointeeType T> + reference_wrapper<T> ref(reference_wrapper<T>); +... +template <ObjectTypePointeeType T> + reference_wrapper<const T> cref(reference_wrapper<T>); +Rationale:
++a) The occurrence of T& in the function signature auto-implies +std::ReferentType, +this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4 +
++b) The occurrence of the constrained template reference_wrapper<T> in +the remaining +signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of +this template. But we need to add at least *one* requirement (and it +was an arbitrary, +but natural decision to require std::PointeeType here) to *activate* +this. If we hadn't done +this, we were in unconstrained mode! +
+ + + + + +
+988. Reflexivity meaningless?
+Section: 20.2.6 [concept.comparison] Status: Tentatively NAD + Submitter: Alisdair Meredith Opened: 2009-02-24 Last modified: 2009-05-23
+View other active issues in [concept.comparison].
+View all other issues in [concept.comparison].
+View all issues with Tentatively NAD status.
+Discussion:
++20.2.6 [concept.comparison] p2: +
++Due to the subtle meaning of == inside axioms, the Reflexivity axiom does +not do anything as written. It merely states that a value is substitutable +with itself, rather than asserting a property of the == operator. +
+ + +Original proposed resolution: + + ++Change the definition of Reflexivity in 20.2.6 [concept.comparison]: +
+ ++ +axiom Reflexivity(T a) { (a == a) == true; } +[ +Post Summit: +]
+ + +++ + + ++Alisdair: I was wrong. +
++Recommend NAD. +
+Proposed resolution:
++NAD. +
+ + + + + +
+989. late_check and library
+Section: 17 [library] Status: Open + Submitter: Alisdair Meredith Opened: 2009-02-24 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
++The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup +inside a constrained context, and so inhibit concept map adaption by users +to meet template requirements. +
++Do we need some text in clause 17 prohibitting use of late_check in library +template definitions unless otherwise documented? +
+ +[ +Doug adds: +]
+ + ++We need something like this, but it should be a more general statement +about implementations respecting the concept maps provided by the +user. Use of late_check is one way in which implementations can +subvert the concept maps provided by the user, but there are other +ways as well ("pattern-based" overloading, tricks with "auto" concept +maps and defaulted associated type arguments). ++ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending proposed wording from Alisdair and/or Doug for further review. ++ + +Proposed resolution:
+ + + + + +
+990. monotonic_clock::is_monotonic must be true
+Section: 20.9.5.2 [time.clock.monotonic] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-03-09 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++There is some confusion over what the value of monotonic_clock::is_monotonic +when monotonic_clock is a synonym for system_clock. The +intent is that if monotonic_clock exists, then monotonic_clock::is_monotonic +is true. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change 20.9.5.2 [time.clock.monotonic], p1: +
+ ++-1- Objects of class monotonic_clock represent clocks for which +values of time_point never decrease as physical time advances. +monotonic_clock may be a synonym for system_clock +if and only if system_clock::is_monotonic is +true. ++ + + + + +
+991. Response to JP 50
+Section: 22.3.3.2.2 [conversions.string] Status: Tentatively Ready + Submitter: P.J. Plauger Opened: 2009-03-03 Last modified: 2009-05-23
+View other active issues in [conversions.string].
+View all other issues in [conversions.string].
+View all issues with Tentatively Ready status.
+Discussion:
++Add custom allocator parameter to wstring_convert, since we cannot +allocate memory for strings from a custom allocator. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 22.3.3.2.2 [conversions.string]: +
+ ++ +template<class Codecvt, class Elem = wchar_t, + class Wide_alloc = std::allocator<Elem>, + class Byte_alloc = std::allocator<char> > class wstring_convert { + public: + typedef std::basic_string<char, char_traits<char>, Byte_alloc> byte_string; + typedef std::basic_string<Elem, char_traits<Elem>, Wide_alloc> wide_string; + ... ++Change 22.3.3.2.2 [conversions.string], p3: +
+ ++-3- The class template describes an ob ject that controls conversions +between wide string ob jects of class +std::basic_string<Elem, char_traits<Elem>, Wide_alloc> +and byte string objects of class +std::basic_string<char, char_traits<char>, Byte_alloc> ++ + + + + + +(also known as std::string). +
+992. Response to UK 169
+Section: 17.6.1.1 [contents] Status: Open + Submitter: P.J. Plauger Opened: 2009-03-03 Last modified: 2009-05-23
+View other active issues in [contents].
+View all other issues in [contents].
+View all issues with Open status.
+Discussion:
++This phrasing contradicts later freedom to implement the C standard +library portions in the global namespace as well as std. (17.6.2.3p4) +
+ +[ +Batavia (2009-05): +]
+ ++The proposed wording seems to go too far. +Move back to Open. ++ + +Proposed resolution:
++Change 17.6.1.1 [contents], p2: +
+ ++-2- All library entities except those from the Standard C +library, macros, operator new and operator +delete are defined within the namespace std or namespaces +nested within namespace std. ++ + + + + + +
+993. Response to UK 188
+Section: 18.5 [support.start.term] Status: Tentatively Ready + Submitter: P.J. Plauger Opened: 2009-03-03 Last modified: 2009-05-23
+View all other issues in [support.start.term].
+View all issues with Tentatively Ready status.
+Discussion:
++The function _Exit does not appear to be defined in this standard. +Should it be added to the table of functions included-by-reference to +the C standard? +
+ +[ +2009-05-09 Alisdair fixed some minor issues in the wording. +]
+ + +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Add to 18.5 [support.start.term] Table 20 (Header +<cstdlib> synopsis) Functions: +
+ ++ +_Exit ++Add before the description of abort(void): +
+ ++ + + + + + +void _Exit [[noreturn]] (int status) ++ ++++The function _Exit(int status) has additional behavior in this +International Standard: +
++
+- +The program is terminated without executing destructors for objects of +automatic, thread, or static storage duration and without calling the +functions passed to atexit() (3.6.3 [basic.start.term]). +
+
+994. Response to UK 193
+Section: 18.6.2.2 [new.handler] Status: Tentatively Ready + Submitter: P.J. Plauger Opened: 2009-03-03 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++quick_exit has been added as a new valid way to terminate a program in a +well defined way +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 18.6.2.2 [new.handler], p2: +
+ +++ + + + + + + ++-2- Required behavior: ... +
++
+- ...
+- +
+call either abort() or exit();+terminate execution of the program without returning to the caller +
+995. Operational Semantics Unclear
+Section: 17.5.1.3 [structure.requirements] Status: Tentatively NAD + Submitter: David Abrahams Opened: 2009-03-06 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
+Discussion:
++As a practical matter there's disagreement on the meaning of operational +semantics. If the text in 17.5.1.3 [structure.requirements]p4 isn't +clear, it should be clarified. However, it's not clear whether the +disagreement is merely due to people not being aware of the text. +
+ +[ +Batavia (2009-05): +]
+ ++Agree with the recommended NAD resolution. ++ + +Proposed resolution:
++Recommend NAD. The text in 17.5.1.3 [structure.requirements] is +perfectly clear. +
+ + + + + +
+996. Move operation not well specified
+Section: 17 [library] Status: Open + Submitter: David Abrahams Opened: 2009-03-06 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
++There are lots of places in the standard where we talk about "the move +constructor" but where we mean "the move operation," i.e. T( move( x ) ). +
++We also don't account for whether that operation modifies x or not, and +we need to. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending proposed wording from Dave for further +review. ++ + +Proposed resolution:
++
+ + + + + +
+997. Response to UK 163
+Section: 17.5.1.4 [structure.specifications] Status: Tentatively Ready + Submitter: Thomas Plum Opened: 2009-03-03 Last modified: 2009-05-23
+View other active issues in [structure.specifications].
+View all other issues in [structure.specifications].
+View all issues with Tentatively Ready status.
+Discussion:
++Many functions are defined as "Effects: Equivalent to a...", which seems +to also define the preconditions, effects, etc. But this is not made +clear. +
+ ++After studying the occurrences of "Effects: Equivalent to", I agree with +the diagnosis but disagree with the solution. In 21.4.2 [string.cons] +we find +
+ +++ ++14 Effects: If InputIterator is an integral type, equivalent to +basic_string(static_cast<size_type>(begin), static_cast<value_type>(end), a) +
++15 Otherwise constructs a string from the values in the range [begin, +end), as indicated in the Sequence Requirements table (see 23.1.3). +
++This would be devishly difficult to re-write with an explicit +"Equivalent to:" clause. Instead, I propose the following, which will +result in much less editorial re-work. +
+ +[ +2009-05-09 Alisdair adds: +]
+ + ++This issue is related to 492. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Add a new paragraph after 17.5.1.4 [structure.specifications], p3: +
+ +++ + + + + + ++-3- Descriptions of function semantics contain the following elements (as appropriate):154 +
+ ++
+ +- +Requires: the preconditions for calling the function +
+- +Effects: the actions performed by the function +
+- +Postconditions: the observable results established by the function +
+- +Returns: a description of the value(s) returned by the function +
+- +Throws: any exceptions thrown by the function, and the conditions that would cause the exception +
+- +Complexity: the time and/or space complexity of the function +
+- +Remarks: additional semantic constraints on the function +
+- +Error conditions: the error conditions for error codes reported by the function. +
+- +Notes: non-normative comments about the function +
++Whenever the Effects element specifies that the semantics of some +function F are Equivalent to some code-sequence, then +the various elements are interpreted as follows. If F's +semantics specifies a Requires element, then that requirement is +logically imposed prior to the equivalent-to semantics. Then, +the semantics of the code-sequence are determined by the +Requires, Effects, Postconditions, Returns, +Throws, Complexity, Remarks, Error +Conditions and Notes specified for the (one or more) function +invocations contained in the code-sequence. The value returned from +F is specified by F's Returns element, or +if F has no Returns element, a non-void return from F is specified +by the Returns elements in code-sequence. If +F's semantics contains a Throws (or +Postconditions, or Complexity) element, then that +supersedes any occurrences of that element in the code-sequence. +
+
+998. Smart pointer referencing its owner
+Section: 20.8.12.2.5 [unique.ptr.single.modifiers] Status: Tentatively Ready + Submitter: Pavel Minaev Opened: 2009-02-26 Last modified: 2009-05-23
+View other active issues in [unique.ptr.single.modifiers].
+View all other issues in [unique.ptr.single.modifiers].
+View all issues with Tentatively Ready status.
+Discussion:
++Consider the following (simplified) implementation of +std::auto_ptr<T>::reset(): +
+ ++ +void reset(T* newptr = 0) { + if (this->ptr && this->ptr != newptr) { + delete this->ptr; + } + this->ptr = newptr; +} ++Now consider the following code which uses the above implementation: +
+ ++ +struct foo { + std::auto_ptr<foo> ap; + foo() : ap(this) {} + void reset() { ap.reset(); } +}; +int main() { + (new foo)->reset(); +} ++With the above implementation of auto_ptr, this results in U.B. at the +point of auto_ptr::reset(). If this isn't obvious yet, let me explain +how this goes step by step: +
+ ++
+ +- +foo::reset() entered +
+- +auto_ptr::reset() entered +
+- +auto_ptr::reset() tries to delete foo +
+- +foo::~foo() entered, tries to destruct its members +
+- +auto_ptr::~auto_ptr() executed - auto_ptr is no longer a valid object! +
+- +foo::~foo() left +
+- +auto_ptr::reset() sets its "ptr" field to 0 <- U.B.! auto_ptr +is not a valid object here already! +
+[ +Thanks to Peter Dimov who recognized the connection to unique_ptr and +brought this to the attention of the LWG, and helped with the solution. +]
+ + +[ +Howard adds: +]
+ + ++To fix this behavior reset must be specified such that deleting the +pointer is the last action to be taken within reset. ++ +[ +Alisdair adds: +]
+ + +++ ++The example providing the rationale for LWG 998 is poor, as it relies on +broken semantics of having two object believing they are unique owners of a +single resource. It should not be surprising that UB results from such +code, and I feel no need to go out of our way to support such behaviour. +
++If an example is presented that does not imply multiple ownership of a +unique resource, I would be much more ready to accept the proposed +resolution. +
+[ +Batavia (2009-05): +]
+ +++ + + ++Howard summarizes: +
++This issue has to do with circular ownership, +and affects auto_ptr, too (but we don't really care about that). +It is intended to spell out the order in which operations must be performed +so as to avoid the possibility +of undefined behavior in the self-referential case. +++Howard points to message c++std-lib-23175 for another example, +requested by Alisdair. +
++We agree with the issue and with the proposed resolution. +Move to Tentatively Ready. +
+Proposed resolution:
++Change 20.8.12.2.5 [unique.ptr.single.modifiers], p5 (Effects clause for reset), and p6: +
+ +++ + + + + ++-5- Effects:
+ +If get() == nullptr there are no effects. Otherwise get_deleter()(get()).+Assigns p to the stored pointer, and then if the old value of the pointer is not +equal to nullptr, calls get_deleter()(the old value of the pointer). +[Note: The order of these operations is significant because the call to get_deleter() +may destroy *this. -- end note] ++-6- Postconditions: get() == p. +[Note: The postcondition does not hold if the call to +get_deleter() destroys *this since this->get() is no longer a valid +expression. -- end note] +
+
+999. Taking the address of a function
+Section: 20.8.11.1 [object.addressof] Status: Tentatively Ready + Submitter: Peter Dimov Opened: 2009-03-09 Last modified: 2009-05-23
+View other active issues in [object.addressof].
+View all other issues in [object.addressof].
+View all issues with Tentatively Ready status.
+Discussion:
++The same fix (reference 987) may be applied to addressof, which is also constrained to +ObjectType. (That was why boost::ref didn't work with functions - it +tried to apply boost::addressof and the reinterpret_cast<char&> +implementation of addressof failed.) +
+ + + +[ +Batavia (2009-05): +]
+ +++ + + ++We agree. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change the synopsis in 20.8 [memory]: +
+ ++ +template <ObjectTypePointeeType T> + T* addressof(T& r); ++Change 20.8.11.1 [object.addressof]: +
+ ++ + +template <ObjectTypePointeeType T> + T* addressof(T& r); +Rationale:
++a) The occurrence of T& in the function signature auto-implies +std::ReferentType, +this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4 +
+ + + + + +
+1000. adjacent_find is over-constrained
+Section: 25.3.8 [alg.adjacent.find] Status: Open + Submitter: Chris Jefferson Opened: 2009-03-09 Last modified: 2009-03-13
+View all other issues in [alg.adjacent.find].
+View all issues with Open status.
+Discussion:
++Addresses UK 296 +
+ ++adjacent_find in C++03 allows an arbitrary predicate, but in C++0x +EqualityComparable/EquivalenceRelation is required. This forbids a +number of use cases, including: +
+++ ++
++ ++adjacent_find(begin, end, less<double>) + ++Find the first +place where a range is not ordered in decreasing order - in use to check +for sorted ranges. + ++ ++adjacent_find(begin, end, DistanceBiggerThan(6) ) ) + ++Find the first +place in a range where values differ by more than a given value - in use +to check an algorithm which produces points in space does not generate +points too far apart. + ++A number of books use predicate which are not equivalence relations in +examples, including "Thinking in C++" and "C++ Primer". +
+ ++Adding the requirement that the predicate is an EquivalenceRelation +does not appear to open up any possibility for a more optimised algorithm. +
+ + + +Proposed resolution:
++Change the definition of adjacent_find in the synopsis of 25 [algorithms] +and 25.3.8 [alg.adjacent.find] to: +
+ ++ + + + + +template<ForwardIterator Iter> + requiresEqualityComparableHasEqualTo<Iter::value_type, Iter::value_type> + Iter adjacent_find(Iter first, Iter last); + +template<ForwardIterator Iter,EquivalenceRelationPredicate<auto, Iter::value_type, Iter::value_type> Pred> + requires CopyConstructible<Pred> + Iter adjacent_find(Iter first, Iter last, Pred pred); +
+1001. Pointers, concepts and headers
+Section: 17 [library] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-10 Last modified: 2009-06-16
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Review status.
+Discussion:
+ +Addresses UK 78
+ ++Related to 1063. +
+ ++This is effectively an extension of LWG issue 343. +
++We know there is an increasing trend (encouraged by conformance testers and +some users) that each library header should supply no more than required to +satisfy the synopsis in the standard. This is typically achieved by +breaking larger headers into smaller subsets, and judicious use of forward +declarations. +
++If we apply this policy to C++0x (per +N2800) +it will be very surprising for +people using library algorithms over ranges defined by pointers that they +must #include <iterator_concepts> for their code to compile again. That is +because pointers do not satisfy any of the iterator concepts without the +concept_map supplied in this header. +
++Therefore, I suggest we should require all library headers that make use of +iterator concepts are specifically required to #include <iterator_concepts>. +
++At a minimum, the list of headers would be: (assuming all are constrained by +concepts) +
++ +algorithm +array +deque +forward_list +initializer_list +iterator +locale +list +map +memory // if 1029 is adopted +memory_concepts +numeric +random +regex +set +string +tuple +unordered_map +unordered_set +utility +vector +[ +Ganesh adds: +]
+ + +++ ++The same problems exists for <memory_concepts> and +<container_concepts>. +
++In order to compile <vector> you just need the +definitions of the concepts in <memory_concepts>, the +concept maps defined there are not necessary. Yet, from the user point +of view, if the concept map template for AllocatableElement are +not in scope, <vector> is pretty useless. Same for +<tuple> and ConstructibleWithAllocator. +
++Similarly, <queue> is not very useful if the concept map +template for QueueLikeContainer is not in scope, although the +definition of concept alone is theoretically sufficient. +
++There's a pattern here: if a concept has concept maps "attached", they +should never be separated. +
+[ +Beman provided the proposed resolution for the May 2009 mailing. He +comments: +]
+ + ++ ++ +Initially I tried to specify exactly what header should include what other +headers. This was verbose, error prone, hard to maintain, and appeared to add +little value compared to just stating the general rule.
+ +[ +Batavia (2009-05): +]
+ +++ ++Pete believes the proposed wording overconstrains implementers. +Instead of specifying the mechanism, +he prefers a solution that spells out what needs to be declared, +rather than how those declarations are to be provided, +e.g., +
++A C++ header shall provide the names +that are required to be defined in that header. +++Bill suggests approaching the wording from a programmer's perspective. +We may want to consider promising that certain widely-used headers +(e.g., the concept headers) are included when needed by other headers. +He feels, however, there is nothing broken now, +although we may want to consider "something nicer." +
++Move to Open status. +
+ +[ +2009-06-16 Beman updated the proposed resolution: +]
+ + +++ + + ++
+- The mechanism is no longer specified, as requested in Batavia.
+- The footnote has been removed since it specified mechanism and also did + not reflect existing practice.
+- A sentence was added that makes it clear that the existing practice is + permitted.
+Proposed resolution:
+Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:
+++ + + + + + +A C++ + header shall provide definitions for any names that appear in its synopsis (3.2 [basic.def.odr]). + A C++ header may include other C++ headers.
+ +[footnote]A C++ + header shown in its synopsis as including other C++ headers shall provide + definitions for the same names as if those other headers were included. A C++ header that uses a + concept (14.10 [concept]) shall provide the definition for that concept as if it included the C++ header + that defines that concept in its synopsis. The mechanism and ordering of such + definitions is unspecified.[Example: If C++ header
+ +<a>
contains a concept + defined in C++ header<b>
, and header<b>
contains a + concept defined in C++ header<c>
, then inclusion of<a>
+ is equivalent to inclusion of<a>
,<b>
, and+ <c>
. — end example]+
[footnote] C++ headers must include a C++ header that contains + any needed definition (3.2).
+1002. Response to UK 170
+Section: 17.6.1.2 [headers] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all other issues in [headers].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 170
+ ++One of goals of C++0x is to make language easier to teach and for +'incidental' programmers. The fine-grained headers of the C++ library +are valuable in large scale systems for managing dependencies and +optimising build times, but overcomplicated for simple development and +tutorials. Add additional headers to support the whole library through a +single include statement. +
+ +[ +Batavia (2009-05): +]
+ ++We do not all agree that this is an issue, +but we agree that if it needs solving this is the right way to do it. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5 +
++An additional header <std> shall have the effect of +supplying the entire standard library. [Note: for example, it +might be implemented as a file with an #include statement for each of the +headers listed in tables 13 and 14. -- end note] ++ + + + + +
+1003. Response to JP 23
+Section: 17.6.1.3 [compliance] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [compliance].
+View all other issues in [compliance].
+View all issues with Review status.
+Discussion:
+ +Addresses JP 23
+ ++There is a freestanding implementation including +<type_traits>, <array>, +<ratio>, lately added to Table 13, C++ library headers. +Programmers think them useful and hope that these headers are also added +to Table 15, C++ headers for freestanding implementations, that shows +the set of headers which a freestanding implementation shall include at +least. +
+ +Original proposed resolution
+ ++Add <type_traits>, <array>, +<ratio> to Table 15. +
+ +[ +Summit: +]
+ + +++ ++ The <array> header has far too many dependencies to require for a +free-standing implementation. +
++The <ratio> header would be useful, has no dependencies, but is not +strictly necessary. +
++The <type_traits> header is fundamentally a core language facility with a +library interface, so should be supported. +
+ ++(it is anticipated the resolution will come via an update to paper +N2814) +(see also LWG 833) +
+[ +Batavia (2009-05): +]
+ ++Leave in Review status pending a paper on freestanding implementations +by Martin Tasker. ++ + +Proposed resolution:
++Add <type_traits> to Table 15. +
+ + + + + + +
+1004. Response to UK 179
+Section: 17.6.3.8 [res.on.functions] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all other issues in [res.on.functions].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 179
+ ++According to the 4th bullet there is a problem if "if any replacement +function or handler function or destructor operation throws an +exception". There should be no problem throwing exceptions so long as +they are caught within the function. +
+ +[ +Batavia (2009-05): +]
+ ++The phrasing "throws an exception" is commonly used elsewhere +to mean "throws or propagates an exception." +Move to Open pending a possible more general resolution. ++ + +Proposed resolution:
++Change the 4th bullet of 17.6.3.8 [res.on.functions], p2: +
+ +++ + + + + + ++
+- +if any replacement function or handler function or destructor operation +
+throwspropagates an exception, unless specifically +allowed in the applicable Required behavior: paragraph. +
+1005. Response to JP 26
+Section: 18.3.1.1 [numeric.limits] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-25
+View all issues with Review status.
+Discussion:
+ +Addresses JP 26
+ ++numeric_limits [partial specializations] does not use concept. +
+ +[ +Summit: +]
+ + ++Alisdair will provide a soltion as part of treatment of axioms and LWG 902. ++ +[ +Post Summit: +]
+ + ++Alisdair recommends NAD as the partial specializations are already +constrained by requirements on the primary template. ++ +[ +Batavia (2009-05): +]
+ ++The Working Draft does not in general repeat a primary template's constraints +in any specializations. +Move to NAD. ++ +[ +2009-05-25 Howard adds: +]
+ + ++A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the +correct resolution of this issue. Indeed the discussion also casts doubt that +the current proposed wording is the correct resolution as well. Personally I'm +inclined to reset the status to Open. However I'm reverting the status to +that which it had prior to the Batavia recommendation. I'm setting back to Review. ++ + +Proposed resolution:
++Change 18.3.1.1 [numeric.limits]: +
+ ++ + + + + + +template<classRegular T> class numeric_limits<const T>; +template<classRegular T> class numeric_limits<volatile T>; +template<classRegular T> class numeric_limits<const volatile T>; +
+1006. Response to UK 190
+Section: 18.6.1 [new.delete] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all other issues in [new.delete].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 190
+ ++It is not entirely clear how the current specification acts in the +presence of a garbage collected implementation. +
+ +[ +Summit: +]
+ + ++Agreed. ++ +[ +2009-05-09 Alisdair adds: +]
+ + ++Proposed wording is too strict for implementations that do not support +garbage collection. Updated wording supplied. ++ +[ +Batavia (2009-05): +]
+ ++We recommend advancing this to Tentatively Ready +with the understanding that it will not be moved for adoption +unless and until the proposed resolution to Core issue #853 is adopted. ++ + +Proposed resolution:
+ ++(Editorial note: This wording ties into the proposed +resolution for Core #853) +
+ ++Add paragraphs to 18.6.1.1 [new.delete.single]: +
+ ++ +void operator delete(void* ptr) throw(); ++ +void operator delete(void* ptr, const std::nothrow_t&) throw();+[ +The second signature deletion above is editorial. +]
+ + +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-10- ...
+void operator delete(void* ptr, const std::nothrow_t&) throw(); ++ +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-15- ...
++Add paragraphs to 18.6.1.2 [new.delete.array]: +
+ ++ + +void operator delete[](void* ptr) throw(); ++ +void operator delete[](void* ptr, const std::nothrow_t&) throw();+[ +The second signature deletion above is editorial. +]
+ + +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-9- ...
+void operator delete[](void* ptr, const std::nothrow_t&) throw(); ++ +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-13- ...
++Add paragraphs to 18.6.1.3 [new.delete.placement]: +
+ ++ + + + + + +void operator delete(void* ptr, void*) throw(); ++ +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-7- ...
+void operator delete[](void* ptr, void*) throw(); ++ +++ ++Requires: If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then ptr shall +be a safely-derived pointer. +
+ +-9- ...
+
+1007. Response to JP 29
+Section: 18.8.6 [except.nested] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-13
+View other active issues in [except.nested].
+View all other issues in [except.nested].
+View all issues with Open status.
+Discussion:
+ +Addresses JP 29
+ ++throw_with_nested does not use concept. +
+ +[ +Summit: +]
+ + ++Agreed. ++ + + +Proposed resolution:
+ ++Alisdair initially proposed wording in +N2619. +
++We are awaiting an updated paper based on feedback from the San Francisco +review. +
+ + + + + +
+1008. Response to JP 31
+Section: 18.8.6 [except.nested] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-13
+View other active issues in [except.nested].
+View all other issues in [except.nested].
+View all issues with Open status.
+Discussion:
+ +Addresses JP 31
+ ++It is difficult to understand in which case nested_exception is applied. +
+ +[ +Summit: +]
+ + ++Alisdair will add an example in an update to +N2619. ++ + + +Proposed resolution:
+ + + + + +
+1009. Response to UK 251
+Section: 24.2.1 [iterator.iterators] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-22
+View all issues with Review status.
+Discussion:
+ +Addresses UK 251
+ ++The post-increment operator is dangerous for a general InputIterator. +The multi-pass guarantees that make it meaningful are defined as part of +the ForwardIterator refinement. Any change will affect only constrained +templates that have not yet been written, so should not break existing +user iterators which remain free to add these operations. This change +will also affect the generalised OutputIterator, although there is no +percieved need for the post-increment operator in this case either. +
+ + + +Proposed resolution:
++Change 24.2.1 [iterator.iterators]: +
+ ++ +concept Iterator<typename X> : Semiregular<X> { + MoveConstructible reference = typename X::reference; ++ +MoveConstructible postincrement_result;+ +requires HasDereference<postincrement_result>;+ + reference operator*(X&&); + X& operator++(X&); +postincrement_result operator++(X&, int);+} +...
++ +postincrement_result operator++(X& r, int);+++ +-3- Effects: equivalent to { X tmp = r; ++r; return tmp; }.++Change 24.2.2 [input.iterators]: +
+ +++ +concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> { + ObjectType value_type = typename X::value_type; + MoveConstructible pointer = typename X::pointer; + + SignedIntegralLike difference_type = typename X::difference_type; + + requires IntegralType<difference_type> + && Convertible<reference, const value_type &>; + && Convertible<pointer, const value_type*>; + ++requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;+ + pointer operator->(const X&); +} ++Change 24.2.3 [output.iterators]: +
+ +++ +auto concept OutputIterator<typename X, typename Value> { + requires Iterator<X>; + + typename reference = Iterator<X>::reference; ++typename postincrement_result = Iterator<X>::postincrement_result;+ requires SameType<reference, Iterator<X>::reference> +&& SameType<postincrement_result, Iterator<X>::postincrement_result>+&& Convertible<postincrement_result, const X&>+ && HasAssign<reference, Value> +&& HasAssign<HasDereference<postincrement_result>::result_type, Value>; +} ++Change 24.2.4 [forward.iterators]: +
+ +[ +See 1084 which is attempting to change this same area in a compatible +way. +]
+ + +++ + + + + + +concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { ++ +requires Convertible<postincrement_result, const X&>;+ + MoveConstructible postincrement_result; + requires HasDereference<postincrement_result> + && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; + + postincrement_result operator++(X&, int); + + axiom MultiPass(X a, X b) { + if (a == b) *a == *b; + if (a == b) ++a == ++b; + } +} +++ +-4- ...
+postincrement_result operator++(X& r, int); ++ +++ ++-5- Effects: equivalent to { X tmp = r; ++r; return tmp; }. +
+
+1010. Response to UK 263
+Section: 24.2.6 [random.access.iterators] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [random.access.iterators].
+View all other issues in [random.access.iterators].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 263
+ ++This requirement on operator-= would be better expressed as a default +implementation in the concept, with a matching axiom. +
+ +[ +Batavia (2009-05): +]
+ ++The proposed resolution should also remove +paragraph 5 and the declaration that precedes it. +Further, we should provide an axiom +that captures the desired semantics. +This may be a broader policy to be applied. +Move to Open. ++ + +Proposed resolution:
++Change 24.2.6 [random.access.iterators]: +
+ ++ + + + + + +concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> { + ... + X& operator-=(X& x, difference_type n) { return x += -n; } + ... +} +
+1011. Response to UK 271
+Section: 24.4 [iterator.operations] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [iterator.operations].
+View all other issues in [iterator.operations].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 271
+ ++next/prev return an incremented iterator without changing the value of +the original iterator. However, even this may invalidate an +InputIterator. A ForwardIterator is required to guarantee the +'multipass' property. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change [iterator.synopsis]: +
+ ++ +template <InputIteratorForwardIterator Iter> + Iter next(Iter x, + Iter::difference_type n = 1); ++Change 24.4 [iterator.operations], p6: +
+ ++ + + + + + +template <InputIteratorForwardIterator Iter> + Iter next(Iter x, + Iter::difference_type n = 1); +
+1012. Response to UK 277
+Section: 24.5.1.2.1 [reverse.iter.cons] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
+ +Addresses UK 277
+ ++The default constructor default-initializes current, rather than +value-initializes. This means that when Iterator corresponds to a +trivial type, the current member is left un-initialized, even when the +user explictly requests value intialization! At this point, it is not +safe to perform any operations on the reverse_iterator other than assign +it a new value or destroy it. Note that this does correspond to the +basic definition of a singular iterator. +
+ +[ +Summit: +]
+ + ++Agree with option i. ++ ++Related issue: 408 +
+ +[ +Batavia (2009-05): +]
+ ++We believe this should be revisited +in conjunction with issue 408, +which nearly duplicates this issue. +Move to Open. ++ + +Proposed resolution:
++Change [reverse.iter.con]: +
+ ++ +reverse_iterator(); +++-1- Effects:+DefaultValue initializes current. Iterator +operations applied to the resulting iterator have defined behavior if and +only if the corresponding operations are defined on a default constructed +iterator of type Iterator. ++Change 24.5.3.2.1 [move.iter.op.const]: +
+ ++ + + + + + +move_iterator(); +++-1- Effects: Constructs a move_iterator,+defaultvalue +initializing current. +
+1013. Response to UK 305
+Section: 25.5.7 [alg.min.max] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [alg.min.max].
+View all other issues in [alg.min.max].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 305
+ ++The negative requirement on IsSameType is a hold-over from an earlier +draught with a variadic template form of min/max algorith. It is no +longer necessary. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 25 [algorithms]: +
+ ++ +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ const T& min(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ const T& max(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp); ++Change 25.5.7 [alg.min.max], p1, p9 and p17: +
+ ++ + + + + + +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ const T& min(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ const T& max(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> +requires !SameType<T, Compare> && CopyConstructible<Compare>+ pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp); +
+1014. Response to UK 317 and JP 74
+Section: 28.9.2 [re.regex.construct] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all other issues in [re.regex.construct].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 317 and JP 74
+ ++UK 317: +
+ ++basic_string has both a constructor and an assignment operator that +accepts an initializer list, basic_regex should have the same. ++ ++JP 74: +
+ ++basic_regx & operator= (initializer_list<T>); is not defined. ++ +[ +Batavia (2009-05): +]
+ ++UK 317 asks for both assignment and constructor, +but the requested constructor is already present in the current Working Paper. +We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 28.9 [re.regex]: +
+ ++ +template <class charT, + class traits = regex_traits<charT> > +class basic_regex { + ... + basic_regex& operator=(const charT* ptr); + basic_regex& operator=(initializer_list<charT> il); + template <class ST, class SA> + basic_regex& operator=(const basic_string<charT, ST, SA>& p); + ... +}; ++Add in 28.9.2 [re.regex.construct]: +
+ +++ + + + + + ++-20- ... ++basic_regex& operator=(initializer_list<charT> il); +++-21- Effects: returns assign(il.begin(), il.end()); ++
+1015. Response to UK 199
+Section: 20.2.1 [concept.transform] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [concept.transform].
+View all other issues in [concept.transform].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 199
+ ++The requirement that programs do not supply concept_maps should +probably be users do not supply their own concept_map +specializations. The program will almost certainly supply +concept_maps - the standard itself supplies a specialization +for RvalueOf references. Note that the term program is +defined in 3.5 [basic.link]p1 and makes no account of the +standard library being treated differently to user written code. +
+ +[ +2009-05-09 Alisdair adds: +]
+ + +++ ++The same problem is present in the words added for the +LvalueReference/RvalueReference concepts last meeting. +
++With three subsections requiring the same constraint, I'm wondering if there +is a better way to organise this section. +Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in +14.10.4 [concept.support]? While they can be implemented purely as a +library feature without additional compiler support, they are pretty +fundamental and we want the same restriction on user-concept maps as is +mandated there. +
+[ +Batavia (2009-05): +]
+ ++We agree with the issue, +but believe the wording needs further improvement. +We want to investigate current definitions for nomenclature such as +"user" and "program." +Move to Open pending the recommended investigation. ++ + +Proposed resolution:
++Change 20.2.1 [concept.transform] p2: +
+ ++-2- A+ +programuser shall not provide concept maps for +any concept in 20.1.1. ++Change 20.2.2 [concept.true] p2: +
+ ++-2- Requires: a+ +programuser shall not +provide a concept map for the True concept. ++Change 20.2.3 [concept.classify] p2: +
+ ++-2- Requires: a+ + + + + + +programuser shall not provide concept +maps for any concept in this section. +
+1016. Response to JP 33
+Section: 20.2.6 [concept.comparison] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View other active issues in [concept.comparison].
+View all other issues in [concept.comparison].
+View all issues with Open status.
+Discussion:
+ +Addresses JP 33
+ ++LessThanComparable and EqualityComparable don't correspond to NaN. +
+ +Original proposed resolution:
+ ++Apply concept_map to these concepts at FloatingPointType. +
+ +[ +Post Summit, Alisdair adds: +]
+ + +++ + + ++I don't understand the proposed resolution - there is no such thing as a +'negative' concept_map, and these concepts are auto concepts that match +float/double etc. Also not clear how we are supposed to match values to +concepts. +
++Recommend NAD and treat as a subset of issue 902. +
+Proposed resolution:
++Recommend NAD. +
+ + + + + +
+1017. Response to US 66
+Section: 20.2.11 [concept.regular] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View all issues with Open status.
+Discussion:
+ +Addresses US 66
+ ++Application of the Regular concept to floating-point types appears to be +controversial (see long discussion on std-lib reflector). +
+ +Original proposed resolution:
+ ++State that the Regular concept does not apply to floating-point types. +
+ +[ +Summit: +]
+ + +++ ++Recommend that we handle the same as JP 33 / 1016. +
+[ +Post Summit, Alisdair adds: +]
+ + +++ + + ++Recommend Open, and review after resolution of 902 and revised axiom +feature. +
+Proposed resolution:
+ + + + + +
+1018. Response to US 70
+Section: 20.6 [meta] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View other active issues in [meta].
+View all other issues in [meta].
+View all issues with Open status.
+Discussion:
+ +Addresses US 70
+ ++Specifications now expressed via narrative text are more accurately and +clearly expressed via executable code. +
++Wherever concepts are available that directly match this section's type +traits, express the traits in terms of the concepts instead of via +narrative text. Where the type traits do not quite match the +corresponding concepts, bring the two into alignment so as to avoid two +nearly-identical notions. +
+ +[ +Summit: +]
+ + +++ + + ++We think that this is a good idea, but it requires a lot of work. If someone +submits a paper proposing specific changes, we would be happy to review it +at the next meeting. +
+Proposed resolution:
+ + + + + +
+1019. Response to UK 205
+Section: 20.6.3 [meta.help] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [meta.help].
+View all other issues in [meta.help].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 205
+ ++integral_constant objects should be usable in integral-constant-expressions. +The addition to the language of literal types and the enhanced rules for +constant expressions make this possible. +
+ +[ +Batavia (2009-05): +]
+ ++We agree that the static data member +ought be declared constexpr, +but do not see a need for the proposed operator value_type(). +(A use case would be helpful.) +Move to Open. ++ +[ +2009-05-23 Alisdair adds: +]
+ + +++ + ++The motivating case in my mind is that we can then use +true_type and false_type as integral Boolean expressions, for example inside +a static_assert declaration. In that sense it is purely a matter of style. +
++Note that Boost has applied the non-explicit conversion operator for many +years as it has valuable properties for extension into other metaprogramming +libraries, such as MPL. If additional rationale is desired I will poll the +Boost lists for why this extension was originally applied. I would argue +that explicit conversion is more appropriate for 0x though. +
+Proposed resolution:
++Add to the integral_constant struct definition in 20.6.3 [meta.help]: +
+ ++ + + + + +template <class T, T v> +struct integral_constant { + static constexpr T value = v; + typedef T value_type; + typedef integral_constant<T,v> type; + constexpr operator value_type() { return value; } +}; +
+1020. Response to UK 204
+Section: 20.6.7 [meta.trans.other] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View other active issues in [meta.trans.other].
+View all other issues in [meta.trans.other].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 204
+ ++It is not possible to create a variant union based on a parameter pack +expansion, e.g. to implement a classic discriminated union template. +
+ +Original proposed resolutuion:
+ ++Restore aligned_union template that was removed by LWG issue 856. +
+ +[ +Summit: +]
+ + ++Agree. The need for aligned_union is compelling enough to reinstate. ++ +[ +Post Summit, Alisdair adds: +]
+ + ++paper +N2843 +proposes an extension to the [[align]] attribute +that further diminishes the need for this template. Recommend NAD. ++ + + +Proposed resolution:
+ + + + + +
+1021. Response to UK 211
+Section: 20.8.12.2.3 [unique.ptr.single.asgn] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 211
+ ++The nullptr_t type was introduced to resolve the null pointer literal +problem. It should be used for the assignemnt operator, as with the +constructor and elsewhere through the library. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change the synopsis in 20.8.12.2 [unique.ptr.single]: +
+ ++ +unique_ptr& operator=(unspecified-pointer-typenullptr_t); ++Change 20.8.12.2.3 [unique.ptr.single.asgn]: +
+ ++ + + + + +unique_ptr& operator=(+unspecified-pointer-typenullptr_t); +++Assigns from the literal 0 or NULL. [Note: The +unspecified-pointer-type is often implemented as a pointer to a +private data member, avoiding many of the implicit conversion pitfalls. +-- end note]+
+1023. Response to DE 22
+Section: 20.7.16.2 [func.wrap.func] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [func.wrap.func].
+View all other issues in [func.wrap.func].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
+ +Addresses DE 22
+ +Related to issue 1114.
+ ++The conditions for deriving from std::unary_function and +std::binary_function are unclear: The condition would also be satisfied if +ArgTypes were std::vector<T1>, because it (arguably) +"contains" T1. +
+ +[ +Summit: +]
+ + ++Agree. std::reference_wrapper has the same structure, and we +suggest that std::function be presented in the same way as +std::reference_wrapper. ++ +[ +2009-05-09 Alisdair adds: +]
+ + ++Phrasing should be "publicly and +unambiguously derived from" and probably back in reference_wrapper too. Updated +wording supplied. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed wording. +Move to NAD Editorial. ++ + +Proposed resolution:
++(no changes to <functional> synopsis required) +
+ ++Change synopsis in Class template function 20.7.16.2 [func.wrap.func]: +
+ ++ +template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> + : public unary_function<T1, R> //iff sizeof...(ArgTypes) == 1 andsee below +// ArgTypes contains T1+ : public binary_function<T1, T2, R> //iff sizeof...(ArgTypes) == 2 andsee below +// ArgTypes contains T1 and T2+{ + ... ++Add new p1/p2 before 20.7.16.2.1 [func.wrap.func.con]: +
+ +++ + + + + + ++The template instantiation function<R(T1)> shall be publicly and +unambiguously derived from +std::unary_function<T1,R> if and only if the template type parameter +is a function type taking one argument of type T1 and returning R. +
+ ++The template instantiation function<R(T1,T2)> shall be publicly and +unambiguously derived from +std::binary_function<T1,T2,R> if and only if the template type +parameter is a function type taking two arguments of type T1 and T2 and +returning R. +
+ +explicit function(); ++
+1024. Response to JP 39
+Section: 20.7.16.2 [func.wrap.func] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-05-23
+View other active issues in [func.wrap.func].
+View all other issues in [func.wrap.func].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses JP 39
+ ++There are no requires corresponding to F of std::function. +
+ +[ +2009-05-01 Daniel adds: +]
+ + ++1070 removes the second constructor. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. +If issue 1070 is accepted, +the changes to the second constructor +in this issue are moot. ++ + +Proposed resolution:
++Correct as follows in 20.7.16.2 [func.wrap.func] (class definition) +
+ ++ + + + + + +template<class F, Allocator Alloc> + requires ConstructibleWithAllocator<F, Alloc> + && call=Callable<F, ArgTypes...> + && Convertible<call::result_type, R> + function(allocator_arg_t, const Alloc&, F); + template<class F, Allocator Alloc> + requires ConstructibleWithAllocator<F,Alloc> + && call=Callable<F, ArgTypes...> + && Convertible<call::result_type, R> + function(allocator_arg_t, const Alloc&, F&&); +
+1026. Response to UK 209
+Section: 20.8 [memory] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View other active issues in [memory].
+View all other issues in [memory].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 209
+ ++Smart pointers cannot be used in constrained templates. +
+ +[ +Summit: +]
+ + ++We look forward to a paper on this topic. We recommend no action until a +paper is available. We understand that a paper is forthcoming. ++ +[ +Peter Dimov adds: +]
+ + ++shared_ptr<T> and weak_ptr<T> support all +types T for which T* is valid. In other words, a +possible (partial) resolution is to change class T to +PointeeType T for shared_ptr, weak_ptr and +possibly enable_shared_from_this. ++ + + +Proposed resolution:
+ + + + + +
+1027. Response to UK 213
+Section: 20.8.6 [default.allocator] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-13
+View all issues with Open status.
+Discussion:
+ +Addresses UK 213
+ ++std::allocator should be constrained to simplify its use on constrained +contexts. This library component models allocation from free store via the +new operator so choose constraints to +match. The Allocator concept allows for a wider variety of allocators that +users may choose to supply if their allocation model does not require +operator new, without impacting the +requirements of this template. +
+ ++Suggested direction: +
++The primary allocator template should be constrained to require +ObjectType<T> and FreeStoreAllocatable<T>. +Further operations to be constrained as required. +
+ +[ +Summit: +]
+ + ++Agree as stated. A future paper will address additional related issues. ++ + + +Proposed resolution:
+ + + + + +
+1028. Response to UK 214
+Section: 20.8.8 [storage.iterator] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-15
+View all issues with Open status.
+Discussion:
+ +Addresses UK 214
+ ++raw_storage_iterator needs constraining as an iterator adaptor to be safely +used in constrained templates +
+ +[ +Summit: +]
+ + ++We look forward to a paper on this topic. We recommend no action until a +paper is available. ++ +[ +Post Summit Alisdair provided wording and rationale. +]
+ + + + +Proposed resolution:
++20.8 [memory] p2 +
++Update the synopsis for <memory> +
++ + +// 20.7.8, raw storage iterator: +template <classForwardIterator OutputIterator,classObjectType T> + requires OutputIterator< OutIter, T > + class raw_storage_iterator; + +template <ForwardIterator OutIter, ObjectType T> + requires OutputIterator< OutIter, T > + concept_map Iterator<raw_storage_iterator< OutIter, T > > { } ++20.8.8 [storage.iterator] p1 +
++Replace class template definition with: +
++ + +namespace std { + template <classForwardIterator OutputIterator,classObjectType T> + requires OutputIterator< OutIter, T > + class raw_storage_iterator + : public iterator<output_iterator_tag,void,void,void,void> { + public: + explicit raw_storage_iterator(OutputIteratorx); + + raw_storage_iterator<OutputIterator,T>& operator*(); + raw_storage_iterator<OutputIterator,T>& operator=(const T& element); + raw_storage_iterator<OutputIterator,T>& operator++(); + raw_storage_iterator<OutputIterator,T>operator++(int); + }; + + template <ForwardIterator OutIter, ObjectType T> + requires OutputIterator< OutIter, T > + concept_map Iterator<raw_storage_iterator< OutIter, T > > { } +} +Rationale:
++raw_storage_iterator has to adapt a ForwardIterator, +rather than just an InputIterator for two reasons: +
+ ++
+ + + + + + +- +The initial iterator passed by value is expected to remain valid, +pointing to the initialized region of memory. +
+- +to avoid breaking the declaration of post-increment operator which would +require some kind of proxy formulation to support generalised InputIterators. +
+
+1029. Response to UK 210
+Section: 20.8.11 [specialized.algorithms] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-15
+View all other issues in [specialized.algorithms].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 210
+ +Related to 582
+ ++Specialized algorithms for memory managenment need requirements to be +easily usable in constrained templates. +
+ +[ +Summit: +]
+ + ++We look forward to a paper on this topic. We recommend no action until a +paper is available. ++ +[ +Post Summit Alisdair provided wording. +]
+ + +[ +Post Summit: +]
+ + +++ + + ++Daniel adds: +
+ +++ ++
+- +I suggest Size should require IntegralLike and not UnsignedIntegralLike, +because otherwise simple int-literals could not be provided as arguments +and it would conflict with other algorithms that only require IntegralLike. +
+- +
++The current for-loop-test relies on evaluation in boolean context which is +not provided by ArithmeticLike and it's refinements. I propose to change the +corresponding for-loop-headers to: +
++
+- +for uninitialized_copy_n: for ( ; n > Size(0); ++result, ++first, --n) { +
+- +for uninitialized_fill_n: for (; n > Size(0); ++first, --n) { +
++Alisdair adds: +
++For the record I agree with Daniel's suggestion. ++ +Proposed resolution:
++20.8 [memory] p2 +
++Update the synopsis for <memory> +
++ +template <classInputIterator InIter, +class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter> + requires ForwardIterator<OutIter> +ForwardIteratorOutIter + uninitialized_copy(InputIteratorInIter first,InputIteratorInIter last, +ForwardIteratorOutIter result); + +template <classInputIterator InIter, +classIntegralLike Size, +class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter> + requires ForwardIterator<OutIter> +ForwardIteratorOutIter + uninitialized_copy_n(InputIteratorInIter first, Size n, +ForwardIteratorOutIter result); + +template <classForwardIterator Iter,classObjectType T> + requires Constructible< Iter::value_type, const T& > + void uninitialized_fill(ForwardIteratorIter first,ForwardIteratorIter last, + const T& x); + +template <classForwardIterator Iter,classIntegralLike Size,classObjectType T> + requires Constructible< Iter::value_type, const T& > + void + uninitialized_fill_n(ForwardIteratorIter first, Size n, const T& x); ++Update as follows: +
+ ++uninitialized_copy 20.8.11.2 [uninitialized.copy] +
+ ++ + +template <+ +classInputIterator InIter, +class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter> + requires ForwardIterator<OutIter> +ForwardIteratorOutIter + uninitialized_copy(InputIteratorInIter first,InputIteratorInIter last, +ForwardIteratorOutIter result); +++ ++-1- Effects: +
++ +for (; first != last; ++result, ++first) { + new (static_cast<void*>(&*result)) +typename iterator_traits<ForwardIterator>OutIter::value_type(*first); +} ++-2- Returns: result +
+ +template <+ +classInputIterator InIter, +classIntegralLike Size, +class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter> + requires ForwardIterator<OutIter> +ForwardIteratorOutIter + uninitialized_copy_n(InputIteratorInIter first, Size n, +ForwardIteratorOutIter result); +++ ++-3- Effects: +
++for ( ; n > Size(0); ++result, ++first, --n) { + new (static_cast<void*>(&*result)) +typename iterator_traits<ForwardIterator>OutIter::value_type(*first); +} ++-4- Returns: result +
++uninitialized_fill 20.8.11.3 [uninitialized.fill] +
+ ++ + +template <+ +classForwardIterator Iter,classObjectType T> + requires Constructible< Iter::value_type, const T& > + void uninitialized_fill(ForwardIteratorIter first,ForwardIteratorIter last, + const T& x); ++++-1- Effects: +
++for (; first != last; ++first) { + new ( static_cast<void*>( &*first) ) +typename iterator_traits<ForwardIterator>Iter::value_type(x); +} ++uninitialized_fill_n 20.8.11.4 [uninitialized.fill.n] +
+ ++ + + + + + +template <+ +classForwardIterator Iter,classIntegralLike Size,classObjectType T> + requires Constructible< Iter::value_type, const T& > + void + uninitialized_fill_n(ForwardIteratorIter first, Size n, const T& x); ++++-1- Effects: +
++for (; n--> Size(0); ++first, --n) { + new ( static_cast<void*>( &*first) ) +typename iterator_traits<ForwardIterator>Iter::value_type(x); +} +
+1030. Response to JP 44
+Section: 20.8.13.6 [util.smartptr.shared.atomic] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View all issues with Open status.
+Discussion:
+ +Addresses JP 44
+ ++The 1st parameter p and 2nd parameter v is now +shared_ptr<T>*. +
++It should be shared_ptr<T>&, or if these are +shared_ptr<T>* then add the "p shall not be a +null pointer" at the requires. +
+ +[ +Summit: +]
+ + ++Agree. All of the functions need a requirement that p (or +v) is a pointer to a valid object. ++ + + +Proposed resolution:
+ + + + + +
+1031. Response to US 78
+Section: 20.8.13.2 [util.smartptr.shared] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View other active issues in [util.smartptr.shared].
+View all other issues in [util.smartptr.shared].
+View all issues with Open status.
+Discussion:
+ +Addresses US 78
+ ++There is presently no way to convert directly from a shared_ptr to a +unique_ptr. Add an interface that performs the conversion. +
+ +[ +Summit: +]
+ + ++We look forward to a paper on this topic. We recommend no action until a +paper is available. We believe that the shared pointer must use the default +deleter for the conversion to succeed. ++ +[ +Peter Dimov adds: +]
+ + ++This is basically a request for shared_ptr<>::release in +disguise, with all the associated problems. Not a good idea. ++ + + +Proposed resolution:
+ + + + + +
+1032. Response to JP 45
+Section: 20.9 [time] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-11 Last modified: 2009-03-12
+View all other issues in [time].
+View all issues with Open status.
+Discussion:
+ +Addresses JP 45
+ ++Rep, Period, Clock and Duration +don't correspond to concept. +
++template <class Rep, class Period = ratio<1>> class duration; +template <class Clock, class Duration = typename Clock::duration> class time_point; ++Make concept for Rep, Period, Clock and Duration. +Fix 20.9 [time] and wait_until +and wait_for's template parameter at 30 [thread]. +
+ +[ +Summit: +]
+ + ++We agree that this section needs concepts. We look forward to a paper on +this topic. We recommend no action until a paper is available. ++ + + +Proposed resolution:
+ + + + + +
+1033. thread::join() effects?
+Section: 30.3.1.5 [thread.thread.member] Status: Open + Submitter: Alberto Ganesh Barbati Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [thread.thread.member].
+View all other issues in [thread.thread.member].
+View all issues with Open status.
+Discussion:
+ ++While looking at thread::join() I think I spotted a couple of +possible defects in the specifications. I could not find a previous +issue or NB comment about that, but I might have missed it. +
+ ++The postconditions clause for thread::join() is: +
+ ++Postconditions: If join() throws an exception, the value +returned by get_id() is unchanged. Otherwise, get_id() == id(). ++ ++and the throws clause is: +
+ ++Throws: std::system_error when the postconditions cannot be achieved. ++ ++Now... how could the postconditions not be achieved? +It's just a matter of resetting the value of get_id() or leave it +unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg +problem: in order to decide whether to throw or not I depend on the +postconditions, but the postconditions are different in the two cases. +
+ ++I believe the throws clause should be: +
+ ++Throws: std::system_error when the effects or postconditions +cannot be achieved. ++ ++as it is in detach(), or, even better, as the postcondition is +trivially satisfiable and to remove the circular dependency: +
+ + ++Throws: std::system_error if the effects cannot be achieved. ++ ++Problem is that... ehm... join() has no "Effects" clause. Is that intentional? +
+ +[ +See the thread starting at c++std-lib-23204 for more discussion. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++Pete believes there may be some more general language (in frontmatter) +that can address this and related issues such as 962. +
++Move to Open. +
+Proposed resolution:
+ + + + + +
+1034. Response to UK 222
+Section: 23.2.1 [container.requirements.general] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-12
+View other active issues in [container.requirements.general].
+View all other issues in [container.requirements.general].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 222
+ ++It is not clear what purpose the Requirement tables serve in the +Containers clause. Are they the definition of a library Container? Or +simply a conventient shorthand to factor common semantics into a single +place, simplifying the description of each subsequent container? This +becomes an issue for 'containers' like array, which does not meet the +default-construct-to-empty requirement, or forward_list which does not +support the size operation. Are these components no longer containers? +Does that mean the remaining requirements don't apply? Or are these +contradictions that need fixing, despite being a clear design decision? +
+ ++Recommend: +
+ ++Clarify all the tables in 23.2 [container.requirements] are +there as a convenience for documentation, rather than a strict set of +requirements. Containers should be allowed to relax specific +requirements if they call attention to them in their documentation. The +introductory text for array should be expanded to mention a +default constructed array is not empty, and +forward_list introduction should mention it does not provide +the required size operation as it cannot be implemented +efficiently. +
+ +[ +Summit: +]
+ + ++Agree in principle. ++ + + +Proposed resolution:
+ + + + + +
+1035. Response to UK 226
+Section: 23.2.1 [container.requirements.general] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-02
+View other active issues in [container.requirements.general].
+View all other issues in [container.requirements.general].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 226
+ ++<array> must be added to this list. In particular it +doesn't satisfy: - no swap() function invalidates any +references, pointers, or iterators referring to the elements of the +containers being swapped. and probably doesn't satisfy: - no +swap() function throws an exception. +
++If <array> remains a container, this will have to also +reference array, which will then have to say which of these +points it satisfies. +
+ +[ +Summit: +]
+ + ++Agree. The proposed resolution is incomplete. Further work required. ++ +[ +2009-05-01 Daniel adds: +]
+ + ++Issue 1099 also suggests +adding move constructor to this. ++ + + +Proposed resolution:
+ + + + + +
+1036. Response to UK 231
+Section: 23.2.3 [sequence.reqmts] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-12
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 231
+ ++p9-p11 are redundant now that Concepts define what it means to be an +Iterator and guide overload resolution accordingly. +
+ +[ +Summit: +]
+ + ++Agree with issue and change to 23.2.3 [sequence.reqmts]. The +changes required to 21 [strings] will be part of the general +concept support for that clause. ++ + + +Proposed resolution:
++Strike 23.2.3 [sequence.reqmts]p9-11. Make sure std::basic_string +has constraints similar to +std::vector to meet this old guarantee. +
+ + + + + +
+1037. Response to UK 232
+Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 232
+ ++match_results may follow the requirements but is not listed a general +purpose library container. +
+ ++Remove reference to match_results against a[n] operation. +
+ +[ +Summit: +]
+ + ++Agree. operator[] is defined elsewhere. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++In 23.2.3 [sequence.reqmts] Table 84, remove reference to +match_results in the row describing the a[n] operation. +
+ + + + + +
+1038. Response to UK 233
+Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 233
+ ++Table 84 is missing references to several new container types. +
+ +[ +Summit: +]
+ + ++Agree. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed +containers to the following rows: +
+ +++ + + + + ++
+Table 84 -- Optional sequence container operations ++ +Expression +Return type +Operational semantics +Container ++ +a.front() +... +... +vector, list, deque, basic_string, array, forward_list ++ +a.back() +... +... +vector, list, deque, basic_string, array ++ +a.emplace_front(args) +... +... +list, deque, forward_list ++ +a.push_front(t) +... +... +list, deque, forward_list ++ +a.push_front(rv) +... +... +list, deque, forward_list ++ +a.pop_front() +... +... +list, deque, forward_list ++ +a[n] +... +... +vector, deque, basic_string, array ++ +a.at(n) +... +... +vector, deque, basic_string, array +
+1039. Response to UK 234
+Section: 23.2.3 [sequence.reqmts] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 234
+ ++The reference to iterator in semantics for back should +also allow for const_iterator when called on a const-qualified +container. This would be ugly to specify in the 03 standard, but is +quite easy with the addition of auto in this new standard. +
+ +[ +Summit: +]
+ + ++Agree. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back: +
+ +++ + + + + ++
+Table 84 -- Optional sequence container operations ++ +Expression +Return type +Operational semantics +Container ++ +a.back() +reference; const_reference for constant a +{ +iteratorauto tmp = a.end();
--tmp;
return *tmp; }vector, list, deque, basic_string +
+1040. Response to UK 238
+Section: 23.2.4 [associative.reqmts] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [associative.reqmts].
+View all other issues in [associative.reqmts].
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 238
+ ++Leaving it unspecified whether or not iterator and const_iterator are the +same type is dangerous, as user code may or may not violate the One +Definition Rule by providing overloads for +both types. It is probably too late to specify a single behaviour, but +implementors should document what to expect. Observing that problems can be +avoided by users restricting themselves to using const_iterator, add a note to that effect. +
++Suggest Change 'unspecified' to 'implementation defined'. +
+ +[ +Summit: +]
+ + ++Agree with issue. Agree with adding the note but not with changing the +normative text. We believe the note provides sufficient guidance. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++In 23.2.4 [associative.reqmts] p6, add: +
+ ++-6- iterator of an associative container meets the requirements +of the BidirectionalIterator concept. For associative +containers where the value type is the same as the key type, both +iterator and const_iterator are constant iterators. It +is unspecified whether or not iterator and +const_iterator are the same type. +[Note: iterator and const_iterator have identical semantics in +this case, and iterator is convertible to const_iterator. Users can avoid +violating the One Definition Rule by always using const_iterator +in their function parameter lists -- end note] ++ + + + + +
+1041. Response to UK 239
+Section: 23.2.4 [associative.reqmts] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-15
+View other active issues in [associative.reqmts].
+View all other issues in [associative.reqmts].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 239
+ ++It is not possible to take a move-only key out of an unordered +container, such as (multi)set or +(multi)map, or the new unordered containers. +
+ ++Add below a.erase(q), a.extract(q), with the following notation: +
++a.extract(q)>, Return type pair<key, iterator> +Extracts the element pointed to by q and erases it from the +set. Returns a pair containing the value pointed to by +q and an iterator pointing to the element immediately +following q prior to the element being erased. If no such +element exists,returns a.end(). +
+ +[ +Summit: +]
+ + ++We look forward to a paper on this topic. We recommend no action until a +paper is available. The paper would need to address exception safety. ++ +[ +Post Summit Alisdair adds: +]
+ + ++Would value_type be a better return type than key_type? ++ + + +Proposed resolution:
++In 23.2.4 [associative.reqmts] Table 85, add: +
+ +++ ++
+Table 85 -- Associative container requirements (in addition to container) ++ +Expression +Return type +Assertion/note +
pre-/post-conditionComplexity +a.erase(q) +... +... +... ++ +a.extract(q) +pair<key_type, iterator> +Extracts the element pointed to by q and erases it from the set. +Returns a pair containing the value pointed to by q and an iterator +pointing to the element immediately following q prior to the element being +erased. If no such element +exists, returns a.end(). +amortized constant ++In 23.2.5 [unord.req] Table 87, add: +
+ +++ + + + + ++
+Table 87 -- Unordered associative container requirements (in addition to container) ++ +Expression +Return type +Assertion/note +
pre-/post-conditionComplexity +a.erase(q) +... +... +... ++ +a.extract(q) +pair<key_type, iterator> +Extracts the element pointed to by q and erases it from the set. +Returns a pair containing the value pointed to by q and an iterator +pointing to the element immediately following q prior to the element being +erased. If no such element +exists, returns a.end(). +amortized constant +
+1042. Response to UK 244
+Section: 23.3 [sequences] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-14
+View all other issues in [sequences].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 244
+ ++The validity of the expression &a[n] == &a[0] + n is contingent on +operator& doing the "right thing" (as captured by the CopyConstructible +requirements in table 30 in C++2003). However this constraint has been +lost in the Concepts of C++0x. This applies to vector and array (it +actually applies to string also, but that's a different chapter, so I'll +file a separate comment there and cross-reference). +
+ ++Suggested solution: +
+ ++Define a ContiguousStrorage and apply it to +vector, array and string. +
+ +[ +Summit: +]
+ + ++Agree with the issue but not the details of the proposed solution. Walter to +provide wording for the new concept. ++ +[ +Post Summit Alisdair adds: +]
+ + ++Another LWG subgroup wondered if this concept +should extend to complex<T>, and so not be built on the container concept at +all? ++ + + +Proposed resolution:
++Add to <container_concepts> synopsis in 23.2.6 [container.concepts] +
+ ++ +concept< typename C > ContiguousStorageContainer see below; ++Add a new section to the end of 23.2.6 [container.concepts] +
+ +++ ++23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous] +
+ +concept ContiguousStorageContainer< typename C > + : Container<C> +{ + value_type* data(C&); + + axiom Contiguity(C& c, size_type i) { + if( i < size(c) ) { + addressof( * (data(c) + i) ) + == addressof( * advance(data(c), i) ); + } + } +} ++ ++The ContiguousStorageContainer concept describes a container whose elements +are allocated in a single region of memory, and are stored sequentially +without intervening padding other than to meet alignment requirements. +For example, the elements may be stored in a +single array of suitable length. +
+ +value_type * data( C& ); ++ ++Returns: a pointer to the first element in the region of storage. +Result is unspecified for an empty container. ++ ++Change 23.3.1 [array] p1: +
+ ++-1- The header <array> defines a class template for +storing fixed-size sequences of objects. An array supports +random access iterators. An instance of array<T, N> +stores N elements of type T, so that size() == +N is an invariant. The elements of an array are stored +contiguously, meaning that+ +if a isan +array<T, N>then it obeys the identity &a[n] +== &a[0] + n for all 0 <= n < N+satisfies the concept ContiguousStorageContainer< array<T, +N>>. ++Add to the synopsis in 23.3.1 [array]: +
+ ++ +... + T * data(); + const T * data() const; + }; + + template< typename T, size_t N > + concept_map ContiguousStorageContainer< array<T, N>> {}; +} ++Change 23.3.6 [vector] p1: +
+ ++A vector is a sequence container that supports random access +iterators. In addition, it supports (amortized) constant time insert and +erase operations at the end; insert and erase in the middle take linear +time. Storage management is handled automatically, though hints can be +given to improve efficiency. The elements of a vector are stored +contiguously, meaning that+ +if v isa +vector<T, Alloc> (where T is some +type other than bool), then it obeys the +identity &v[n] == &v[0] + n for all 0 <= n < +v.size()satisfies the concept ContiguousStorageContainer< +vector< T, Alloc>>. ++Add at the end of the synopsis in 23.3.6 [vector] p2: +
+ ++ + + + + + +template< typename T, typename A > + requires !SameType< T, bool > + concept_map ContiguousStorageContainer< vector<T, A>> {}; +
+1043. Response to US 91
+Section: 29.6 [atomics.types.operations] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View all other issues in [atomics.types.operations].
+View all issues with Review status.
+Discussion:
+ +Addresses US 91
+ ++It is unclear whether or not a failed compare_exchange is a RMW operation +(as used in 1.10 [intro.multithread]). +
+ ++Suggested solution: +
+ ++Make failing compare_exchange operations not be RMW. +
+ +[ +Anthony Williams adds: +]
+ + ++In 29.6 [atomics.types.operations] p18 it says that "These +operations are atomic read-modify-write operations" (final sentence). +This is overly restrictive on the implementations of +compare_exchange_weak and compare_exchange_strong on platforms without a +native CAS instruction. ++ + +[ +Summit: +]
+ + ++Group agrees with the resolution as proposed by Anthony Williams in the attached note. ++ +[ +Batavia (2009-05): +]
+ ++We recommend the proposed resolution be reviewed +by members of the Concurrency Subgroup. ++ + +Proposed resolution:
++Change 29.6 [atomics.types.operations] p18: +
+ ++-18- Effects: Atomically, compares the value pointed to by +object or by this for equality with that in +expected, and if true, replaces the value pointed to by +object or by this with desired, and if false, updates +the value in expected with the value pointed to by +object or by this. Further, if the comparison is true, +memory is affected according to the value of success, and if the +comparison is false, memory is affected according to the value of +failure. 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_acquire and a value of +memory_order_release shall be replaced by the value +memory_order_relaxed. If the comparison is true, ++ + + + + + +Tthese operations are atomic +read-modify-write operations (1.10). +If the comparison is false, these +operations are atomic load operations. +
+1044. Response to UK 325
+Section: 30.4 [thread.mutex] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 325
+ ++We believe constexpr literal values should be a more natural expression +of empty tag types than extern objects as it should improve the +compiler's ability to optimize the empty object away completely. +
+ +[ +Summit: +]
+ + ++Move to review. The current specification is a "hack", and the proposed +specification is a better "hack". ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change the synopsis in 30.4 [thread.mutex]: +
+ ++ + + + + + +struct defer_lock_t {}; +struct try_to_lock_t {}; +struct adopt_lock_t {}; + +externconstexpr defer_lock_t defer_lock {}; +externconstexpr try_to_lock_t try_to_lock {}; +externconstexpr adopt_lock_t adopt_lock {}; +
+1045. Response to UK 326
+Section: 30.4.3.2.1 [thread.lock.unique.cons] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ +Addresses UK 326
+ ++The precondition that the mutex is not owned by this thread offers +introduces the risk of un-necessary undefined behaviour into the +program. The only time it matters whether the current thread owns the +mutex is in the lock operation, and that will happen subsequent to +construction in this case. The lock operation has the identical +pre-condition, so there is nothing gained by asserting that precondition +earlier and denying the program the right to get into a valid state +before calling lock. +
+ +[ +Summit: +]
+ + ++Agree, move to review. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Strike 30.4.3.2.1 [thread.lock.unique.cons] p7: +
+ ++ + + + + + +unique_lock(mutex_type& m, defer_lock_t); ++++-7- Precondition: If mutex_type is not a recursive mutex +the calling thread does not own the mutex.+
+1046. Response to UK 329
+Section: 30.6 [futures] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-13
+View all issues with Open status.
+Discussion:
+ +Addresses UK 329
+ ++future, promise and packaged_task provide a +framework for creating future values, but a simple function to tie all +three components together is missing. Note that we only need a *simple* +facility for C++0x. Advanced thread pools are to be left for TR2. +
+ ++Simple Proposal: +
+ ++Provide a simple function along the lines of: +
++ +template< typename F, typename ... Args > + requires Callable< F, Args... > + future< Callable::result_type > async( F&& f, Args && ... ); ++Semantics are similar to creating a thread object with a packaged_task +invoking f with forward<Args>(args...) +but details are left unspecified to allow different scheduling and thread +spawning implementations. +
++It is unspecified whether a task submitted to async is run on its own thread +or a thread previously used for another async task. If a call to async +succeeds, it shall be safe to wait for it from any thread. +
++The state of thread_local variables shall be preserved during async calls. +
++No two incomplete async tasks shall see the same value of +this_thread::get_id(). +
++[Note: this effectively forces new tasks to be run on a new thread, or a +fixed-size pool with no queue. If the +library is unable to spawn a new thread or there are no free worker threads +then the async call should fail. --end note] +
+ +[ +Summit: +]
+ + +++ + + ++The concurrency subgroup has revisited this issue and decided that it +could be considered a defect according to the Kona compromise. A task +group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a +paper for Frankfort proposing a simple asynchronous launch facility +returning a future. It was agreed that the callable must be run on a +separate thread from the caller, but not necessarily a brand-new thread. +The proposal might or might not allow for an implementation that uses +fixed-size or unlimited thread pools. +
++Bjarne in c++std-lib-23121: I think that what we agreed was that to +avoid deadlock async() would almost certainly be specified to launch in +a different thread from the thread that executed async(), but I don't +think it was a specific design constraint. +
+Proposed resolution:
+ + + + + +
+1047. Response to UK 334
+Section: 30.6.4 [futures.unique_future] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [futures.unique_future].
+View all other issues in [futures.unique_future].
+View all issues with Review status.
+Discussion:
+ +Addresses UK 334
+ ++Behaviour of get() is undefined if calling get() while +not is_ready(). The intent is that get() is a blocking +call, and will wait for the future to become ready. +
+ +[ +Summit: +]
+ + +++ ++Agree, move to Review. +
+[ +2009-04-03 Thomas J. Gritzan adds: +]
+ + +++ ++This issue also applies to shared_future::get(). +
+ ++Suggested wording: +
+ ++Add a paragraph to [futures.shared_future]: +
+ ++void shared_future<void>::get() const; +++Effects: If is_ready() would return false, block on the asynchronous +result associated with *this. ++[ +Batavia (2009-05): +]
+ ++It is not clear to us that this is an issue, +because the proposed resolution's Effects clause seems to duplicate +information already present in the Synchronization clause. +Keep in Review status. ++ + +Proposed resolution:
++Add a paragraph to 30.6.4 [futures.unique_future]: +
+ ++ + + + + +R&& unique_future::get(); +R& unique_future<R&>::get(); +void unique_future<void>::get(); ++++Note:...
++Effects: If is_ready() would return false, +block on the asynchronous result associated with *this. +
++Synchronization: if *this is associated with a +promise object, the completion of set_value() or +set_exception() to that promise happens before (1.10) +get() returns. +
+
+1048. Response to UK 335
+Section: 30.6.4 [futures.unique_future] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-13
+View other active issues in [futures.unique_future].
+View all other issues in [futures.unique_future].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 335
+ ++std::unique_future is MoveConstructible, so you can transfer the +association with an asynchronous result from one instance to another. +However, there is no way to determine whether or not an instance has +been moved from, and therefore whether or not it is safe to wait for it. +
+ ++ +std::promise<int> p; +std::unique_future<int> uf(p.get_future()); +std::unique_future<int> uf2(std::move(uf)); +uf.wait(); // oops, uf has no result to wait for. ++Suggest we add a waitable() function to unique_future +(and shared_future) akin to std::thread::joinable(), +which returns true if there is an associated result to wait for +(whether or not it is ready). +
+ ++Then we can say: +
+ ++ +if(uf.waitable()) uf.wait(); +[ +Summit: +]
+ + +++ ++Create an issue. Requires input from Howard. Probably NAD. +
+[ +Post Summit, Howard thows in his two cents: +]
+ + +++ + + ++Here is a copy/paste of my last prototype of unique_future which was +several years ago. At that time I was calling unique_future future: +
+ ++ +template <class R> +class future +{ +public: + typedef R result_type; +private: + future(const future&);// = delete; + future& operator=(const future&);// = delete; + + template <class R1, class F1> friend class prommise; +public: + future(); + ~future(); + + future(future&& f); + future& operator=(future&& f); + + void swap(future&& f); + + bool joinable() const; + bool is_normal() const; + bool is_exceptional() const; + bool is_ready() const; + + R get(); + + void join(); + template <class ElapsedTime> + bool timed_join(const ElapsedTime&); +}; ++shared_future had a similar interface. I intentionally reused +the thread interface where possible to lessen the learning +curve std::lib clients will be faced with. +
+Proposed resolution:
+ + + + + +
+1049. Response to UK 339
+Section: 30.6.6 [futures.promise] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [futures.promise].
+View all other issues in [futures.promise].
+View all issues with Review status.
+Discussion:
+ +Addresses UK 339
+ ++Move assignment is goiing in the wrong direction, assigning from +*this to the passed rvalue, and then returning a reference to +an unusable *this. +
+ +[ +Summit: +]
+ + +++ ++Agree, move to Review. +
+[ +Batavia (2009-05): +]
+ ++We recommend deferring this issue until after Detlef's paper (on futures) +has been issued. ++ + +Proposed resolution:
++Strike 30.6.6 [futures.promise] p6 and change p7: +
+ ++ + + + + + +promise& operator=(promise&& rhs); +++++
+-6- Effects: move assigns its associated state to rhs.++-7- Postcondition:
+*this has no associated +state.associated state of *this is the same as the +associated state of rhs before the call. rhs has no +associated state. +
+1050. Response to UK 340
+Section: 30.6.6 [futures.promise] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [futures.promise].
+View all other issues in [futures.promise].
+View all issues with Review status.
+Discussion:
+ +Addresses UK 340
+ ++There is an implied postcondition for get_future() that the state of the +promise is transferred into the future leaving the promise with no +associated state. It should be spelled out. +
+ +[ +Summit: +]
+ + +++ ++Agree, move to Review. +
+[ +2009-04-03 Thomas J. Gritzan adds: +]
+ + +++ ++promise::get_future() must not invalidate the state of the promise object. +
++A promise is used like this: +
++promise<int> p; +unique_future<int> f = p.get_future(); +// post 'p' to a thread that calculates a value +// use 'f' to retrieve the value. ++So get_future() must return an object that shares the same associated +state with *this. +
++But still, this function should throw an future_already_retrieved error +when it is called twice. +
++packaged_task::get_future() throws std::bad_function_call if its future +was already retrieved. It should throw +future_error(future_already_retrieved), too. +
++Suggested resolution: +
++Replace p12/p13 30.6.6 [futures.promise]: +
++++-12- Throws: future_error if
+*this has no associated state+the future has already been retrieved. ++-13- Error conditions: future_already_retrieved if
+*this +has no associated state+the future associated with +the associated state has already been retrieved. ++Postcondition: The returned object and *this share the associated state. +
++Replace p14 30.6.8 [futures.task]: +
++++-14- Throws:
+ +std::bad_function_callfuture_error if the futureassociated with +the taskhas already been retrieved. ++Error conditions: future_already_retrieved if the future associated with +the task has already been retrieved. +
++Postcondition: The returned object and *this share the associated task. +
+[ +Batavia (2009-05): +]
+ ++Keep in Review status +pending Detlef's forthcoming paper on futures. ++ + +Proposed resolution:
++Add after p13 30.6.6 [futures.promise]: +
+ ++ + + + + + +unique_future<R> get_future(); +++++-13- ... +
++Postcondition: *this has no associated state. +
+
+1051. Response to UK 279
+Section: 24.5.1.2.12 [reverse.iter.opindex], 24.5.3.2.12 [move.iter.op.index] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-21
+View all issues with Open status.
+Discussion:
+ +Addresses UK 279
+ ++The reason the return type became unspecified is LWG issue 386. This +reasoning no longer applies as there are at least two ways to get the right +return type with the new language facilities added since the previous +standard. +
+ ++Proposal: Specify the return type using either decltype or the Iter concept_map. +
+ +[ +Summit: +]
+ + +++ ++Under discussion. This is a general question about all iterator +adapters. +
+[ +Howard adds post Summit: +]
+ + ++I am requesting test cases to demonstrate a position. ++ + + +Proposed resolution:
+ + + + + +
+1052. Response to UK 281
+Section: 24.5.1.2.5 [reverse.iter.opref] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-13
+View all issues with Open status.
+Discussion:
+ +Addresses UK 281
+ ++The current specification for return value for reverse_iterator::operator-> +will always be a true pointer type, but reverse_iterator supports proxy +iterators where the pointer type may be some kind of 'smart pointer'. +
+ +[ +Summit: +]
+ + +++ + + ++move_iterator avoids this problem by returning a value of the wrapped +Iterator type. +study group formed to come up with a suggested resolution. +
++move_iterator solution shown in proposed wording. +
+Proposed resolution:
++Change synopsis in 24.5.1.1 [reverse.iterator]: +
+ ++ +template <BidirectionalIterator Iter> +class reverse_iterator { + ... + typedef Iter::pointerpointer; ++Change 24.5.1.2.5 [reverse.iter.opref]: +
+ ++ + + + + + +pointer operator->() const; +++Returns: +++&(operator*());+this->tmp = current; +--this->tmp; +return this->tmp; +
+1053. Response to UK 295
+Section: 25 [algorithms] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-03-13
+View all other issues in [algorithms].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 295
+ ++There is a level of redundancy in the library specification for many +algorithms that can be eliminated with the combination of concepts and +default parameters for function templates. Eliminating redundancy simplified +specification and reduces the risk of introducing accidental +inconsistencies. +
++Proposed resolution: Adopt +N2743. +
+ +[ +Summit: +]
+ + +++ ++NAD, this change would break code that takes the address of an +algorithm. +
+[ +Post Summit Alisdair adds: +]
+ + +++ + + ++Request 'Open'. The issues in the paper go beyond just reducing +the number of signatures, but cover unifying the idea of the ordering +operation used by algorithms, containers and other library components. At +least, it takes a first pass at the problem. +
+ ++For me (personally) that was the more important part of the paper, and not +clearly addressed by the Summit resolution. +
+Proposed resolution:
+ + + + + +
+1054. forward broken
+Section: 20.3.2 [forward] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-13 Last modified: 2009-05-23
+View all other issues in [forward].
+View all issues with Open status.
+Discussion:
+ ++This is a placeholder issue to track the fact that we (well I) put the standard +into an inconsistent state by requesting that we accept +N2844 +except for the proposed changes to [forward]. +
+ ++There will exist in the post meeting mailing +N2835 +which in its current state reflects the state of affairs prior to the Summit +meeting. I hope to update it in time for the post Summit mailing, but as I write +this issue I have not done so yet. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, awaiting the promised paper. ++ + + +Proposed resolution:
+ + + + + +
+1055. Response to UK 98
+Section: 20.6.7 [meta.trans.other] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [meta.trans.other].
+View all other issues in [meta.trans.other].
+View all issues with Open status.
+Discussion:
+ +Addresses UK 98
+ ++It would be useful to be able to determine the underlying +type of an arbitrary enumeration type. This would allow +safe casting to an integral type (especially needed for +scoped enums, which do not promote), and would allow +use of numeric_limits. In general it makes generic +programming with enumerations easier. +
+ +[ +Batavia (2009-05): +]
+ ++Pete observes (and Tom concurs) +that the proposed resolution seems to require compiler support +for its implementation, +as it seems necessary to look at the range of values +of the enumerated type. +To a first approximation, +a library solution could give an answer based on the size of the type. +If the user has specialized numeric_limits for the enumerated type, +then the library might be able to do better, +but there is no such requirement. +Keep status as Open +and solicit input from CWG. ++ +[ +2009-05-23 Alisdair adds: +]
+ + ++Just to confirm that the BSI originator of this comment assumed it did +indeed imply a compiler intrinsic. Rather than request a Core extension, it +seemed in keeping with that the type traits interface provides a library API +to unspecified compiler features - where we require several other traits +(e.g. has_trivial_*) to get the 'right' answer now, unlike in TR1. ++ + +Proposed resolution:
++Add a new row to the table in 20.6.7 [meta.trans.other]: +
+ +++ + + + + ++
+Table 41 -- Other transformations ++ +Template +Condition +Comments ++ ++template< class T > struct enum_base; + ++T shall be an enumeration type (7.2 [dcl.enum]) + ++The member typedef type shall name the underlying type +of the enum T. + +
+1056. Must all Engines and Distributions be Streamable?
+Section: 26.5 [rand] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-31
+View other active issues in [rand].
+View all other issues in [rand].
+View all issues with Open status.
+Discussion:
+ ++Both the concepts RandomNumberEngine and RandomNumberDistribution have +requirements to be InputStreamable and OutputStreamable. +
++I have no problems leaving the WP in an inconsistent state on the best-faith +assumption these concepts will be provided later, however disagree with the +proposers that these constraints are not separable, orthogonal to the basic +concepts of generating random number distributions. +
++These constraints should be dropped, and applied to specific algorithms as +needed. +
++If a more refined concept (certainly deemed useful by the proposers) is +proposed there is no objection, but the basic concept should not require +persistence via streaming. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open. ++ +[ +2009-05-31 Alisdair adds: +]
+ + +++ + ++Working on constraining the stream iterators, I have a few more observations +to make on the concepts proposed while constraining the random number +facility. +
++While I still believe the concerns are orthogonal, I don't believe the +existing constraints go far enough either! The goal we want to achieve is +not that a RandomNumberEngine / RandomNumberDistribution supports the stream +operators, but that it is Serializable. I.e. there is a relationship +between the insert and extract operations that guarantees to restore the +state of the original object. This implies a coupling of the concepts +together in a broader concept (Serializable) with at least one axiom to +assert the semantics. +
++One problem is that istream and ostream may be fundamentally different +types, although we can hook a relation if we are prepared to drop down to +the char type and char_traits template parameters. Doing so ties us to a +form of serialization that demands implementation via the std iostreams +framework, which seems overly prescriptive. I believe the goal is generally +to support serialization without regard to how it is expressed - although +this is getting even more inventive in terms of concepts we do not have +today. +
+Proposed resolution:
+ + + + + +
+1057. RandomNumberEngineAdaptor
+Section: 26.5 [rand] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [rand].
+View all other issues in [rand].
+View all issues with Open status.
+Discussion:
+ ++The RandomNumberEngineAdaptor concept breaks precedent in the +way the library has been specified by grouping requirements into a +concept that is never actually used in the library. +
++This is undoubtedly a very helpful device for documentation, but we are not +comfortable with the precedent - especially as we have rejected national +body comments on the same grounds. +
++Suggest either removing the concept, or providing an algorithm/type that +requires this concept in their definition (such as a factory function to +create new engines). +
++The preference is to create a single new algorithm and retain the value of +the existing documentation. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Walter points out that it is unlikely that any algorithm would ever +require this concept, but that the concept nonetheless is useful as +documentation, and (via concept maps) as a means of checking specific adapters. +
++Alisdair disagrees as to the concept's value as documentation. +
++Marc points out that the RandomNumberDistribution +is also a concept not used elsewhere in the Standard. +
++Pete agrees that a policy of not inventing concepts +that aren't used in the Standard is a good starting point, +but should not be used as a criterion for rejecting a concept. +
++Move to Open. +
+Proposed resolution:
+ + + + + +
+1058. New container issue
+Section: 23.2.3 [sequence.reqmts] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2009-05-23
+View other active issues in [sequence.reqmts].
+View all other issues in [sequence.reqmts].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
+ ++Sequence containers 23.2.3 [sequence.reqmts]: +
+ ++The return value of new calls added to table 83 are not specified. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to NAD Editorial. +
+Proposed resolution:
++Add after p6 23.2.3 [sequence.reqmts]: +
+ +++ + + + + ++-6- ... +
++The iterator returned from a.insert(p,rv) points to the copy of rv +inserted into a. +
++The iterator returned from a.emplace(p, args) points to the new +element constructed from args inserted into a. +
+
+1059. Usage of no longer existing FunctionType concept
+Section: 20.7.16.2 [func.wrap.func] Status: Open + Submitter: Daniel Krügler Opened: 2009-03-13 Last modified: 2009-05-23
+View other active issues in [func.wrap.func].
+View all other issues in [func.wrap.func].
+View all issues with Open status.
+Discussion:
++Due to a deliberate core language decision, the earlier called +"foundation" concept std::FunctionType had been removed in +N2773 +shortly +before the first "conceptualized" version of the WP +(N2798) +had been +prepared. This caused a break of the library, which already used this +concept in the adapted definition of std::function +(20.7 [function.objects]/2, header <functional> synopsis and +20.7.16.2 [func.wrap.func]). +
++A simple fix would be to either (a) make std::function's primary template +unconstrained or to (b) add constraints based on existing (support) concepts. +A more advanced fix would (c) introduce a new library concept. +
++The big disadvantage of (a) is, that users can define templates which +cause compiler errors during instantiation time because of under-constrainedness +and would thus violate the basic advantage of constrained +code. +
++For (b), the ideal constraints for std::function's template parameter would +be one which excludes everything else but the single provided partial +specialization that matches every "free function" type (i.e. any function +type w/o cv-qualifier-seq and w/o ref-qualifier). +Expressing such a type as as single requirement would be written as +
++template<typename T> +requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq + // or ref-qual (depending on core issue #749) + && PointeeType<T> // Eliminate reference types + && !ObjectType<T> // Eliminate object types ++Just for completeness approach (c), which would make sense, if the +library has more reasons to constrain for free function types: +
++auto concept FreeFunctionType<typename T> + : ReferentType<T>, PointeeType<T>, MemberPointeeType<T> +{ + requires !ObjectType<T>; +} ++I mention that approach because I expect that free function types belong +to the most natural type categories for every days coders. Potential +candidates in the library are addressof and class template packaged_task. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Alisdair would prefer to have a core-supported FunctionType concept +in order that any future changes be automatically correct +without need for a library solution to catch up; +he points to type traits as a precedent. +Further, he believes that a published concept can't in the future +be changed. +
++Bill feels this category of entity would change sufficiently slowly +that he would be willing to take the risk. +
++Of the discussed solutions, we tend toward option (c). +We like the idea of having a complete taxonomy of native types, +and perhaps erred in trimming the set. +
++We would like to have this issue reviewed by Core and would like +their feedback. Move to Open. +
+Proposed resolution:
++
+ + + + + +- +
++Change in 20.7 [function.objects]/2, Header <functional> synopsis: +
++// 20.6.16 polymorphic function wrappers: +class bad_function_call; +template<FunctionTypeReferentType F> +requires PointeeType<F> && !ObjectType<F> +class function; // undefined +- +
++Change in 20.7.16.2 [func.wrap.func]: +
++namespace std { +template<FunctionTypeReferentType F> +requires PointeeType<F> && !ObjectType<F> +class function; // undefined +
+1060. Embedded nulls in NTBS
+Section: 17.5.2.1.4.1 [byte.strings] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2009-03-13 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
+ ++Definition of null-terminated sequences allow for embedded nulls. This is +surprising, and probably not supportable with the intended use cases. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the issue, but believe this can be handled editorially. +Move to NAD Editorial. ++ + + +Proposed resolution:
+ + + + + +
+1061. Bad indexing for tuple access to pair (Editorial?)
+Section: 20.3.4 [pair.astuple] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2009-03-13 Last modified: 2009-05-23
+View all issues with Tentatively NAD Editorial status.
+Discussion:
+ ++The definition of get implies that get must return the second element if +given a negative integer. +
+ +[ +Batavia (2009-05): +]
+ ++Move to NAD Editorial. ++ + + +Proposed resolution:
++20.3.4 [pair.astuple] p5: +
+ ++ + + + + + +template<+intsize_t I, class T1, class T2> + requires True<(I < 2)> + const P& get(const pair<T1, T2>&); +
+1062. Missing insert_iterator for stacks/queues
+Section: 24.7 [insert.iterators] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-13 Last modified: 2009-05-23
+View other active issues in [insert.iterators].
+View all other issues in [insert.iterators].
+View all issues with Open status.
+Discussion:
+ ++It is odd that we have an iterator to insert into a vector, but not an +iterator to insert into a vector that is adapted as a stack. The standard +container adapters all have a common interface to push and pop so it should +be simple to create an iterator adapter to complete the library support. +
+ ++We should provide an AdaptedContainer concept supporting push and pop +operations. Create a new insert iterator and factory function that inserts +values into the container by calling push. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Walter recommends NAD Future. +
++Move to Open, and recommend deferring the issue until after the next +Committee Draft is issued. +
+Proposed resolution:
+ + + + + +
+1063. 03 iterator compatibilty
+Section: D.10.4 [iterator.backward] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-15 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ ++Which header must a user #include to obtain the library-supplied +concept_maps declared in this paragraph? +
+ ++This is important information, as existing user code will break if this +header is not included, and we should make a point of mandating this header +is #include-d by library headers likely to make use of it, notably +<algorithm>. See issue 1001 for more details. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the direction of the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
+Change D.10 [depr.lib.iterator.primitives], Iterator primitives, as +indicated:
+ +++To simplify the use of iterators and provide backward compatibility with + previous C++ Standard Libraries, + the library provides several classes and functions. Unless otherwise + specified, these classes and functions shall be defined in header <iterator>.
+Change D.10.4 [iterator.backward], Iterator backward compatibility, as +indicated:
+++ + + + + +The library provides concept maps that allow iterators specified with + iterator_traits to interoperate with + algorithms that require iterator concepts. These concept maps shall be + defined in the same header that defines the iterator. [Example:
+
+1064. Response to UK 152
+Section: 17.3.15 [defns.obj.state] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-15 Last modified: 2009-03-15
+View all issues with Open status.
+Discussion:
+ +Addresses UK 152
+ ++Object state is using a definition of object (instance of a class) from +outside the standard, rather than the 'region of storage' definiton in +1.8 [intro.object]p1 +
+ +[ +Summit: +]
+ ++We think we're removing this; See 20.7.18.1 [func.referenceclosure.cons]. ++ + +Proposed resolution:
++
+ + + + + +
+1065. Response to UK 168
+Section: 17.6.1.1 [contents] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-03-15 Last modified: 2009-05-23
+View other active issues in [contents].
+View all other issues in [contents].
+View all issues with Tentatively Ready status.
+Discussion:
+Addresses UK 168
++We should make it clear (either by note or normatively) that namespace +std may contain inline namespaces, and that entities specified to be +defined in std may in fact be defined in one of these inline namespaces. +(If we're going to use them for versioning, eg when TR2 comes along, +we're going to need that.) +
+ ++Replace "namespace std or namespaces nested within namespace std" with +"namespace std or namespaces nested within namespace std or inline +namespaces nested directly or indirectly within namespace std" +
+ +[ +Summit: +]
+ ++adopt UK words (some have reservations whether it is correct) ++ +[ +2009-05-09 Alisdair improves the wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++Bill believes there is strictly speaking no need to say that +because no portable test can detect the difference. +However he agrees that it doesn't hurt to say this. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change 17.6.1.1 [contents] p2: +
+ ++All library entities except macros, operator new and +operator delete are defined within the namespace std or +namespaces nested within namespace std. +It is unspecified whether names declared in a specific namespace +are declared directly in that namespace, or in an inline namespace inside +that namespace. [Footnote: This gives implementers freedom to support +multiple configurations of the library.] ++ + + + + +
+1066. Response to UK 189 and JP 27
+Section: 18 [language.support] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-03-15 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+Addresses UK 189 and JP 27
++The addition of the [[noreturn]] attribute to the language will be an +important aid for static analysis tools. +
+ ++The following functions should be declared in C++ with the +[[noreturn]] attribute: abort exit +quick_exit terminate unexpected +rethrow_exception throw_with_nested. +
+ +[ +Summit: +]
+ ++Agreed. ++ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 18.5 [support.start.term] p3: +
+ +++ +-2- ...
+void abort [[noreturn]] (void) ++-3- ...
+-6- ...
+void exit [[noreturn]] (int status) ++-7- ...
+-11- ...
+void quick_exit [[noreturn]] (int status) ++-12- ...
++Change the <exception> synopsis in 18.8 [support.exception]: +
+ ++ +void unexpected [[noreturn]] (); +... +void terminate [[noreturn]] (); +... +void rethrow_exception [[noreturn]] (exception_ptr p); +... +template <class T> void throw_with_nested [[noreturn]] (T&& t);// [[noreturn]]++Change 18.8.2.4 [unexpected]: +
+ ++ +void unexpected [[noreturn]] (); ++Change 18.8.3.3 [terminate]: +
+ ++ +void terminate [[noreturn]] (); ++Change 18.8.5 [propagation]: +
+ ++ +void rethrow_exception [[noreturn]] (exception_ptr p); ++In the synopsis of 18.8.6 [except.nested] and the definition area change: +
+ ++ + + + + +template <class T> void throw_with_nested [[noreturn]] (T&& t);// [[noreturn]]+
+1067. simplified wording for inner_product
+Section: 26.7 [numeric.ops] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-17 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
+ ++One of the motivating examples for introducing requirements-aliases was to +simplify the wording of the inner_product requirements. As the paper +adopting the feature and constrained wording for the library went through in +the same meeting, it was not possible to make the change at the time. The +simpler form should be adopted now though. Similarly, most the other +numerical algorithms can benefit from a minor cleanup. +
++Note that in each case, the second more generalised form of the algorithm +does not benefit, as there are already named constraints supplied by the +template type parameters. +
+ +[ +2009-05-02 Daniel adds: +]
+ + +++ ++one part of the suggested resolution suggests the removal of the +MoveConstructible<T> requirement from +inner_product. According to 26.7.2 [inner.product] +
+ ++Computes its result by initializing the accumulator acc with the +initial value init ++ ++this step requires at least MoveConstructible. +
+ ++Therefore I strongly suggest to take this removal back (Note also +that the corresponding overload with a functor argument still has +the same MoveConstructible<T> requirement). +
+[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution as amended by Daniel's suggestion +to restore MoveConstructible, +reflected in the updated proposed resolution below. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change in 26.7 [numeric.ops] and [accumulate]: +
+ ++ +template <InputIterator Iter, MoveConstructible T> + requires add = HasPlus<T, Iter::reference> + && HasAssign<T,HasPlus<T, Iter::reference>add::result_type> + T accumulate(Iter first, Iter last, T init); ++Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]: +
+ ++ +template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T> + requires mult = HasMultiply<Iter1::reference, Iter2::reference> + && add = HasPlus<T,HasMultiply<Iter1::reference, Iter2::reference>mult::result_type> + && HasAssign< + T, +HasPlus<T, + HasMultiply<Iter1::reference, Iter2::reference>::result_type>add::result_type> + T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init); ++Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]: +
+ ++ +template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> + requires add = HasPlus<InIter::value_type, InIter::reference> + && HasAssign<InIter::value_type, +HasPlus<InIter::value_type, InIter::reference>add::result_type> + && Constructible<InIter::value_type, InIter::reference> + OutIter partial_sum(InIter first, InIter last, OutIter result); ++Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]: +
+ ++ + + + + + +template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> + requires sub = HasMinus<InIter::value_type, InIter::value_type> + && Constructible<InIter::value_type, InIter::reference> + && OutputIterator<OutIter,HasMinus<InIter::value_type, InIter::value_type>sub::result_type> + && MoveAssignable<InIter::value_type> + OutIter adjacent_difference(InIter first, InIter last, OutIter result); +
+1068. class random_device should be movable
+Section: 26.5.6 [rand.device] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-18 Last modified: 2009-05-23
+View all other issues in [rand.device].
+View all issues with Open status.
+Discussion:
+ ++class random_device should be movable. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, and recommend this issue be deferred until after the next +Committee Draft is issued. ++ + +Proposed resolution:
+ + + + + +
+1069. class seed_seq should support efficient move operations
+Section: 26.5.7.1 [rand.util.seedseq] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-18 Last modified: 2009-05-23
+View all other issues in [rand.util.seedseq].
+View all issues with Open status.
+Discussion:
+ ++class seed_seq should support efficient move operations. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, and recommend this issue be deferred until after the next +Committee Draft is issued. ++ + +Proposed resolution:
+ + + + + +
+1070. Ambiguous move overloads in function
+Section: 20.7.16.2 [func.wrap.func] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-03-19 Last modified: 2009-05-23
+View other active issues in [func.wrap.func].
+View all other issues in [func.wrap.func].
+View all issues with Tentatively Ready status.
+Discussion:
++The synopsis in 20.7.16.2 [func.wrap.func] says: +
+ ++ +template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> +{ + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F); + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F&&); + ... + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&); + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes..> + && Convertible<Callable<F, ArgTypes...>::result_type + function& operator=(F); + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function& operator=(F&&); + ... +}; ++Each of the 3 pairs above are ambiguous. We need only one of each pair, and we +could do it with either one. If we choose the F&& version we +need to bring decay into the definition to get the pass-by-value behavior. +In the proposed wording I've gotten lazy and just used the pass-by-value signature. +
+ +[ +2009-05-01 Daniel adds: +]
+ + ++1024 modifies the second removed constructor. ++ +[ +Batavia (2009-05): +]
+ +++ + ++We briefly discussed whether we ought support moveable function objects, +but decided that should be a separate issue if someone cares to propose it. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change the synopsis of 20.7.16.2 [func.wrap.func], and remove the associated definitions in +20.7.16.2.1 [func.wrap.func.con]: +
+ ++ + + + + + +template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> +{ + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F); +template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F&&);+ ... + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); +template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);+ ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes..> + && Convertible<Callable<F, ArgTypes...>::result_type + function& operator=(F); +template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function& operator=(F&&);+ ... +}; +
+1071. is_bind_expression should derive from integral_constant<bool>
+Section: 20.7.12.1.1 [func.bind.isbind] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-19 Last modified: 2009-05-31
+View all issues with Open status.
+Discussion:
+ ++Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]: +
+ ++namespace std { + template<class T> struct is_bind_expression { + static const bool value = see below; + }; +} ++is_bind_expression should derive from std::integral_constant<bool> like +other similar trait types. +
+ +[ +Daniel adds: +]
+ ++We need the same thing for the trait is_placeholder as well. ++[ +2009-03-22 Daniel provided wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++ ++We recommend this be deferred until after the next Committee Draft is issued. +
++Move to Open. +
+[ +2009-05-31 Peter adds: +]
+ + +++ + + ++I am opposed to the proposed resolution and to the premise of the issue +in general. The traits's default definitions should NOT derive from +integral_constant, because this is harmful, as it misleads people into +thinking that is_bind_expression<E> always derives from +integral_constant, whereas it may not. +
++is_bind_expression and is_placeholder allow user +specializations, and in fact, this is their primary purpose. Such user +specializations may not derive from integral_constant, and the +places where is_bind_expression and is_placeholder are +used intentionally do not require such derivation. +
++The long-term approach here is to switch to +BindExpression<E> and Placeholder<P> +explicit concepts, of course, but until that happens, I say leave them +alone. +
+Proposed resolution:
++
+ + + + + +- +
++In 20.7.12.1.1 [func.bind.isbind] change as indicated: +
++namespace std { + template<class T> struct is_bind_expression : integral_constant<bool, see below> { };{ + static const bool value = see below; + };+} +- +
++In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated: +
+++static const bool value;++-2-+true if T is a type returned from bind, false otherwise.+ If T is a type returned from bind, is_bind_expression<T> shall +be publicly derived from + integral_constant<bool, true>, otherwise it shall be +publicly derived from + integral_constant<bool, false>. +- +
++In 20.7.12.1.2 [func.bind.isplace] change as indicated: +
++namespace std { + template<class T> struct is_placeholder : integral_constant<int, see below> { };{ + static const int value = see below; + };+} +- +
++In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated: +
+++static const int value;++-2-+value is J if T is the type of std::placeholders::_J, 0 otherwise.+ If T is the type of std::placeholders::_J, is_placeholder<T> +shall be publicly + derived from integral_constant<int, J> otherwise it shall +be publicly derived + from integral_constant<int, 0>. +
+1072. Is std::hash a constrained template or not?
+Section: 20.7.17 [unord.hash] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-19 Last modified: 2009-05-23
+View other active issues in [unord.hash].
+View all other issues in [unord.hash].
+View all issues with Open status.
+Discussion:
+ ++Is std::hash a constrained template or not? +
++According to Class template hash 20.7.17 [unord.hash], the definition is: +
+ ++ +template <class T> +struct hash : public std::unary_function<T, std::size_t> { + std::size_t operator()(T val) const; +}; ++And so unconstrained. +
++According to the <functional> synopsis in p2 Function objects +20.7 [function.objects] the template is declared as: +
+ ++ +template <ReferentType T> struct hash; ++which would make hash a constrained template. +
+ +[ +2009-03-22 Daniel provided wording. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++Alisdair is not certain that Daniel's proposed resolution is sufficient, +and recommends we leave the hash template unconstrained for now. +
++Recommend that the Project Editor make the constrained declaration consistent +with the definition in order to make the Working Paper internally consistent, +and that the issue then be revisited. +
++Move to Open. +
+Proposed resolution:
+ ++[To the editor: This resolution is merge-compatible to the +resolution of 1078] +
+ ++
+ + + + + +- +
++In 20.7 [function.objects]/2, header <functional> synopsis, change as indicated: +
+ ++// 20.6.17, hash function base template: +template <ReferentType T> struct hash; // undefined +- +
++In 20.7.17 [unord.hash]/1 change as indicated: +
++namespace std { +template <class T> + struct hash : public std::unary_function<T, std::size_t> { + std::size_t operator()(T val) const; + };+ template <ReferentType T> struct hash; // undefined +} +- +
++In 20.7.17 [unord.hash]/2 change as indicated: +
+ ++-2- For all library-provided specializations, the template +instantiation hash<T> + shall provide a public operator() with return type std::size_t to +satisfy the concept + requirement Callable<const hash<T>, const T&>. If T is an object +type or reference to + object, hash<T> shall be publicly derived from +std::unary_function<T, std::size_t>. + The return value of operator() is unspecified, except that +equal arguments + shall yield the same result. operator() shall not throw exceptions. ++- +
++In 18.7 [support.rtti]/1, header <typeinfo> synopsis change as indicated: +
++namespace std { + class type_info; + class type_index; + template <classReferentType T> struct hash; +
+1073. Declaration of allocator_arg should be constexpr
+Section: 20.8 [memory] Status: Tentatively Ready + Submitter: Alisdair Meredith Opened: 2009-03-19 Last modified: 2009-05-23
+View other active issues in [memory].
+View all other issues in [memory].
+View all issues with Tentatively Ready status.
+Discussion:
+ ++Declaration of allocator_arg should be constexpr to ensure constant +initialization. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. Move to Tentatively Ready. ++ + +Proposed resolution:
++Change 20.8 [memory] p2: +
+ ++ + + + + + +// 20.8.1, allocator argument tag +struct allocator_arg_t { }; +constexpr allocator_arg_t allocator_arg = allocator_arg_t(); +
+1074. concept map broken by N2840
+Section: 20.8.3 [allocator.element.concepts] Status: Tentatively NAD + Submitter: Alisdair Meredith Opened: 2009-03-19 Last modified: 2009-05-23
+View all issues with Tentatively NAD status.
+Discussion:
+ ++p7 Allocator-related element concepts 20.8.3 [allocator.element.concepts] +
+ ++The changes to the AllocatableElement concept mean this concept_map +specialization no longer matches the original concept: +
+ ++ +template <Allocator Alloc, class T, class ... Args> + requires HasConstructor<T, Args...> + concept_map AllocatableElement<Alloc, T, Args&&...> { + void construct_element(Alloc& a, T* t, Args&&... args) { + Alloc::rebind<T>(a).construct(t, forward(args)...); + } + } +[ +2009-03-23 Pablo adds: +]
+ + ++Actually, this is incorrect, +N2840 +says. "In section +20.8.3 [allocator.element.concepts] paragraph 8, modify the definition of the +AllocatableElement concept and eliminate the related concept map:" but +then neglects to include the red-lined text of the concept map that was +to be eliminated. Pete also missed this, but I caught it he asked me to +review his edits. Pete's updated WP removes the concept map entirely, +which was the original intent. The issue is, therefore, moot. Note, as +per my presentation of +N2840 +in summit, construct() no longer has a +default implementation. This regrettable fact was deemed (by David +Abrahams, Doug, and myself) to be preferable to the complexity of +providing a default implementation that would not under-constrain a more +restrictive allocator (like the scoped allocators). ++ +[ +2009-05-01 Daniel adds: +]
+ +++ ++it seems to me that #1074 should be resolved as a NAD, because the +current WP has already removed the previous AllocatableElement concept map. +It introduced auto concept AllocatableElement instead, but as of +20.8.3 [allocator.element.concepts]/7 this guy contains now +
++requires FreeStoreAllocatable<T>; +void Alloc::construct(T*, Args&&...); +[ +Batavia (2009-05): +]
+ +++ + ++The affected code is no longer part of the Working Draft. +
++Move to NAD. +
+Proposed resolution:
++Change 20.8.3 [allocator.element.concepts]: +
+ ++ + + + + + +template <Allocator Alloc, class T, class ... Args> + requires HasConstructor<T, Args...> + concept_map AllocatableElement<Alloc, T, Args&&...> { + void construct_element(Alloc& a,T* t, Args&&... args) { + Alloc::rebind<T>(a).construct(t, forward(args)...); + } + } +
+1075. Response to US 65, US 74.1
+Section: 20 [utilities], 23 [containers] Status: Open + Submitter: Alan Talbot Opened: 2009-03-20 Last modified: 2009-06-10
+View all other issues in [utilities].
+View all issues with Open status.
+Discussion:
+Addresses US 65 and US 74.1
+ +US 65:
+ ++Scoped allocators and allocator propagation traits add a small amount of +utility at the cost of a great deal of machinery. The machinery is user +visible, and it extends to library components that don't have any +obvious connection to allocators, including basic concepts and simple +components like pair and tuple. + ++ +Suggested resolution:
+ ++Sketch of proposed resolution: Eliminate scoped allocators, replace +allocator propagation traits with a simple uniform rule (e.g. always +propagate on copy and move), remove all mention of allocators from +components that don't explicitly allocate memory (e.g. pair), and adjust +container interfaces to reflect this simplification. +
++Components that I propose eliminating include HasAllocatorType, +is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor, +and ConstructibleAsElement. +
+US 74.1:
+ +++ ++Scoped allocators represent a poor trade-off for standardization, since +(1) scoped-allocator--aware containers can be implemented outside the +C++ standard library but used with its algorithms, (2) scoped +allocators only benefit a tiny proportion of the C++ community +(since few C++ programmers even use today's allocators), and (3) all C++ +users, especially the vast majority of the C++ community that won't ever +use scoped allocators are forced to cope with the interface complexity +introduced by scoped allocators. +
++In essence, the larger community will suffer to support a very small +subset of the community who can already implement their own +data structures outside of the standard library. Therefore, scoped +allocators should be removed from the working paper. +
++Some evidence of the complexity introduced by scoped allocators: +
++++20.3.3 [pairs], 20.5 [tuple]: Large increase in the +number of pair and tuple constructors. +
++23 [containers]: Confusing "AllocatableElement" requirements throughout. +
+Suggested resolution:
+ ++Remove support for scoped allocators from the working paper. This +includes at least the following changes: +
+ +++ ++Remove 20.8.3 [allocator.element.concepts] +
++Remove 20.8.7 [allocator.adaptor] +
++Remove 20.8.10 [construct.element] +
++In Clause 23 [containers]: replace requirements naming the +AllocatableElement concept with requirements naming CopyConstructible, +MoveConstructible, DefaultConstructible, or Constructible, as +appropriate. +
+[ +Post Summit Alan moved from NAD to Open. +]
+ + +[ +2009-05-15 Ganesh adds: +]
+ + +++ ++The requirement AllocatableElement should not be replaced with +Constructible on the emplace_xxx() functions as suggested. In the +one-parameter case the Constructible requirement is not satisfied when +the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth +bullet) but we do want to allow explicit constructors in emplace, as the +following example shows: +
+ ++ +vector<shared_ptr<int>> v; +v.emplace_back(new int); // should be allowed ++If the issue is accepted and scoped allocators are removed, I suggest to +add a new pair of concepts to 20.2.7 [concept.construct], namely: +
+ ++ +auto concept HasExplicitConstructor<typename T, typename... Args> { + explicit T::T(Args...); +} + +auto concept ExplicitConstructible<typename T, typename... Args> + : HasExplicitConstructor<T, Args...>, NothrowDestructible<T> +{ } ++We should then use ExplicitConstructible as the requirement for all +emplace_xxx() member functions. +
++For coherence and consistency with the similar concepts +Convertible/ExplicitlyConvertible, we might also consider changing +Constructible to: +
+ ++ +auto concept Constructible<typename T, typename... Args> + : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...> +{ } ++Moreover, all emplace-related concepts in 23.2.6 [container.concepts] +should also use ExplicitConstructible instead of Constructible in the +definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be +corrected even if the issue is not accepted. +
++On the other hand, if the issue is not accepted, the scoped allocator +adaptors should be fixed because the following code: +
+ ++ +template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>; + +vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v; +v.emplace_back(new int); // ops! doesn't compile ++doesn't compile, as the member function construct() of the scoped +allocator requires non-explicit constructors through concept +ConstructibleWithAllocator. Fixing that is not difficult but probably +more work than it's worth and is therefore, IMHO, one more reason in +support of the complete removal of scoped allocators. +
+[ +2009-06-09 Alan adds: +]
+ + +++ + + ++I reopened this issue because I did not think that these National Body +comments were adequately addressed by marking them NAD. My understanding +is that something can be marked NAD if it is clearly a misunderstanding +or trivial, but a substantive issue that has any technical merit +requires a disposition that addresses the concerns. +
++The notes in the NB comment list (US 65 & US 74.1) say that: +
++
+- +this issue has not introduced any new arguments not previously discussed, +
+- +the vote (4-9-3) was not a consensus for removing scoped allocators, +
+- +the issue is resolved by +N2840. +
++My opinion is: +
++
+ +- +there are new arguments in both comments regarding concepts (which were +not present in the library when the scoped allocator proposal was voted +in), +
+- +the vote was clearly not a consensus for removal, but just saying there +was a vote does not provide a rationale, +
+- +I do not believe that N2840 addresses these comments (although it does +many other things and was voted in with strong approval). +
++My motivation to open the issue was to ensure that the NB comments were +adequately addressed in a way that would not risk a "no" vote on our +FCD. If there are responses to the technical concerns raised, then +perhaps they should be recorded. If the members of the NB who authored +the comments are satisfied with N2840 and the other disposition remarks +in the comment list, then I am sure they will say so. In either case, +this issue can be closed very quickly in Frankfurt, and hopefully will +have helped make us more confident of approval with little effort. If in +fact there is controversy, my thought is that it is better to know now +rather than later so there is more time to deal with it. +
+Proposed resolution:
+ + + + + +
+1076. unary/binary_negate need constraining and move support
+Section: 20.7.11 [negators] Status: Open + Submitter: Alisdair Meredith Opened: 2009-03-20 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++The class templates unary/binary_negate need constraining and move support. +
++Ideally these classes would be deprecated, allowing unary/binary_function to +also be deprecated. However, until a generic negate adaptor is introduced +that can negate any Callable type, they must be supported so should be +constrained. Likewise, they should be movable, and support adopting a +move-only predicate type. +
++In order to preserve ABI compatibility, new rvalue overloads are supplied in +preference to changing the existing pass-by-const-ref to pass-by-value. +
++Do not consider the issue of forwarding mutable lvalues at this point, +although remain open to another issue on the topic. +
+ +[ +2009-05-01 Daniel adds: +]
+ +++ ++IMO the currently proposed resolution needs some updates +because it is ill-formed at several places: +
+ ++
+- +
++In concept AdaptableUnaryFunction change +
++typename X::result_type; +typename X::argument_type; ++to +
++Returnable result_type = typename X::result_type; +typename argument_type = typename X::argument_type; ++[The replacement "Returnable result_type" instead of "typename +result_type" is non-editorial, but maybe you prefer that as well] +
+- +
+ ++In concept AdaptableBinaryFunction change +
++typename X::result_type; +typename X::first_argument_type; +typename X::second_argument_type; ++to +
++Returnable result_type = typename X::result_type; +typename first_argument_type = typename X::first_argument_type; +typename second_argument_type = typename X::second_argument_type; ++[The replacement "Returnable result_type" instead of "typename +result_type" is non-editorial, but maybe you prefer that as well.] +
+- +
++In class unary/binary_function +
++
+- +I suggest to change "ReturnType" to "Returnable" in both cases. +
+- +I think you want to replace the remaining occurrences of "Predicate" by "P" +(in both classes in copy/move from a predicate) +
+- +
++I think you need to change the proposed signatures of not1 and not2, because +they would still remain unconstrained: To make them constrained at least a +single requirement needs to be added to enable requirement implication. This +could be done via a dummy ("requires True<true>") or just explicit as follows: +
++
+- +
++template <AdaptableUnaryFunction P> +requires Predicate< P, P::argument_type> +unary_negate<P> not1(const P&& pred); +template <AdaptableUnaryFunction P> +requires Predicate< P, P::argument_type > +unary_negate<P> not1(P&& pred); +++-3- Returns: unary_negate<P>(pred). +++[Don't we want a move call for the second overload as in +
++unary_negate<P>(std::move(pred)) ++in the Returns clause ?] +
+- +
+template <AdaptableBinaryFunction P> +requires Predicate< P, P::first_argument_type, P::second_argument_type > +binary_negate<P> not2(const P& pred); +template <AdaptableBinaryFunction P> +requires Predicate< P, P::first_argument_type, P::second_argument_type > +binary_negate<P> not2(P&& pred); +++-5- Returns: binary_negate<P>(pred). +
++[Don't we want a move call for the second overload as in +
++binary_negate<P>(std::move(pred)) ++in the Returns clause ?] +
+[ +Batavia (2009-05): +]
+ +++ + ++There is concern that complicating the solution +to preserve the ABI seems unnecessary, +since we're not in general preserving the ABI. +
++We would prefer a separate paper consolidating all Clause 20 +issues that are for the purpose of providing constrained versions +of the existing facilities. +
++Move to Open. +
+Proposed resolution:
++Add new concepts where appropriate:: +
+ ++ +auto concept AdaptableUnaryFunction< typename X > { + typename X::result_type; + typename X::argument_type; +} + +auto concept AdaptableBinaryFunction< typename X > { + typename X::result_type; + typename X::first_argument_type; + typename X::second_argument_type; +} ++Revise as follows: +
+ ++Base 20.7.3 [base] (Only change is constrained Result) +
+ +++ ++-1- The following classes are provided to simplify the typedefs of the +argument and result types: +
+namespace std { + template <class Arg,classReturnType Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + }; + + template <class Arg1, class Arg2,classReturnType Result> + struct binary_function { + typedef Arg1 first_argument_type; + typedef Arg2 second_argument_type; + typedef Result result_type; + }; +} ++Negators 20.7.11 [negators]: +
+ +++ + + + + + ++-1- Negators not1 and not2 take a unary and a binary predicate, +respectively, and return their complements (5.3.1). +
+ +template <+classAdaptableUnaryFunction Predicate> + requires Predicate< P, P::argument_type > + class unary_negate + : public unary_function<typenamePredicate::argument_type,bool> { + public: + unary_negate(const unary_negate & ) = default; + unary_negate(unary_negate && ); + + requires CopyConstructible< P > + explicit unary_negate(const Predicate& pred); + requires MoveConstructible< P > + explicit unary_negate(Predicate && pred); + + bool operator()(consttypenamePredicate::argument_type& x) const; + }; ++-2 operator() returns !pred(x). ++ +template <class Predicate> + unary_negate<Predicate> not1(const Predicate& pred); +template <class Predicate> + unary_negate<Predicate> not1(Predicate&& pred); +++-3- Returns: unary_negate<Predicate>(pred). ++ +template <+classAdaptableBinaryFunction Predicate> + requires Predicate< P, P::first_argument_type, P::second_argument_type > + class binary_negate + : public binary_function<typenamePredicate::first_argument_type, +typenamePredicate::second_argument_type, bool> { + public: + biary_negate(const binary_negate & ) = default; + binary_negate(binary_negate && ); + + requires CopyConstructible< P > + explicit binary_negate(const Predicate& pred); + requires MoveConstructible< P > + explicit binary_negate(const Predicate& pred); + + bool operator()(consttypenamePredicate::first_argument_type& x, + consttypenamePredicate::second_argument_type& y) const; + }; ++-4- operator() returns !pred(x,y). ++ +template <class Predicate> + binary_negate<Predicate> not2(const Predicate& pred); +template <class Predicate> + binary_negate<Predicate> not2(Predicate&& pred); ++ ++-5- Returns: binary_negate<Predicate>(pred). ++
+1077. Nonesense tuple declarations
+Section: 20.5.2 [tuple.tuple] Status: Tentatively NAD Editorial + Submitter: Pete Becker Opened: 2009-03-20 Last modified: 2009-05-23
+View other active issues in [tuple.tuple].
+View all other issues in [tuple.tuple].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++Class template tuple 20.5.2 [tuple.tuple]: +
+ ++ +template <class... UTypes> + requires Constructible<Types, const UTypes&>... +template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... ++Somebody needs to look at this and say what it should be. +
+ +[ +2009-03-21 Daniel provided wording. +]
+ + +[ +Batavia (2009-05): +]
+ ++The resolution looks correct; move to NAD Editorial. ++ + +Proposed resolution:
++In 20.5.2 [tuple.tuple], class tuple, change as indicated: +
+ ++ +template <class... UTypes> + requires Constructible<Types, const UTypes&>... + tuple(const pair<UTypes...>&); +template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... + tuple(pair<UTypes...>&&); ++[NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8] +
+ + + + + +
+1078. DE-17: Remove class type_index
+Section: 18.7.2 [type.index] Status: Open + Submitter: Doug Gregor Opened: 2009-03-20 Last modified: 2009-03-31
+View all issues with Open status.
+Discussion:
+ +Addresses DE 17
+ ++DE-17: +
++The class type_index should be removed; it provides no additional +functionality beyond providing appropriate concept maps. +
+ +[ +2009-03-31 Peter adds: +]
+ + +++ + + ++It is not true, in principle, that std::type_index provides no utility +compared to bare std::type_info*. +
++std::type_index can avoid the lifetime issues with type_info when the +DLL that has produced the type_info object is unloaded. A raw +type_info* does not, and cannot, provide any protection in this case. +A type_index can (if the implementor so chooses) because it can wrap a +smart (counted or even cloning) pointer to the type_info data that is +needed for name() and before() to work. +
+Proposed resolution:
+Modify the header <typeinfo> synopsis in + 18.7 [support.rtti]p1 as follows:
+ ++ +namespace std { + class type_info; +class type_index;+ template <class T> struct hash; + template<> struct hash<type_indexconst type_info *> : public std::unary_function<type_indexconst type_info *, size_t> { + size_t operator()(type_indexconst type_info *indext) const; + }; + concept_map LessThanComparable<const type_info *> see below + class bad_cast; + class bad_typeid; +} +Add the following new subsection
+++ ++18.7.1.1 Template specialization
+ +hash<const type_info *>
+[type.info.hash]size_t operator()(const type_info *x) const; +++
+- Returns:
+x->hash_code()
Add the following new subsection
+++ +18.7.1.2
+ + +type_info
concept map [type.info.concepts]concept_map LessThanComparable<const type_info *> { + bool operator<(const type_info *x, const type_info *y) { return x->before(*y); } + bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); } + bool operator>(const type_info *x, const type_info *y) { return y->before(*x); } + bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); } +} +++
+- Note: provides a well-defined ordering among +
+type_info const
pointers, which makes such pointers + usable in associative containers (23.4).Remove section 18.7.2 [type.index]
+ + + + + +
+1079. UK-265:
+RandomAccessIterator
'soperator-
has nonsensical effects clauseSection: 24.2.6 [random.access.iterators] Status: Open + Submitter: Doug Gregor Opened: 2009-03-20 Last modified: 2009-03-22
+View other active issues in [random.access.iterators].
+View all other issues in [random.access.iterators].
+View all issues with Open status.
+Discussion:
+Addresses UK 265
+ +UK-265:
++This effects clause is nonesense. It looks more like an axiom stating +equivalence, and certainly an effects clause cannot change the state of +two arguments passed by const reference +
+ + + +Proposed resolution:
+ +Modify 24.2.6 [random.access.iterators]p7-9 as follows:
+ ++ + + + + +difference_type operator-(const X& a, const X& b); +++
+- Precondition: there exists a value
+n
of +difference_type
such thata == b + n
.- +
Effects:b == a + (b - a)
- Returns:
+(a < b) ? distance(a,b) : + -distance(b,a)
n
+1080. Concept ArithmeticLike should provide explicit boolean conversion
+Section: 20.2.13 [concept.arithmetic] Status: Review + Submitter: Daniel Krügler Opened: 2009-03-21 Last modified: 2009-05-23
+View all issues with Review status.
+Discussion:
++Astonishingly, the current concept ArithmeticLike as specified in +20.2.13 [concept.arithmetic] does not provide explicit conversion +to bool although this is a common property of arithmetic types +(4.12 [conv.bool]). Recent proposals that introduced such types +(integers of arbitrary precision, +n2143, +decimals +n2732 +indirectly +via conversion to long long) also took care of such a feature. +
++Adding such an explicit conversion associated function would also +partly solve a currently invalid effects clause in library, which bases +on this property, 24.2.6 [random.access.iterators]/2: +
++ +{ difference_type m = n; + if (m >= 0) while (m--) ++r; + else while (m++) --r; + return r; } ++Both while-loops take advantage of a contextual conversion to bool +(Another problem is that the >= comparison uses the no +longer supported existing implicit conversion from int to IntegralLike). +
+ +Original proposed resolution: ++
+ +- +
++In 20.2.13 [concept.arithmetic], add to the list of less refined +concepts one further concept: +
+ ++concept ArithmeticLike<typename T> + : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, + HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, + HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, + HasPostdecrement<T>, + HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, + HasMultiplyAssign<T, const T&>, + HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> { +- +
++In 24.2.6 [random.access.iterators]/2 change the current effects clause +as indicated [The proposed insertion fixes the problem that the previous +implicit construction from integrals has been changed to an explicit +constructor]: +
++{ difference_type m = n; + if (m >= difference_type(0)) while (m--) ++r; + else while (m++) --r; + return r; } +[ +Batavia (2009-05): +]
+ +++ + + ++We agree that arithmetic types ought be convertible to bool, +and we therefore agree with the proposed resolution's paragraph 1. +
++We do not agree that the cited effects clause is invalid, +as it expresses intent rather than specific code. +
++Move to Review, pending input from concepts experts. +
+Proposed resolution:
++In 20.2.13 [concept.arithmetic], add to the list of less refined +concepts one further concept: +
+ ++ + + + + +concept ArithmeticLike<typename T> + : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, + HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, + HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, + HasPostdecrement<T>, + HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, + HasMultiplyAssign<T, const T&>, + HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> { +
+1081. Response to UK 216
+Section: 21 [strings] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View all other issues in [strings].
+View all issues with Open status.
+Discussion:
+Addresses UK 216, JP 46, JP 48
+ ++All the containers use concepts for their iterator usage, exect for +basic_string. This needs fixing. +
+ ++Use concepts for iterator template parameters throughout the chapter. +
+ +[ +Summit: +]
+ ++NB comments to be handled by Dave Abrahams and Howard Hinnant with +advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies +extensive proposed wording; start there. ++ + +Proposed resolution:
+ + + + + +
+1082. Response to JP 49
+Section: 22 [localization] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View other active issues in [localization].
+View all other issues in [localization].
+View all issues with Open status.
+Discussion:
+Addresses JP 49
+ ++codecvt does not use concept. For example, create CodeConvert +concept and change as follows. +
+ ++ +template<CodeConvert Codecvt, class Elem = wchar_t> + class wstring_convert { +[ +Summit: +]
+ ++To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger. ++ + +Proposed resolution:
+ + + + + +
+1083. Response to JP 52, 53
+Section: 22 [localization] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View other active issues in [localization].
+View all other issues in [localization].
+View all issues with Open status.
+Discussion:
+Addresses JP 52, JP 53
+ ++InputIterator does not use concept. +
+ ++OutputIterator does not use concept. +
+ ++Comments include proposed wording. +
+ +[ +Summit: +]
+ ++To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger. ++ + +Proposed resolution:
+ + + + + +
+1084. Response to UK 250
+Section: 24.2.4 [forward.iterators] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-06-09
+View all other issues in [forward.iterators].
+View all issues with Open status.
+Discussion:
+Addresses UK 250
+ ++A default implementation should be supplied for the post-increment +operator to simplify implementation of iterators by users. +
+ ++Copy the Effects clause into the concept description as the default +implementation. Assumes a default value for postincrement_result +
+ +[ +Summit: +]
+ ++Howard will open an issue. ++ +[ +2009-06-07 Daniel adds: +]
+ + ++This issue cannot currently be resolved as suggested, because +that would render auto-detection of the return type +postincrement_result invalid, see 14.10.2.2 [concept.map.assoc]/4+5. The +best fix would be to add a default type to that associated type, but +unfortunately any default type will prevent auto-deduction of types of +associated functions as quoted above. A corresponding core issue +is in preparation. ++ + +Proposed resolution:
+[ +This wording assumes the acceptance of UK 251 / 1009. Both +wordings change the same paragraphs. +]
+ + ++Change 24.2.4 [forward.iterators]: +
+ +++ + + + + + +concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { + + MoveConstructible postincrement_result; + requires HasDereference<postincrement_result> + && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; + + postincrement_result operator++(X& r, int);{ + X tmp = r; + ++r; + return tmp; + } + + axiom MultiPass(X a, X b) { + if (a == b) *a == *b; + if (a == b) ++a == ++b; + } +} +
+1085. Response to UK 258
+Section: 24.2.5 [bidirectional.iterators] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-06-09
+View all other issues in [bidirectional.iterators].
+View all issues with Open status.
+Discussion:
+Addresses UK 258
+ ++A default implementation should be supplied for the post-decrement +operator to simplify implementation of iterators by users. +
+ ++Copy the Effects clause into the concept description as the default +implementation. Assumes a default value for postincrement_result +
+ +[ +Summit: +]
+ ++Howard will open an issue. ++ +[ +2009-06-07 Daniel adds: +]
+ + ++This issue cannot currently be resolved as suggested, because +that would render auto-detection of the return type +postdecrement_result invalid, see 1084. ++ + +Proposed resolution:
+ ++Change 24.2.5 [bidirectional.iterators]: +
+ +++ + + + + + +concept BidirectionalIterator<typename X> : ForwardIterator<X> { + MoveConstructible postdecrement_result; + requires HasDereference<postdecrement_result> + && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&> + && Convertible<postdecrement_result, const X&>; + X& operator--(X&); + postdecrement_result operator--(X& r, int);{ + X tmp = r; + --r; + return tmp; + } +} +
+1086. Response to UK 284
+Section: 24.6 [stream.iterators] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View all issues with Open status.
+Discussion:
+Addresses UK 284
+ ++The stream iterators need constraining with concepts/requrires clauses. +
+ +[ +Summit: +]
+ ++We agree. To be handled by Howard, Martin and PJ. ++ + +Proposed resolution:
+ + + + + +
+1087. Response to UK 301
+Section: 25.4.5 [alg.replace] Status: Review + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-06-11
+View other active issues in [alg.replace].
+View all other issues in [alg.replace].
+View all issues with Review status.
+Discussion:
+Addresses UK 301
+ ++replace and replace_if have the requirement: OutputIterator<Iter, +Iter::reference> Which implies they need to copy some values in the +range the algorithm is iterating over. This is not however the case, the +only thing that happens is const T&s might be copied over existing +elements (hence the OutputIterator<Iter, const T&>. +
+ ++Remove OutputIterator<Iter, Iter::reference> from replace +and replace_if. +
+ +[ +Summit: +]
+ ++We agree. To be handled by Howard. ++ + +Proposed resolution:
++Change in 25.2 [algorithms.syn] and 25.4.5 [alg.replace]: +
+ ++ + + + + +template<ForwardIterator Iter, class T> + requiresOutputIterator<Iter, Iter::reference> + &&OutputIterator<Iter, const T&> + && HasEqualTo<Iter::value_type, T> + void replace(Iter first, Iter last, + const T& old_value, const T& new_value); + +template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> + requiresOutputIterator<Iter, Iter::reference> + &&OutputIterator<Iter, const T&> + && CopyConstructible<Pred> + void replace_if(Iter first, Iter last, + Pred pred, const T& new_value); +
+1088. Response to UK 342
+Section: 30.6.6 [futures.promise] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View other active issues in [futures.promise].
+View all other issues in [futures.promise].
+View all issues with Open status.
+Discussion:
+Addresses UK 342
+ ++std::promise is missing a non-member overload of swap. This is +inconsistent with other types that provide a swap member function. +
+ ++Add a non-member overload void swap(promise&& x,promise&& y){ x.swap(y); } +
+ +[ +Summit: +]
+ ++Create an issue. Move to review, attention: Howard. Detlef will also +look into it. ++ +[ +Post Summit Daniel provided wording. +]
+ + + +Proposed resolution:
++
+ + + + + + +- +
++In 30.6.6 [futures.promise], before p.1, immediately after class template +promise add: +
+++template <class R> +void swap(promise<R>& x, promise<R>& y); + +- +
++Change 30.6.6 [futures.promise]/10 as indicated (to fix a circular definition): +
++++-10- Effects:
+swap(*this, other)Swaps the associated state +of *this and other ++Throws: Nothing. +
+- +
+ ++After the last paragraph in 30.6.6 [futures.promise] add the following +prototype description: +
+++template <class R> +void swap(promise<R>& x, promise<R>& y); +++++Effects: x.swap(y) +
++Throws: Nothing. +
+
+1089. Response to JP 76
+Section: 30 [thread] Status: Open + Submitter: Howard Hinnant Opened: 2009-03-22 Last modified: 2009-03-22
+View other active issues in [thread].
+View all other issues in [thread].
+View all issues with Open status.
+Discussion:
+Addresses JP 76
+ ++A description for "Throws: Nothing." are not unified. +
+ ++At the part without throw, "Throws: Nothing." should be described. +
+ ++Add "Throws: Nothing." to the following. +
+ ++
+ +- +30.3.1.6 [thread.thread.static] p1 +
+- +30.4.3.1 [thread.lock.guard] p4 +
+- +30.4.3.2.1 [thread.lock.unique.cons] p6 +
+- +30.5.1 [thread.condition.condvar] p7 and p8 +
+- +30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25 +
+[ +Summit: +]
+ ++Pass on to editor. ++ +[ +Post Summit: Editor declares this non-editorial. +]
+ + + +Proposed resolution:
+ + + + + +
+1090. Missing description of packaged_task member swap, missing non-member swap
+Section: 30.6.8 [futures.task] Status: Open + Submitter: Daniel Krügler Opened: 2009-03-22 Last modified: 2009-05-24
+View all issues with Open status.
+Discussion:
++Class template packaged_task in 30.6.8 [futures.task] shows a member swap +declaration, but misses to +document it's effects (No prototype provided). Further on this class +misses to provide a non-member +swap. +
+ +[ +Batavia (2009-05): +]
+ +++ ++Alisdair notes that paragraph 2 of the proposed resolution has already been +applied in the current Working Draft. +
++We note a pending future-related paper by Detlef; +we would like to wait for this paper before proceeding. +
++Move to Open. +
+[ +2009-05-24 Daniel removed part 2 of the proposed resolution. +]
+ + + +Proposed resolution:
++
+ +- +
++In 30.6.8 [futures.task], immediately after the definition of class +template packaged_task add: +
+++template<class R, class... Argtypes> +void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&); + ++
+ + + + + +- +
++In 30.6.8 [futures.task], immediately after operator= prototype +description (After p. 8) add: +
++void swap(packaged_task& other); +++++Effects: Swaps the associated state of *this and other. +
++Throws: Nothing. +
+- +
++At the end of 30.6.8 [futures.task] (after p. 20), add add the following +prototype description: +
+ +++template<class R, class... Argtypes> +void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y); +++++Effects: x.swap(y) +
++Throws: Nothing. +
+
+1091. Response to UK 246
+Section: 23.4.2.2 [multimap.modifiers] Status: Review + Submitter: Beman Dawes Opened: 2009-03-22 Last modified: 2009-05-23
+View all issues with Review status.
+Discussion:
+ +Addresses UK 246
++The content of this sub-clause is purely trying to describe in words the +effect of the requires clauses on these operations, now that we have +Concepts. As such, the description is more confusing than the signature +itself. The semantic for these functions is adequately covered in the +requirements tables in 23.2.4 [associative.reqmts]. +
+ +[ +Beman adds: +]
+ + ++Pete is clearly right that +this one is technical rather than editorial. ++ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Review. +
+Proposed resolution:
++Strike 23.4.2.2 [multimap.modifiers] entirely +(but do NOT strike these signatures from the class template definition!). +
+ + + + + +
+1092. Class template integral_constant should be a constrained template
+Section: 20.6.3 [meta.help] Status: Open + Submitter: Daniel Krügler Opened: 2009-03-22 Last modified: 2009-05-23
+View other active issues in [meta.help].
+View all other issues in [meta.help].
+View all issues with Open status.
+Discussion:
++A first step to change the type traits predicates to constrained templates is to +constrain their common base template integral_constant. This can be done, +without enforcing depending classes to be constrained as well, but not +vice versa +without brute force late_check usages. The following proposed resolution depends +on the resolution of LWG issue 1019. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending a paper that looks at constraints +for the entirety of the type traits +and their relationship to the foundation concepts. +We recommend this be deferred +until after the next Committee Draft is issued. ++ + +Proposed resolution:
++
+ + + + + +- +
++In 20.6.2 [meta.type.synop], Header <type_traits> +synopsis change as indicated: +
++namespace std { +// 20.5.3, helper class: +template <classIntegralConstantExpressionType T, T v> struct integral_constant; +- +
++In 20.6.3 [meta.help] change as indicated: +
++template <classIntegralConstantExpressionType T, T v> +struct integral_constant { + static constexpr T value = v; + typedef T value_type; + typedef integral_constant<T,v> type; + constexpr operator value_type() { return value; } +}; +
+1093. Multiple definitions for random_shuffle algorithm
+Section: 25.4.12 [alg.random.shuffle] Status: Review + Submitter: Alisdair Meredith Opened: 2009-03-22 Last modified: 2009-06-09
+View all other issues in [alg.random.shuffle].
+View all issues with Review status.
+Discussion:
+ ++There are a couple of issues with the declaration of the random_shuffle +algorithm accepting a random number engine. +
+ ++
+ +- +The Iterators must be shuffle iterators, yet this requirement is missing. +
+- +The RandomNumberEngine concept is now provided by the random number +library +(n2836) +and the placeholder should be removed. +
+[ +2009-05-02 Daniel adds: +]
+ + +++ ++this issue completes adding necessary requirement to the +third new random_shuffle overload. The current suggestion is: +
+ ++ +template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand> +requires ShuffleIterator<Iter> +void random_shuffle(Iter first, Iter last, Rand&& g); ++IMO this is still insufficient and I suggest to add the requirement +
++Convertible<Rand::result_type, Iter::difference_type> ++to the list (as the two other overloads already have). +
+ ++Rationale: +
+ +++ ++Its true that this third overload is somewhat different from the remaining +two. Nevertheless we know from UniformRandomNumberGenerator, that +it's result_type is an integral type and that it satisfies +UnsignedIntegralLike<result_type>. +
++To realize it's designated task, the algorithm has to invoke the +Callable aspect of g and needs to perform some algebra involving +it's min()/max() limits to compute another index value that +at this point is converted into Iter::difference_type. This is so, +because 24.2.6 [random.access.iterators] uses this type as argument +of it's algebraic operators. Alternatively consider the equivalent +iterator algorithms in 24.4 [iterator.operations] with the same result. +
++This argument leads us to the conclusion that we also need +Convertible<Rand::result_type, Iter::difference_type> here. +
+[ +Batavia (2009-05): +]
+ +++ ++Alisdair notes that point (ii) has already been addressed. +
++We agree with the proposed resolution to point (i) +with Daniel's added requirement. +
++Move to Review. +
+[ +2009-06-05 Daniel updated proposed wording as recommended in Batavia. +]
+ + + +Proposed resolution:
++Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]: +
+ ++ + + + + + +concept UniformRandomNumberGenerator<typename Rand> { }+template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand> + requires ShuffleIterator<Iter> && + Convertible<Rand::result_type, Iter::difference_type> + void random_shuffle(Iter first, Iter last, Rand&& g); +
+1094. Response to JP 65 and JP 66
+Section: 27.5.4.3 [iostate.flags] Status: Review + Submitter: P.J. Plauger Opened: 2009-03-24 Last modified: 2009-05-23
+View all other issues in [iostate.flags].
+View all issues with Review status.
+Discussion:
+Addresses JP 65 and JP 66
+ ++Switch from "unspecified-bool-type" to "explicit operator bool() const". +
+ ++Replace operator unspecified-bool-type() const;" with explicit operator bool() const; +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to Review. ++ + +Proposed resolution:
++Change the synopis in 27.5.4 [ios]: +
+ ++ +explicit operatorunspecified-bool-typebool() const; ++Change 27.5.4.3 [iostate.flags]: +
+ ++ + + + + + + +explicit operator+ +unspecified-bool-typebool() const; ++++-1- Returns: !fail()
+If fail() then a value that will evaluate +false in a boolean context; otherwise a value that will evaluate true in +a boolean context. The value type returned shall not be convertible to +int.++
+[Note: This conversion can be used in contexts where a bool is expected +(e.g., an if condition); however, implicit conversions (e.g., +to int) that can occur with bool are not allowed, +eliminating some sources of user error. One possible implementation +choice for this type is pointer-to-member. -- end note]+
+1095. Shared objects and the library wording unclear
+Section: 17.6.3.10 [res.on.objects] Status: Review + Submitter: Beman Dawes Opened: 2009-03-27 Last modified: 2009-05-23
+View all issues with Review status.
+Discussion:
++N2775, +Small library thread-safety revisions, among other changes, removed a note from +17.6.3.10 [res.on.objects] that read: +
+ ++[Note: This prohibition against concurrent non-const access means that +modifying an object of a standard library type shared between threads +without using a locking mechanism may result in a data race. --end note.] ++ ++That resulted in wording which is technically correct but can only be +understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races] +Data race avoidance. This has the effect of making +17.6.3.10 [res.on.objects] unclear, and has already resulted in a query +to the LWG reflector. See c++std-lib-23194. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++The proposed wording seems to need a bit of tweaking +("really bad idea" isn't quite up to standardese). +We would like feedback +as to whether the original Note's removal was intentional. +
++Change the phrase "is a really bad idea" +to "risks undefined behavior" and +move to Review status. +
+Proposed resolution:
++Change 17.6.3.10 [res.on.objects] as indicated: +
+ +++ + + + + ++The behavior of a program is undefined if calls to standard library +functions from different threads may introduce a data race. The +conditions under which this may occur are specified in 17.6.4.7. +
++[Note: Thus modifying an object of a standard library type shared between +threads risks undefined behavior unless objects of the type are explicitly +specified as being sharable without data races or the user supplies a +locking mechanism. --end note] +
+
+1096. unconstrained rvalue ref parameters
+Section: 17 [library] Status: Open + Submitter: David Abrahams Opened: 2009-03-21 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
++TODO: Look at all cases of unconstrained rvalue ref parameters and check +that concept req'ts work when T deduced as reference. +
+ ++ We found some instances where that was not done correctly and we figure + the possibility of deducing T to be an lvalue reference was probably + overlooked elsewhere. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending proposed wording from Dave for further review. ++ + +Proposed resolution:
++
+ + + + + +
+1097. #define __STDCPP_THREADS
+Section: 18.2 [support.types] Status: Review + Submitter: Jens Maurer Opened: 2009-04-03 Last modified: 2009-05-23
+View all other issues in [support.types].
+View all issues with Review status.
+Discussion:
+Addresses DE 18
+ ++Freestanding implementations do not (necessarily) have + support for multiple threads (see 1.10 [intro.multithread]). + Applications and libraries may want to optimize for the + absence of threads. I therefore propose a preprocessor + macro to indicate whether multiple threads can occur. +
+ ++There is ample prior implementation experience for this + feature with various spellings of the macro name. For + example, gcc implicitly defines _REENTRANT + if multi-threading support is selected on the compiler + command-line. +
+ ++While this is submitted as a library issue, it may be more + appropriate to add the macro in 16.8 cpp.predefined in the + core language. +
+ ++See also +N2693. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the issue, and believe it is properly a library issue. +
++We prefer that the macro be conditionally defined +as part of the <thread> header. +
++Move to Review. +
+Proposed resolution:
++Insert a new subsection before 18.2 [support.types], entitled +"Feature Macros" (support.macros): +
+++ + + + + + ++The standard library defines the following macros; no explicit +prior inclusion of any header file is necessary. +
++++
+- __STDCPP_THREADS
+- +The macro __STDCPP_THREADS shall be defined if and only if a + program can have more than one thread of execution (1.10 [intro.multithread]). +If the macro is defined, it shall have the same + value as the predefined macro __cplusplus (16.8 [cpp.predefined]). +
+
+1098. definition of get_pointer_safety()
+Section: 20.8.13.7 [util.dynamic.safety] Status: Open + Submitter: Jens Maurer Opened: 2009-04-03 Last modified: 2009-05-23
+View all other issues in [util.dynamic.safety].
+View all issues with Open status.
+Discussion:
+Addresses DE 18
+ ++ In 20.8.13.7 [util.dynamic.safety], get_pointer_safety() purports +to define behavior for + non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]). However, + the cited core-language section in paragraph 4 specifies undefined behavior + for the use of such pointer values. This seems an unfortunate near-contradiction. + I suggest to specify the term relaxed pointer safety in + the core language section and refer to it from the library description. + This issue deals with the library part, the corresponding core issue (c++std-core-13940) + deals with the core modifications. +
+ ++See also +N2693. +
+ +[ +Batavia (2009-05): +]
+ +++ + + ++We recommend if this issue is to be moved, +the issue be moved concurrently with the cited Core issue. +
++We agree with the intent of the proposed resolution. +We would like input from garbage collection specialists. +
++Move to Open. +
+Proposed resolution:
++In 20.8.13.7 [util.dynamic.safety] p16, replace the description of +get_pointer_safety() with: +
+ +++ + + + + ++pointer_safety get_pointer_safety(); +
++++
+Returns: an enumeration value indicating the implementation's treatment +of pointers that are not safely derived (3.7.4.3). Returns +pointer_safety::relaxed if pointers that are not safely derived will be +treated the same as pointers that are safely derived for the duration of +the program. Returns pointer_safety::preferred if pointers that are not +safely derived will be treated the same as pointers that are safely +derived for the duration of the program but allows the implementation to +hint that it could be desirable to avoid dereferencing pointers that are +not safely derived as described. [Example: pointer_safety::preferred +might be returned to detect if a leak detector is running to avoid +spurious leak reports. -- end note] Returns pointer_safety::strict if +pointers that are not safely derived might be treated differently than +pointers that are safely derived.++Returns: Returns pointer_safety::strict if the implementation has + strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is + implementation-defined whether get_pointer_safety returns + pointer_safety::relaxed or pointer_safety::preferred if the + implementation has relaxed pointer safety + (3.7.4.3 [basic.stc.dynamic.safety]).Footnote +
+ ++Throws: nothing +
+ ++Footnote) pointer_safety::preferred might be returned to indicate to the + program that a leak detector is running so that the program can avoid + spurious leak reports. + +
+ +
+1099. Various issues
+Section: 17 [library] Status: Open + Submitter: David Abrahams Opened: 2009-03-21 Last modified: 2009-05-23
+View other active issues in [library].
+View all other issues in [library].
+View all issues with Open status.
+Discussion:
++Notes +
+++ ++[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1, +MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple +on 550 +
++[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to +talk about "copiable from generalized rvalue ref argument" for cases +where we're going to forward and copy. +
++++ This issue may well be quite large. Language in para 4 about "if + an lvalue" is wrong because types aren't expressions. +
++ p1199, call_once has all the same issues. +
++[2009-03-21 Sat] p869 InputIterator pointer type should not be required +to be convertible to const value_type*, rather it needs to have a +operator-> of its own that can be used for the value type. +
++[2009-03-21 Sat] p818 stack has the same problem with default ctor. +
++[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so +
++requires MoveConstructible<Cont> + explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont()); +++ Don't require MoveConstructible when default constructing Cont. + Also missing semantics for move ctor. +
++ [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as + opposed to MoveConstructible? +
++ [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't + be MoveConstructible). No documented semantics for move c'tor. Or + *any* of its 7 ctors! +
++ [2009-03-21 Sat] std::array should have constructors for C++0x, + consequently must consider move construction. +
+ +[ +2009-05-01 Daniel adds: +]
+ + ++This could be done as part of 1035, which already handles +deviation of std::array from container tables. ++ ++ [2009-03-21 Sat] p622 all messed up. +
+++ ++ para 8 "implementation-defined" is the wrong term; should be "see + below" or something. +
++ para 12 "will be selected" doesn't make any sense because we're not + talking about actual arg types. +
++ paras 9-13 need to be totally rewritten for concepts. +
++ [2009-03-21 Sat] Null pointer comparisons (p587) have all become + unconstrained. Need to fix that +
++ [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration. + We think CopyConstructible is the right reqt. +
++ make_pair needs Constructible<V1, T1&&> requirements! +
++ make_tuple needs something similar +
++ tuple bug in synopsis: +
++ +template <class... UTypes> + requires Constructible<Types, const UTypes&>... + template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... +++ Note: removal of MoveConstructible requirements in std::function makes + these routines unconstrained! +
+[ +2009-05-02 Daniel adds: +]
+ + ++This part of the issue is already covered by 1077. ++ ++ these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ] +
++unique_ptr(pointer p, implementation-defined d); + unique_ptr(pointer p, implementation-defined d); ++ multimap range constructor should not have MoveConstructible<value_type> requirement. +
++ same with insert(..., P&&); multiset has the same issue, as do + unordered_multiset and unordered_multimap. Review these! ++ +[ +Batavia (2009-05): +]
+ ++Move to Open, pending proposed wording from Dave for further review. ++ + +Proposed resolution:
++
+ + + + + +
+1100. auto_ptr to unique_ptr conversion
+Section: D.9 [depr.auto.ptr] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-04-25 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++Message c++std-lib-23182 led to a discussion in which several people +expressed interest in being able to convert an auto_ptr to a +unique_ptr without the need to call release. Below is +wording to accomplish this. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Pete believes it not a good idea to separate parts of a class's definition. +Therefore, if we do this, +it should be part of unique-ptr's specification. +
++Alisdair believes the lvalue overload may be not necessary. +
++Marc believes it is more than just sugar, +as it does ease the transition to unique-ptr. +
++We agree with the resolution as presented. +Move to Tentatively Ready. +
+Proposed resolution:
++Add to D.9 [depr.auto.ptr]: +
+ +++ + + + + + ++The following unique_ptr constructors are in addition to those specified +in 20.8.12.2.1 [unique.ptr.single.ctor]. +
+template <class T, class D> +class unique_ptr +{ +public: + template <class U> + requires SameType<D, default_delete<T>> + && Convertible<U*, T*> + unique_ptr(auto_ptr<U>& u); + template <class U> + requires SameType<D, default_delete<T>> + && Convertible<U*, T*> + unique_ptr(auto_ptr<U>&& u); +}; +++Effects: Constructs a unique_ptr with u.release(). +
+ ++Postconditions: get() == the value u.get() had before +the construciton, modulo any required offset adjustments resulting from the cast from +U* to T*. u.get() == nullptr. +
+ ++Throws: nothing. +
+
+1101. unique requirements
+Section: 25.4.9 [alg.unique] Status: Tentatively NAD Editorial + Submitter: Howard Hinnant Opened: 2009-04-25 Last modified: 2009-05-23
+View other active issues in [alg.unique].
+View all other issues in [alg.unique].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++From Message c++std-core-14160 Howard wrote: +
+ ++It was the intent of the rvalue reference proposal for unique to only require MoveAssignable: +N1860. ++ ++And Pete replied: +
+ ++That was overridden by the subsequent changes made for concepts in +N2573, +which reimposed the C++03 requirements. ++ ++My impression is that this overwrite was a simple (unintentional) mistake. +Wording below to correct it. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++Howard notes this issue resolves a discrepancy between the synopsis +and the description. +
++Move to NAD Editorial. +
+Proposed resolution:
++Change 25.4.9 [alg.unique]: +
+ ++ +template<ForwardIterator Iter> + requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> + && EqualityComparable<Iter::value_type> + Iter unique(Iter first, Iter last); + +template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> + requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> + && CopyConstructible<Pred> + Iter unique(Iter first, Iter last, Pred pred); ++Note that the synopsis in 25.2 [algorithms.syn] is already correct. +
+ + + + + + +
+1102. std::vector's reallocation policy still unclear
+Section: 23.3.6.2 [vector.capacity] Status: Review + Submitter: Daniel Krügler Opened: 2009-04-20 Last modified: 2009-05-23
+View all other issues in [vector.capacity].
+View all issues with Review status.
+Discussion:
++I have the impression that even the wording of current draft +N2857 +does insufficiently express the intent of vector's +reallocation strategy. This has produced not too old library +implementations which release memory in the clear() function +and even modern articles about C++ programming cultivate +the belief that clear is allowed to do exactly this. A typical +example is something like this: +
+ ++const int buf_size = ...; +std::vector<T> buf(buf_size); +for (int i = 0; i < some_condition; ++i) { + buf.resize(buf_size); + write_or_read_data(buf.data()); + buf.clear(); // Ensure that the next round get's 'zeroed' elements +} ++where still the myth is ubiquitous that buf might be +allowed to reallocate it's memory *inside* the for loop. +
++IMO the problem is due to the fact, that +
+ ++
+ +- +the actual memory-reallocation stability of std::vector +is explained in 23.3.6.2 [vector.capacity]/3 and /6 which +are describing just the effects of the reserve +function, but in many examples (like above) there +is no explicit call to reserve involved. Further-more +23.3.6.2 [vector.capacity]/6 does only mention insertions +and never mentions the consequences of erasing +elements. +
+- +
++the effects clause of std::vector's erase overloads in +23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This +easily causes a misunderstanding, because the counter +parting insert functions described in 23.3.6.4 [vector.modifiers]/2 +explicitly say, that +
++Causes reallocation if the new size is greater than the +old capacity. If no reallocation happens, all the iterators +and references before the insertion point remain valid. +++It requires a complex argumentation chain about four +different places in the standard to provide the - possibly +weak - proof that calling clear() also does never change +the capacity of the std::vector container. Since std::vector +is the de-facto replacement of C99's dynamic arrays this +type is near to a built-in type and it's specification should +be clear enough that usual programmers can trust their +own reading. +
+[ +Batavia (2009-05): +]
+ +++ + ++Bill believes paragraph 1 of the proposed resolution is unnecessary +because it is already implied (even if tortuously) by the current wording. +
++Move to Review. +
+Proposed resolution:
+[ +This is a minimum version. I also +suggest that the wording explaining the allocation strategy +of std::vector in 23.3.6.2 [vector.capacity]/3 and /6 is moved into +a separate sub paragraph of 23.3.6.2 [vector.capacity] before +any of the prototype's are discussed, but I cannot provide +reasonable wording changes now +]
+ + ++
+ + + + + +- +
++Change 23.3.6.2 [vector.capacity]/6 as follows: +
++It is guaranteed that no reallocation takes place during +insertions or erasures that happen after a call +to reserve() until the time when an insertion would make +the size of the vector greater than the value of capacity(). ++- +
++Change 23.3.6.4 [vector.modifiers]/4 as follows: +
++Effects: The capacity shall remain unchanged and no reallocation shall +happen. +Invalidates iterators and references at or after the point +of the erase. ++
+1103. system_error constructor postcondition overly strict
+Section: 19.5.5.2 [syserr.syserr.members] Status: Tentatively Ready + Submitter: Howard Hinnant Opened: 2009-04-25 Last modified: 2009-05-23
+View all issues with Tentatively Ready status.
+Discussion:
++19.5.5.2 [syserr.syserr.members] says: +
+ ++ +system_error(error_code ec, const string& what_arg); +++++Effects: Constructs an object of class system_error. +
++Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg.c_str()) == 0. +
++However the intent is for: +
+ ++ +std::system_error se(std::errc::not_a_directory, "In FooBar"); +... +se.what(); // returns something along the lines of: + // "In FooBar: Not a directory" ++The way the constructor postconditions are set up now, to achieve both +conformance, and the desired intent in the what() string, the +system_error constructor must store "In FooBar" in the base class, +and then form the desired output each time what() is called. Or +alternatively, store "In FooBar" in the base class, and store the desired +what() string in the derived system_error, and override +what() to return the string in the derived part. +
+ ++Both of the above implementations seem suboptimal to me. In one I'm computing +a new string every time what() is called. And since what() +can't propagate exceptions, the client may get a different string on different +calls. +
+ ++The second solution requires storing two strings instead of one. +
+ ++What I would like to be able to do is form the desired what() string +once in the system_error constructor, and store that in the +base class. Now I'm: +
+ ++
+ +- Computing the desired what() only once.
+- The base class what() definition is sufficient and nothrow.
+- I'm not storing multiple strings.
++This is smaller code, smaller data, and faster. +
+ ++ios_base::failure has the same issue. +
+ +[ +Comments about this change received favorable comments from the system_error +designers. +]
+ + +[ +Batavia (2009-05): +]
+ + +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions: +
+ +++ +system_error(error_code ec, const string& what_arg); +++-2- Postconditions: code() == ec +and+ +strcmp(runtime_error::what(), what_arg.c_str()) == 0+string(what()).find(what_arg) != string::npos. +system_error(error_code ec, const char* what_arg); +++-4- Postconditions: code() == ec +and+ +strcmp(runtime_error::what(), what_arg) == 0+string(what()).find(what_arg) != string::npos. +system_error(error_code ec); +++-6- Postconditions: code() == ec ++ +and strcmp(runtime_error::what(), "". +system_error(int ev, const error_category& ecat, const string& what_arg); +++-8- Postconditions: code() == error_code(ev, ecat) +and+ +strcmp(runtime_error::what(), what_arg.c_str()) == 0+string(what()).find(what_arg) != string::npos. +system_error(int ev, const error_category& ecat, const char* what_arg); +++-10- Postconditions: code() == error_code(ev, ecat) +and+ +strcmp(runtime_error::what(), what_arg) == 0+string(what()).find(what_arg) != string::npos. +system_error(int ev, const error_category& ecat); +++-12- Postconditions: code() == error_code(ev, ecat) ++ +and strcmp(runtime_error::what(), "") == 0. ++In 19.5.5.2 [syserr.syserr.members], change the description of what(): +
+ +++ +const char *what() const throw(); +++++-14- Returns: An NTBS incorporating
+runtime_error::what() and +code().message()the arguments supplied in the constructor. ++[Note:
+One possible implementation would be:+The return NTBS might take the form: what_arg + ": " + code().message() +++if (msg.empty()) { + try { + string tmp = runtime_error::what(); + if (code()) { + if (!tmp.empty()) + tmp += ": "; + tmp += code().message(); + } + swap(msg, tmp); + } catch(...) { + return runtime_error::what(); + } +return msg.c_str(); ++— end note] +
++In 27.5.2.1.1 [ios::failure], change the synopsis: +
+ ++ +namespace std { + class ios_base::failure : public system_error { + public: + explicit failure(const string& msg, const error_code& ec = io_errc::stream); + explicit failure(const char* msg, const error_code& ec = io_errc::stream); +virtual const char* what() const throw();+ }; +} ++In 27.5.2.1.1 [ios::failure], change the description of the constructors: +
+ ++ ++ +explicit failure(const string& msg, , const error_code& ec = io_errc::stream); ++++ ++-3- Effects: Constructs an object of class failure +by constructing the base class with msg and ec. +
++
+-4- Postcondition: code() == ec and strcmp(what(), msg.c_str()) == 0+explicit failure(const char* msg, const error_code& ec = io_errc::stream); ++++ ++-5- Effects: Constructs an object of class failure +by constructing the base class with msg and ec. +
++
+-6- Postcondition: code() == ec and strcmp(what(), msg) == 0++In 27.5.2.1.1 [ios::failure], remove what (the base class definition +need not be repeated here). +
+ +++ + + + + + ++const char* what() const;+++ +-7- Returns: The message msg with which the exception was created.+
+1104. basic_ios::move should accept lvalues
+Section: 27.5.4.2 [basic.ios.members] Status: Review + Submitter: Howard Hinnant Opened: 2009-04-25 Last modified: 2009-05-23
+View other active issues in [basic.ios.members].
+View all other issues in [basic.ios.members].
+View all issues with Review status.
+Discussion:
++With the rvalue reference changes in +N2844 +basic_ios::move no longer has the most convenient signature: +
+ ++ +void move(basic_ios&& rhs); ++This signature should be changed to accept lvalues. It does not need to be +overloaded to accept rvalues. This is a special case that only derived clients +will see. The generic move still needs to accept rvalues. +
+ +[ +Batavia (2009-05): +]
+ +++ ++Tom prefers, on general principles, to provide both overloads. +Alisdair agrees. +
++Howard points out that there is no backward compatibility issue +as this is new to C++0X. +
++We agree that both overloads should be provided, +and Howard will provide the additional wording. +Move to Open. +
+[ +2009-05-23 Howard adds: +]
+ + ++Added overload, moved to Review. ++ + + +Proposed resolution:
++Add a signature to the existing prototype in the synopsis of 27.5.4 [ios] +and in 27.5.4.2 [basic.ios.members]: +
+ ++ + + + + +void move(basic_ios& rhs); +void move(basic_ios&& rhs); +
+1105. Shouldn't Range be an auto concept
+Section: 24.2.8 [iterator.concepts.range] Status: Open + Submitter: David Abrahams Opened: 2009-04-23 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
+ +[ +2009-04-26 Herb adds: +]
+ + +++ ++Here's a common example: We have many ISV customers who have built lots of +in-house STL-like containers. Imagine that, for the past ten years, the user +has been happily using his XYZCorpContainer<T> that has begin() and end() +and an iterator typedef, and indeed satisfies nearly all of Container, +though maybe not quite all just like valarray. The user upgrades to a +range-enabled version of a library, and now lib_algo( xyz.begin(), xyz.end()); +no longer works -- compiler error. +
++Even though XYZCorpContainer matches the pre-conceptized version of the +algorithm, and has been working for years, it appears the user has to write +at least this: +
++template<class T> concept_map Range<XYZCorpContainer<T>> {}; + +template<class T> concept_map Range<const XYZCorpContainer<T>> {}; ++Is that correct? +
++But he may actually have to write this as we do for initializer list: +
++ +template<class T> +concept_map Range<XYZCorpContainer<T>> { + typedef T* iterator; + iterator begin(XYZCorpContainer<T> c) { return c.begin(); } + iterator end(XYZCorpContainer<T> c) { return c.end(); } +}; + +template<class T> +concept_map Range<const XYZCorpContainer<T>> { + typedef T* iterator; + iterator begin(XYZCorpContainer<T> c) { return c.begin(); } + iterator end(XYZCorpContainer<T> c) { return c.end(); } +}; +[ +2009-04-28 Alisdair adds: +]
+ + +++ ++I recommend NAD, although remain concerned about header organisation. +
++A user container will satisfy the MemberContainer concept, which IS auto. +There is a concept_map for all MemberContainers to Container, and then a +further concept_map for all Container to Range, so the stated problem is not +actually true. User defined containers will automatically match the Range +concept without explicitly declaring a concept_map. +
++The problem is that they should now provide an additional two headers, +<iterator_concepts> and <container_concepts>. + The only difference from +making Range an auto concept would be this reduces to a single header, +<iterator_concepts>. +
++I am strongly in favour of any resolution that tackles the issue of +explicitly requiring concept headers to make these concept maps available. +
+[ +Batavia (2009-05): +]
+ +++ + ++We observe there is a recent paper by Bjarne that overlaps this issue. +
++Alisdair continues to recommend NAD. +
++Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +
+Proposed resolution:
+ + + + + +
+1106. Multiple exceptions from connected shared_future::get()?
+Section: 30.6.5 [future.shared_future] Status: Open + Submitter: Thomas J. Gritzan Opened: 2009-04-03 Last modified: 2009-05-23
+View other active issues in [future.shared_future].
+View all other issues in [future.shared_future].
+View all issues with Open status.
+Discussion:
++It is not clear, if multiple threads are waiting in a +shared_future::get() call, if each will rethrow the stored exception. +
++Paragraph 9 reads: +
++Throws: the stored exception, if an exception was stored and not +retrieved before. +++The "not retrieved before" suggests that only one exception is thrown, +but one exception for each call to get() is needed, and multiple calls +to get() even on the same shared_future object seem to be allowed. +
++I suggest removing "and not retrieved before" from the Throws paragraph. +I recommend adding a note that explains that multiple calls on get() are +allowed, and each call would result in an exception if an exception was +stored. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We note there is a pending paper by Detlef +on such future-related issues; +we would like to wait for his paper before proceeding. +
++Alisdair suggests we may want language to clarify that this +get() function can be called from several threads +with no need for explicit locking. +
++Move to Open. +
+Proposed resolution:
++Change 30.6.5 [future.shared_future]: +
+ ++ + + + + + +const R& shared_future::get() const; +R& shared_future<R&>::get() const; +void shared_future<void>::get() const; ++++...
++-9- Throws: the stored exception, if an exception was stored
+and not retrieved before. + +[Note: Multiple calls on get() are +allowed, and each call would result in an exception if an exception was +stored. — end note] + +
+1107. constructor shared_future(unique_future) by value?
+Section: 30.6.5 [future.shared_future] Status: Tentatively Ready + Submitter: Thomas J. Gritzan Opened: 2009-04-03 Last modified: 2009-05-23
+View other active issues in [future.shared_future].
+View all other issues in [future.shared_future].
+View all issues with Tentatively Ready status.
+Discussion:
++In the shared_future class definition in 30.6.5 [future.shared_future] +the move constructor +that constructs a shared_future from an unique_future receives the +parameter by value. In paragraph 3, the same constructor receives it as +const value. +
+ ++I think that is a mistake and the constructor should take a r-value +reference: +
+ ++ +shared_future(unique_future<R>&& rhs); +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Tentatively Ready. +
+Proposed resolution:
++Change the synopsis in 30.6.5 [future.shared_future]: +
+ ++ +shared_future(unique_future<R>&& rhs); ++Change the definition of the constructor in 30.6.5 [future.shared_future]: +
+ ++ + + + + + +shared_future(constunique_future<R>&& rhs); +
+1108. thread.req.exception overly constrains implementations
+Section: 30.2.2 [thread.req.exception] Status: Open + Submitter: Christopher Kohlhoff Opened: 2009-04-25 Last modified: 2009-05-23
+View all issues with Open status.
+Discussion:
++The current formulation of 30.2.2 [thread.req.exception]/2 reads: +
++The error_category of the error_code reported by such an +exception's code() member function is as specified in the error +condition Clause. +++This constraint on the code's associated error_categor means an +implementation must perform a mapping from the system-generated +error to a generic_category() error code. The problems with this +include: +
+ ++
+- +The mapping is always performed, even if the resultant value is + never used. +
+- +
++The original error produced by the operating system is lost. +
++The latter was one of Peter Dimov's main objections (in a private +email discussion) to the original error_code-only design, and led to +the creation of error_condition in the first place. Specifically, +error_code and error_condition are intended to perform the following +roles: +
++
+- +error_code holds the original error produced by the operating + system. +
+- +error_condition and the generic category provide a set of well + known error constants that error codes may be tested against. +
++Any mapping determining correspondence of the returned error code to +the conditions listed in the error condition clause falls under the +"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects]. +(Although obviously their latitude is restricted a little by the +need to match the right error condition when returning an error code +from a library function.) +
++It is important that this error_code/error_condition usage is done +correctly for the thread library since it is likely to set the +pattern for future TR libraries that interact with the operating +system. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. ++ + +Proposed resolution:
++Change 30.2.2 [thread.req.exception]/2: +
+ +++ + + + + + ++-2-
+The error_category (19.5.1.1) of the error_code reported by +such an exception's code() member function +is as specified in the error condition Clause.+ +The error_code reported by such an exception's code() member +function shall compare equal to one of the conditions specified in +the function's error condition Clause. [Example: When the thread +constructor fails: + ++ ++ec.category() == implementation-defined // probably system_category +ec == errc::resource_unavailable_try_again // holds true ++— end example] +
+ +
+1109. std::includes should require CopyConstructible predicate
+Section: 25.5.5.1 [includes] Status: Tentatively NAD Editorial + Submitter: Alisdair Meredith Opened: 2009-04-28 Last modified: 2009-05-23
+View other active issues in [includes].
+View all other issues in [includes].
+View all issues with Tentatively NAD Editorial status.
+Discussion:
++All the set operation algorithms require a CopyConstructible predicate, with +the exception of std::includes. This looks like a typo as much as anything, +given the general library requirement that predicates are copy +constructible, and wording style of other set-like operations. +
+ +[ +Batavia (2009-05): +]
+ ++We agree with the proposed resolution. +Move to NAD Editorial. ++ + +Proposed resolution:
++Change 25.2 [algorithms.syn] and 25.5.5.1 [includes]: +
+ ++ + + + + +template<InputIterator Iter1, InputIterator Iter2, +typenameCopyConstructible Compare> + requires Predicate<Compare, Iter1::value_type, Iter2::value_type> + && Predicate<Compare, Iter2::value_type, Iter1::value_type> + bool includes(Iter1 first1, Iter1 last1, + Iter2 first2, Iter2 last2, + Compare comp); +
+1110. Is for_each overconstrained?
+Section: 25.3.4 [alg.foreach] Status: Open + Submitter: Alisdair Meredith Opened: 2009-04-29 Last modified: 2009-05-23
+View other active issues in [alg.foreach].
+View all other issues in [alg.foreach].
+View all issues with Open status.
+Discussion:
++Quoting working paper for reference (25.3.4 [alg.foreach]): +
+ +++ +template<InputIterator Iter, Callable<auto, Iter::reference> Function> + requires CopyConstructible<Function> + Function for_each(Iter first, Iter last, Function f); +++++1 Effects: Applies f to the result of dereferencing every iterator in the + range [first,last), starting from first and proceeding to last - 1. +
++2 Returns: f. +
++3 Complexity: Applies f exactly last - first times. +
++P2 implies the passed object f should be invoked at each stage, rather than +some copy of f. This is important if the return value is to usefully +accumulate changes. So the requirements are an object of type Function can +be passed-by-value, invoked multiple times, and then return by value. In +this case, MoveConstructible is sufficient. This would open support for +move-only functors, which might become important in concurrent code as you +can assume there are no other references (copies) of a move-only type and so +freely use them concurrently without additional locks. +
+ +[ +See further discussion starting with c++std-lib-23686. +]
+ + +[ +Batavia (2009-05): +]
+ +++ + ++Pete suggests we may want to look at this in a broader context +involving other algorithms. +We should also consider the implications of parallelism. +
++Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +
+Proposed resolution:
++Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]: +
+ ++ + + + + +template<InputIterator Iter, Callable<auto, Iter::reference> Function> + requiresCopyConstructibleMoveConstructible<Function> + Function for_each(Iter first, Iter last, Function f); +
+1111. associative containers underconstrained
+Section: 23.4 [associative] Status: Review + Submitter: Alisdair Meredith Opened: 2009-04-29 Last modified: 2009-05-23
+View other active issues in [associative].
+View all other issues in [associative].
+View all issues with Review status.
+Discussion:
++According to table 87 (n2857) the expression X::key_equal for an unordered +container shall return a value of type Pred, where Pred is an equivalence +relation. +
+ ++However, all 4 containers constrain Pred to be merely a Predicate, +and not EquivalenceRelation. +
+ +[ +Batavia (2009-05): +]
+ +++ + ++We agree with the proposed resolution. +
++Move to Review. +
+Proposed resolution:
++For ordered containers, replace +
++Predicate<auto, Key, Key> Compare = less<Key> ++with +
++ +StrictWeakOrder<auto, Key, Key> Compare = less<Key> ++For unordered containers, replace +
++Predicate<auto, Key, Key> Compare = less<Key> ++with +
++EquivalenceRelation<auto, Key, Key> Compare = less<Key> ++As in the following declarations: +
+ +++ + + + + + ++Associative containers 23.4 [associative] +
++ 1 Headers <map> and <set>: +
++ Header <map> synopsis +
++ +namespace std { + template <ValueType Key, ValueType T, +PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class map; + + ... + + template <ValueType Key, ValueType T, +PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multimap; + + ... + + } ++ Header <set> synopsis +
++ +namespace std { + template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class set; + + ... + + template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multiset; + + ... + + } ++ 23.4.1p2 Class template map [map] +
++ + +namespace std { + template <ValueType Key, ValueType T, +PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class map { + ... + }; + } ++ 23.4.2p2 Class template multimap [multimap] +
++ + +namespace std { + template <ValueType Key, ValueType T, +PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multimap { + ... + }; + } ++ 23.4.3p2 Class template set [set] +
++ + +namespace std { + template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class set { + ... + }; + } ++ 23.4.4p2 Class template multiset [multiset] +
++ +namespace std { + template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multiset { + ... + }; + } ++ 23.5 Unordered associative containers [unord] +
++ 1 Headers <unordered_map> and <unordered_set>: +
++ Header <unordered_map> synopsis +
++ +namespace std { + // 23.5.1, class template unordered_map: + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, +PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_map; + + // 23.5.2, class template unordered_multimap: + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, +PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multimap; + + ... + } ++ Header <unordered_set> synopsis +
++ +namespace std { + // 23.5.3, class template unordered_set: + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, +PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_set; + + // 23.5.4, class template unordered_multiset: + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, +PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multiset; + + ... + } ++ 23.5.1p3 Class template unordered_map [unord.map] +
++ +namespace std { + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, +PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_map + { + ... + }; + } ++ 23.5.2p3 Class template unordered_multimap [unord.multimap] +
++ +namespace std { + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, +PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair<<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multimap + { + ... + }; + } ++ 23.5.3p3 Class template unordered_set [unord.set] +
++namespace std { + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, +PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_set + { + ... + }; + } ++ 23.5.4p3 Class template unordered_multiset [unord.multiset] +
++ +namespace std { + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, +PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multiset + { + ... + }; + } +
+1112. bitsets and new style for loop
+Section: 20.3.6 [template.bitset] Status: Open + Submitter: Alisdair Meredith Opened: 2009-05-06 Last modified: 2009-05-25
+View other active issues in [template.bitset].
+View all other issues in [template.bitset].
+View all issues with Open status.
+Discussion:
++Std::bitset is a homogeneous container-like sequence of bits, yet it does +not model the Range concept so cannot be used with the new for-loop syntax. +It is the only such type in the library that does NOT support the new for +loop. +
++The obvious reason is that bitset does not support iterators. +
++At least two reasonable solutions are available: +
++
+- +Add an iterator interface to bitset, bringing its interface close to that +of std::array +
+- +Provide an unspecified concept_map for Range<bitset>. +
++The latter will still need some kind of iterator-like adapter for bitset, +but gives implementers greater freedom on the details. E.g. begin/end return +some type that simply invokes operator[] on the object it wraps, and +increments its index on operator++. A vendor can settle for InputIterator +support, rather than wrapping up a full RandomAccessIterator. +
++I have a mild preference for option (ii) as I think it is less work to +specify at this stage of the process, although (i) is probably more useful +in the long run. +
++Hmm, my wording looks a little woolly, as it does not say what the element +type of the range is. Do I get a range of bool, bitset<N>::reference, or +something else entirely? +
++I guess most users will assume the behaviour of reference, but expect to +work with bool. Bool is OK for read-only traversal, but you really need to +take a reference to a bitset::reference if you want to write back. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open. +We further recommend this be deferred until after the next Committee Draft. ++ +[ +2009-05-25 Alisdair adds: +]
+ + +++ + + ++I just stumbled over the Range concept_map for valarray and this should +probably set the precedent on how to write the wording. +
+ +[ +Howard: I've replaced the proposed wording with Alisdair's suggestion. +]
+ + +Proposed resolution:
+ ++20.3.6.X bitset concept maps [bitset.concepts] (made up clause name/number) +
+template<size_t N> +concept_map Range<bitset<N>> { + typedef unspecified iterator; + iterator begin(bitset<N>& a); + iterator end(bitset<N>& a); +} + +template<typename T> +concept_map Range<const bitset<N>> { + typedef unspecified iterator; + iterator begin(const bitset<N>& a); + iterator end(const bitset<N>& a); +} +++-1- Note: these concept_maps adapt bitset to the Range concept. +
+ +typedef unspecified iterator; ++ ++-2- Requires: iterator shall meet the requirements of the +RandomAccessIterator concept and iterator::reference +shall equal bitset<N>::reference or const bitset<N>::reference. ++ +iterator begin(bitset<N>& a); +iterator begin(const bitset<N>& a); ++ ++-3- Returns: an iterator referencing the first bit in the bitset. ++ +iterator end(bitset<N>& a); +iterator end(const bitset<N>& a); ++ ++-4- Returns: an iterator referencing one past the last bit in the bitset. ++ + + + + + + + + + +
+1113. bitset::to_string could be simplified
+Section: 20.3.6 [template.bitset] Status: Open + Submitter: Alisdair Meredith Opened: 2009-05-09 Last modified: 2009-05-23
+View other active issues in [template.bitset].
+View all other issues in [template.bitset].
+View all issues with Open status.
+Discussion:
++In 853 our resolution is changing the signature by adding two +defaulting arguments to 3 calls. In principle, this means that ABI breakage +is not an issue, while API is preserved. +
++With that observation, it would be very nice to use the new ability to +supply default template parameters to function templates to collapse all 3 +signatures into 1. In that spirit, this issue offers an alternative resolution +than that of 853. +
+ +[ +Batavia (2009-05): +]
+ ++Move to Open, +and look at the issue again after 853 has been accepted. +We further recommend this be deferred until after the next Committee Draft. ++ + +Proposed resolution:
+ ++
+ + + + + + +- +
++In 20.3.6 [template.bitset]/1 (class bitset) ammend: +
++template <class charT = char, + class traits = char_traits<charT>, + class Allocator = allocator<charT>> + basic_string<charT, traits, Allocator> + to_string(charT zero = charT('0'), charT one = charT('1')) const; +template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > to_string() const; +template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > to_string() const; +basic_string<char, char_traits<char>, allocator<char> > to_string() const;+- +
++In 20.3.6.2 [bitset.members] prior to p35 ammend: +
++template <class charT = char, + class traits = char_traits<charT>, + class Allocator = allocator<charT>> + basic_string<charT, traits, Allocator> + to_string(charT zero = charT('0'), charT one = charT('1')) const; +- +Strike 20.3.6.2 [bitset.members] paragraphs 37 -> 39 (including signature +above 37) +
+
+1114. Type traits underspecified
+Section: 20.6 [meta] Status: Open + Submitter: Daniel Krügler Opened: 2009-05-12 Last modified: 2009-05-23
+View other active issues in [meta].
+View all other issues in [meta].
+View all issues with Open status.
+Discussion:
+ + + ++The current wording in 20.6.1 [meta.rqmts] is still unclear concerning +it's requirements on the type traits classes regarding ambiguities. +Specifically it's unclear +
+ ++
+ +- +if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both +true_type/false_type. +
+- +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive +from the same specified result type. +
+- +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other +integral_constant types making the contained names ambiguous +
+- +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base +classes that contain members hiding the name of the result type members +or make the contained member names ambiguous. +
+[ +Batavia (2009-05): +]
+ +++ + ++Alisdair would prefer to factor some of the repeated text, +but modulo a corner case or two, +he believes the proposed wording is otherwise substantially correct. +
++Move to Open. +
+Proposed resolution:
+[ +The usage of the notion of a BaseCharacteristic below +might be +useful in other places - e.g. to define the base class relation in +20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func]. +In this case it's definition should probably +be moved to Clause 17 +]
+ + ++
+ + + + + + +- +
++Change 20.6.1 [meta.rqmts]/1 as indicated: +
++[..] It shall be DefaultConstructible, CopyConstructible, and publicly +and unambiguously derived, directly or indirectly, from +its BaseCharacteristic, which is a specialization of the +template integral_constant (20.6.3), with the arguments to the template +integral_constant determined by the requirements for the particular +property being described. The member names of the +BaseCharacteristic shall be unhidden and unambiguously +available in the UnaryTypeTrait. ++- +
++Change 20.6.1 [meta.rqmts]/2 as indicated: +
++[..] It shall be DefaultConstructible, CopyConstructible, and publicly +and unambiguously derived, directly or indirectly, from ++an instanceits BaseCharacteristic, which is a +specialization of the template integral_constant (20.6.3), with +the arguments to the template integral_constant determined by the +requirements for the particular relationship being described. The +member names of the BaseCharacteristic shall be unhidden +and unambiguously available in the BinaryTypeTrait. +- +
++Change 20.6.4 [meta.unary]/2 as indicated: +
++Each of these templates shall be a UnaryTypeTrait (20.6.1), ++publicly derived directly or indirectly from true_type if the +corresponding condition is true, otherwise from false_type+where its BaseCharacteristic shall be true_type if the +corresponding condition is true, otherwise false_type. +- +
++Change 20.6.5 [meta.rel]/2 as indicated: +
+ ++Each of these templates shall be a BinaryTypeTrait (20.6.1), ++publicly derived directly or indirectly from true_type if the +corresponding condition is true, otherwise from false_type+where its BaseCharacteristic shall be true_type if the +corresponding condition is true, otherwise false_type. +
+1115. va_copy missing from Standard macros table
+Section: C.2 [diff.library] Status: New + Submitter: Miles Zhao Opened: 2009-05-23 Last modified: 2009-05-23
+View all other issues in [diff.library].
+View all issues with New status.
+Discussion:
++In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros +inherited from C library, va_copy seems to be missing. But in +"Table 21 -- Header <cstdarg> synopsis" (18.10 [support.runtime]), there is. +
+ + +Proposed resolution:
++Add va_copy to Table 122 -- Standard macros in C.2 [diff.library]. +
+ + + + + +
+1116. Literal constructors for tuple
+Section: 20.5.2 [tuple.tuple] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2009-05-24
+View other active issues in [tuple.tuple].
+View all other issues in [tuple.tuple].
+View all issues with New status.
+Discussion:
++It is not currently possible to construct tuple literal values, +even if the elements are all literal types. This is because parameters +are passed to constructor by reference. +
++An alternative would be to pass all constructor arguments by value, where it +is known that *all* elements are literal types. This can be determined with +concepts, although note that the negative constraint really requires +factoring out a separate concept, as there is no way to provide an 'any of +these fails' constraint inline. +
++Note that we will have similar issues with pair (and +tuple constructors from pair) although I am steering +clear of that class while other constructor-related issues settle. +
+ + +Proposed resolution:
++Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as +follows +
+ +++ ++Add the following concept: +
+ ++ +auto concept AllLiteral< typename ... Types > { + requires LiteralType<Types>...; +} ++ammend the constructor +
+ ++ +template <class... UTypes> + requires AllLiteral<Types...> + && Constructible<Types, UTypes>... + explicit tuple(UTypes...); + +template <class... UTypes> + requires !AllLiteral<Types...> + && Constructible<Types, UTypes&&>... + explicit tuple(UTypes&&...); ++ammend the constructor +
+ ++ +template <class... UTypes> + requires AllLiteral<Types...> + && Constructible<Types, UTypes>... + tuple(tuple<UTypes...>); + +template <class... UTypes> + requires !AllLiteral<Types...> + && Constructible<Types, const UTypes&>... + tuple(const tuple<UTypes...>&); ++Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5. +
+ + + + + +
+1117. tuple copy constructor
+Section: 20.5.2.1 [tuple.cnstr] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2009-05-30
+View other active issues in [tuple.cnstr].
+View all other issues in [tuple.cnstr].
+View all issues with New status.
+Discussion:
++The copy constructor for the tuple template is constrained. This seems an +unusual strategy, as the copy constructor will be implicitly deleted if the +constraints are not met. This is exactly the same effect as requesting an +=default; constructor. The advantage of the latter is that it retains +triviality, and provides support for tuples as literal types if issue +1116 is also accepted. +
++Actually, it might be worth checking with core if a constrained copy +constructor is treated as a constructor template, and as such does not +suppress the implicit generation of the copy constructor which would hide +the template in this case. +
+ +[ +2009-05-27 Daniel adds: +]
+ + ++This would solve one half of the suggested changes in 801. ++ + +Proposed resolution:
++Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4: +
+ ++ + + + + +requires CopyConstructible<Types>...tuple(const tuple&) = default; +
+1118. tuple query APIs do not support cv-qualification
+Section: 20.5.2.3 [tuple.helper] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2009-05-25
+View other active issues in [tuple.helper].
+View all other issues in [tuple.helper].
+View all issues with New status.
+Discussion:
++The APIs tuple_size and tuple_element do not support +cv-qualified tuples, pairs or arrays. +
++The most generic solution would be to supply partial specializations once +for each cv-type in the tuple header. However, requiring this header for +cv-qualified pairs/arrays seems unhelpful. The BSI editorial +suggestion (UK-198/US-69, +N2533) +to merge tuple into <utility> would help with pair, +but not array. That might be resolved by making a dependency between the +<array> header and <utility>, or simply recognising +the dependency be fulfilled in a Remark. +
+ +[ +2009-05-24 Daniel adds: +]
+ + +++ ++All tuple_size templates with a base class need to derive publicly, e.g. +
+ ++ +template <IdentityOf T> class tuple_size< const T > : + public tuple_size<T> {}; ++The same applies to the tuple_element class hierarchies. +
++What is actually meant with the comment +
++this solution relies on 'metafunction forwarding' to inherit the +nested typename type +++? +
++I ask, because all base classes are currently unconstrained and their +instantiation is invalid in the constrained context of the tuple_element partial +template specializations. +
+[ +2009-05-24 Alisdair adds: +]
+ + +++ + + ++I think a better solution might be to ask Pete editorially to change all +declarations of tupling APIs to use the struct specifier instead of class. +
++"metafunction forwarding" refers to the MPL metafunction protocol, where a +metafunction result is declared as a nested typedef with the name "type", +allowing metafunctions to be chained by means of inheritance. It is a +neater syntax than repeatedly declaring a typedef, and inheritance syntax is +slightly nicer when it comes to additional typename keywords. +
++The constrained template with an unconstrained base is a good observation +though. +
+Proposed resolution:
++Add to 20.5.1 [tuple.general] p2 (Header <tuple> synopsis) +
+ ++ +// 20.5.2.3, tuple helper classes: +template <IdentityOf T> class tuple_size; // undefined +template <IdentityOf T> class tuple_size< const T > : tuple_size<T> {}; +template <IdentityOf T> class tuple_size< volatile T > : tuple_size<T> {}; +template <IdentityOf T> class tuple_size< const volatile T > : tuple_size<T> {}; + +template <VariableType... Types> class tuple_size<tuple<Types...> >; + +template <size_t I, IdentityOf T> class tuple_element; // undefined +template <size_t I, IdentityOf T> class tuple_element<I, const T>; +template <size_t I, IdentityOf T> class tuple_element<I, volatile T>; +template <size_t I, IdentityOf T> class tuple_element<I, const volatile T>; + +template <size_t I, VariableType... Types> + requires True<(I < sizeof...(Types))> class tuple_element<I, tuple<Types...> >; ++Add to 20.5.2.3 [tuple.helper] +
+[ +(note that this solution relies on 'metafunction forwarding' to inherit the +nested typename type) +]
+ + ++ + + + + +template <class... Types> +class tuple_size<tuple<Types...> > + : public integral_constant<size_t, sizeof...(Types)> { }; + +template <size_t I, class... Types> +requires True<(I < sizeof...(Types))> +class tuple_element<I, tuple<Types...> > { +public: + typedef TI type; +}; + +template <size_t I, IdentityOf T> + class tuple_element<I, const T> : add_const<tuple_element<I,T>> {}; + +template <size_t I, IdentityOf T> + class tuple_element<I, volatile T> : add_volatile<tuple_element<I,T>> {}; + +template <size_t I, IdentityOf T> + class tuple_element<I, const volatile T> : add_cv<tuple_element<I,T>> {}; +
+1119. tuple query APIs do not support references
+Section: 20.5.2.3 [tuple.helper] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2009-05-24
+View other active issues in [tuple.helper].
+View all other issues in [tuple.helper].
+View all issues with New status.
+Discussion:
++The tuple query APIs tuple_size and +tuple_element do not support references-to-tuples. This can be +annoying when a template deduced a parameter type to be a reference, +which must be explicitly stripped with remove_reference before calling +these APIs. +
++I am not proposing a resolution at this point, as there is a +combinatorial explosion with lvalue/rvalue references and +cv-qualification (see previous issue) that suggests some higher +refactoring is in order. This might be something to kick back over to +Core/Evolution. +
++Note that we have the same problem in numeric_limits. +
+ + +Proposed resolution:
+ + + + + +
+1120. New type trait - remove_all
+Section: 20.6 [meta] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2009-05-24
+View other active issues in [meta].
+View all other issues in [meta].
+View all issues with New status.
+Discussion:
++Sometimes it is necessary to remove all qualifiers from a type before +passing on to a further API. A good example would be calling the +tuple query APIs tuple_size or tuple_element +with a deduced type inside a function template. If the deduced type is +cv-qualified or a reference then the call will fail. The solution is to +chain calls to +remove_cv<remove_reference<T>::type>::type, and +note that the order matters. +
++Suggest it would be helpful to add a new type trait, +remove_all, that removes all top-level qualifiers from a type +i.e. cv-qualification and any references. Define the term in such a way +that if additional qualifiers are added to the language, then +remove_all is defined as stripping those as well. +
+ + +Proposed resolution:
+ + + + + +
+1121. Support for multiple arguments
+Section: 20.4.2 [ratio.arithmetic] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-25 Last modified: 2009-05-25
+View other active issues in [ratio.arithmetic].
+View all other issues in [ratio.arithmetic].
+View all issues with New status.
+Discussion:
++Both add and multiply could sensibly be called with more than two arguments. +The variadic template facility makes such declarations simple, and is likely +to be frequently wrapped by end users if we do not supply the variant +ourselves. +
++We deliberately ignore divide at this point as it is not transitive. +Likewise, subtract places special meaning on the first argument so I do not +suggest extending that immediately. Both could be supported with analogous +wording to that for add/multiply below. +
++Note that the proposed resolution is potentially incompatible with that +proposed for 921, although the addition of the typedef to ratio would be +equally useful. +
+ + +Proposed resolution:
+[ +note that this wording relies on 'metafunction forwarding' as described by +Boost MPL +]
+ + ++20.4 [ratio] p3 synopsis: change +
+ ++ +// ratio arithmetic +template <class R1, class R2, class ... RList> struct ratio_add; +template <class R1, class R2> struct ratio_subtract; +template <class R1, class R2, class ... RList> struct ratio_multiply; +template <class R1, class R2> struct ratio_divide; ++20.4.2 [ratio.arithmetic] p1: change +
+ ++ + +template <class R1, class R2, class ... RList> struct ratio_add + : ratio_add< R1, ratio_add<R2, RList...>> { +}; + +template <class R1, class R2> struct ratio_add<R1, R2> { + typedef see below type; +}; ++20.4.2 [ratio.arithmetic] p3: change +
+ ++ + + + + + +template <class R1, class R2, class ... RList> struct ratio_multiply + : ratio_multiply< R1, ratio_ multiply <R2, RList...>> { +}; + +template <class R1, class R2> struct ratio_ multiply<R1, R2> { + typedef see below type; +}; +
+1122. Ratio values should be constexpr
+Section: 20.4.1 [ratio.ratio] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-25 Last modified: 2009-05-25
+View other active issues in [ratio.ratio].
+View all other issues in [ratio.ratio].
+View all issues with New status.
+Discussion:
++The values num and den in the ratio template +should be declared constexpr. +
+ + +Proposed resolution:
++20.4.1 [ratio.ratio] +
+ ++ + + + + + +namespace std { + template <intmax_t N, intmax_t D = 1> + class ratio { + public: + static constexpr intmax_t num; + static constexpr intmax_t den; + }; +} +
+1123. no requirement that standard streams be flushed
+Section: 27.5.2.1.6 [ios::Init] Status: New + Submitter: James Kanze Opened: 2009-05-14 Last modified: 2009-05-30
+View other active issues in [ios::Init].
+View all other issues in [ios::Init].
+View all issues with New status.
+Discussion:
++As currently formulated, the standard doesn't require that there +is ever a flush of cout, etc. (This implies, for example, that +the classical hello, world program may have no output.) In the +current draft +(N2798), +there is a requirement that the objects +be constructed before main, and before the dynamic +initialization of any non-local objects defined after the +inclusion of <iostream> in the same translation unit. The only +requirement that I can find concerning flushing, however, is in +27.5.2.1.6 [ios::Init], where the destructor of the last +std::ios_base::Init object flushes. But there is, as far as I +can see, no guarantee that such an object ever exists. +
++Also, the wording in [iostreams.objects] says that: +
++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. +++In 27.5.2.1.6 [ios::Init], however, as an +effect of the constructor, it says that +
++If init_cnt is zero, +the function stores the value one in init_cnt, then constructs +and initializes the objects cin, cout, cerr, clog +wcin, wcout, wcerr, and wclog" ++ ++which seems to forbid earlier +construction. +
+ ++(Note that with these changes, the exposition only "static +int init_cnt" in ios_base::Init can be dropped.) +
++Of course, a determined programmer can still inhibit the +flush with things like: +
++new std::ios_base::Init ; // never deleted ++or (in a function): +
++std::ios_base::Init ensureConstruction ; +// ... +exit( EXIT_SUCCESS ) ; ++Perhaps some words somewhere to the effect that all +std::ios_base::Init objects should have static lifetime +would be in order. +
+ + +Proposed resolution:
++Change 27.4 [iostream.objects]/2: +
+ ++-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.292 The objects are not destroyed +during program execution.293 ++ +If a translation unit includes +<iostream> 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.+The results of including <iostream> in a translation +unit shall be as if <iostream> defined an instance of +ios_base::Init with static lifetime. Similarly, the entire +program shall behave as if there were at least one instance of +ios_base::Init with static lifetime. ++Change 27.5.2.1.6 [ios::Init]/3: +
+ +++ +Init(); +++-3- Effects: Constructs an object of class Init. ++If init_cnt is zero, the function stores the value one in +init_cnt, then constructs and initializes the objects +cin, cout, cerr, clog (27.4.1), +wcin, wcout, wcerr, and wclog +(27.4.2). In any case, the function then adds one to the value stored in +init_cnt.+Constructs and initializes the objects cin, cout, +cerr, clog, wcin, wcout, +wcerr and wclog if they have not already been +constructed and initialized. ++Change 27.5.2.1.6 [ios::Init]/4: +
+ +++ + + + + + +~Init(); +++-4- Effects: Destroys an object of class Init. ++The function subtracts one from the value stored in init_cnt and, +if the resulting stored value is one,+If there are no other instances of the class still in +existance, +calls cout.flush(), +cerr.flush(), clog.flush(), wcout.flush(), +wcerr.flush(), wclog.flush(). +
+1124. Invalid definition of concept RvalueOf
+Section: 20.2.1 [concept.transform] Status: New + Submitter: Daniel Krügler Opened: 2009-05-28 Last modified: 2009-05-30
+View other active issues in [concept.transform].
+View all other issues in [concept.transform].
+View all issues with New status.
+Discussion:
++A recent news group +article +points to several defects in the +specification of reference-related concepts. +
++One problem of the concept RvalueOf as currently defined in +20.2.1 [concept.transform]: +
+ ++ +concept RvalueOf<typename T> { + typename type = T&&; + requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>; +} + +template<typename T> concept_map RvalueOf<T&> { + typedef T&& type; +} ++is that if T is an lvalue-reference, the requirement +Convertible<T&&,type> isn't satisfied for +lvalue-references, because after reference-collapsing in the concept +definition we have Convertible<T&,type> in this case, +which isn't satisfied in the concept map template and also is not the +right constraint either. I think that the reporter is right that +SameType requirements should do the job and that we also should +use the new RvalueReference concept to specify a best matching +type requirement. +
+ + +Proposed resolution:
++In 20.2.1 [concept.transform] before p. 4 change as indicated: +
+ ++ + + + + +auto concept RvalueOf<typename T> { +typenameRvalueReference type = T&&; + requiresExplicitlyConvertible<T&, type> && Convertible<T&&, type>SameType<T&, type&>; +} +
+1125. ostream_iterator does not work with movable types
+Section: 24.6.2.2 [ostream.iterator.ops] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-28 Last modified: 2009-05-30
+View all issues with New status.
+Discussion:
++ostream_iterator has not been updated to support moveable types, in a +similar manner to the insert iterators. +Note that this is not a problem for ostreambuf_iterator, as the types it is +restricted to dealing with do not support extra-efficient moving. +
+ + +Proposed resolution:
++Add second operator= overload to class template ostream_iterator +in 24.6.2 [ostream.iterator], para 2: +
+ ++ +ostream_iterator<T,charT,traits>& operator=(const T& value); +ostream_iterator<T,charT,traits>& operator=(T&& value); ++Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]: +
+ +++ + + + + + +ostream_iterator& operator=(T&& value); +++++-2- Effects: +
++*out_stream << std::move(value); +if(delim != 0) + *out_stream << delim; +return (*this); +
+1126. istreambuff_iterator::equal needs a const & parameter
+Section: 24.6.3.5 [istreambuf.iterator::equal] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-28 Last modified: 2009-05-30
+View other active issues in [istreambuf.iterator::equal].
+View all other issues in [istreambuf.iterator::equal].
+View all issues with New status.
+Discussion:
++The equal member function of istreambuf_iterator is +declared const, but takes its argument by non-const reference. +
++This is not compatible with the operator== free function overload, which is +defined in terms of calling equal yet takes both arguments by reference to +const. +
+ +[ +The proposed wording is consistent with 110 with status TC1. +]
+ + + + +Proposed resolution:
++Ammend in both:
+ +
+24.6.3 [istreambuf.iterator]
+24.6.3.5 [istreambuf.iterator::equal]
++ + + + + + +bool equal(const istreambuf_iterator& b) const; +
+1127. rvalue references and iterator traits
+Section: D.10.1 [iterator.traits] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-28 Last modified: 2009-05-30
+View all other issues in [iterator.traits].
+View all issues with New status.
+Discussion:
++The deprecated support for iterator_traits and legacy (unconstrained) +iterators features the (exposition only) concept: +
+ ++concept IsReference<typename T> { } // exposition only +template<typename T> concept_map IsReference<T&> { } ++Now this looks exactly like the LvalueReference concept recently added to +clause 20, so I wonder if we should use that instead? +Then I consider the lack of rvalue-reference support, which means that +move_iterator would always flag as merely supporting the input_iterator_tag +category. This suggests we retain the exposition concept, but add a second +concept_map to support rvalue references. +
++I would suggest adding the extra concept_map is the right way forward, but +still wonder if the two exposition-only concepts in this clause might be +worth promoting to clause 20. That question might better be answered with a +fuller investigation of type_trait/concept unification though. +
+ + +Proposed resolution:
++In Iterator traits D.10.1 [iterator.traits] para 4 add: +
+ ++ + + + + + +concept IsReference<typename T> { } // exposition only +template<typename T> concept_map IsReference<T&> { } +template<typename T> concept_map IsReference<T&&> { } +
+1128. Missing definition of iterator_traits<T*>
+Section: 24.3 [iterator.syn] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-28 Last modified: 2009-05-30
+View all issues with New status.
+Discussion:
++The <iterator> header synopsis declares a partial specialization of +iterator_traits to support pointers, 24.3 [iterator.syn]. The implication +is that specialization will be described in D10, yet it did not follow the +rest of the deprecated material into this clause. +
++However, this is not as bad as it first seems! +There are partial specializations of iterator_traits for types that satisfy +the various Iterator concepts, and there are concept_maps for pointers to +explicitly support the RandomAccessIterator concept, so the required +template will be present - just not in the manner advertised. +
++I can see two obvious solutions: +
+ ++
+- +Restore the iterator_traits<T*> partial specialization in D.10 +
+- +Remove the declaration of iterator_traits<T*> from 24.3 synopsis +
++I recommend option (ii) in the wording below +
++Option (ii) could be extended to strike all the declarations of deprecated +material from the synopsis, as it is effectively duplicating D.10 anyway. +This is the approach taken for deprecated library components in the 98/03 +standards. This is probably a matter best left to the Editor though. +
+ + +Proposed resolution:
++In 24.3 [iterator.syn] strike: +
+ ++ + + + + + +template<class T> struct iterator_traits<T*>;+
+1129. istream(buf)_iterator should support literal sentinel value
+Section: 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-30 Last modified: 2009-06-09
+View all issues with New status.
+Discussion:
++istream_iterator and istreambuf_iterator should support literal sentinel +values. The default constructor is frequently used to terminate ranges, and +could easily be a literal value for istreambuf_iterator, and +istream_iterator when iterating value types. A little more work using a +suitably sized/aligned char-array for storage (or an updated component like +boost::optional proposed for TR2) would allow istream_iterator to support +constexpr default constructor in all cases, although we might leave this +tweak as a QoI issue. Note that requiring constexpr be supported also +allows us to place no-throw guarantees on this constructor too. +
+ +[ +2009-06-02 Daniel adds: +]
+ + +++ + ++I agree with the usefulness of the issue suggestion, but we need +to ensure that istream_iterator can satisfy be literal if needed. +Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares +a copy constructor and a destructor and explains their semantic in +24.6.1.1 [istream.iterator.cons]/3+4. +
++The prototype semantic specification is ok (although it seems +somewhat redundant to me, because the semantic doesn't say +anything interesting in both cases), but for support of trivial class +types we also need a trivial copy constructor and destructor as of +9 [class]/6. The current non-informative specification of these +two special members suggests to remove their explicit declaration +in the class and add explicit wording that says that if T is +trivial a default constructed iterator is also literal, alternatively it +would be possible to mark both as defaulted and add explicit +(memberwise) wording that guarantees that they are trivial. +
++Btw.: I'm quite sure that the istreambuf_iterator additions to +ensure triviality are not sufficient as suggested, because the +library does not yet give general guarantees that a defaulted +special member declaration makes this member also trivial. +Note that e.g. the atomic types do give a general statement! +
++Finally there is a wording issue: There does not exist something +like a "literal constructor". The core language uses the term +"constexpr constructor" for this. +
++Suggestion: +
++
+- +
++Change 24.6.1 [istream.iterator]/3 as indicated: +
++constexpr istream_iterator(); +istream_iterator(istream_type& s); +istream_iterator(const istream_iterator<T,charT,traits,Distance>& x) = default; +~istream_iterator() = default; +- +
++Change 24.6.1.1 [istream.iterator.cons]/1 as indicated: +
++constexpr istream_iterator(); +++-1- Effects: Constructs the end-of-stream iterator. If T is a literal type, +then this constructor shall be a constexpr constructor. ++- +
++Change 24.6.1.1 [istream.iterator.cons]/3 as indicated: +
++istream_iterator(const istream_iterator+<T,charT,traits,Distance>& x) = default; ++-3- Effects: Constructs a copy of x. If T is a literal type, then +this constructor shall be a trivial copy constructor. ++- +
++Change 24.6.1.1 [istream.iterator.cons]/4 as indicated: +
+ ++~istream_iterator() = default; +++-4- Effects: The iterator is destroyed. If T is a literal type, then +this destructor shall be a trivial +destructor. ++- +
++Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated: +
+ ++constexpr istreambuf_iterator() throw(); +istreambuf_iterator(const istreambuf_iterator&) throw() = default; +~istreambuf_iterator() throw() = default; +- +
++Change 24.6.3 [istreambuf.iterator]/1 as indicated: +
++[..] The default constructor istreambuf_iterator() and the constructor +istreambuf_iterator(0) both +construct an end of stream iterator object suitable for use as an +end-of-range. All +specializations of istreambuf_iterator shall have a trivial copy +constructor, a constexpr default +constructor and a trivial destructor. ++Proposed resolution:
++24.6.1 [istream.iterator] para 3 +
+ ++ +constexpr istream_iterator(); ++24.6.1.1 [istream.iterator.cons] +
+ ++ +constexpr istream_iterator(); +++-1- Effects: Constructs the end-of-stream iterator. +If T is a literal type, then this constructor shall +be a literal constructor. +++24.6.3 [istreambuf.iterator] +
+ ++ +constexpr istreambuf_iterator() throw(); +
-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].
+1130. copy_exception name misleading
+Section: 18.8.5 [propagation] Status: New + Submitter: Peter Dimov Opened: 2009-05-13 Last modified: 2009-06-02
+View other active issues in [propagation].
+View all other issues in [propagation].
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>. +The naming of std::copy_exception misleads almost everyone +(experts included!) to think that it is the function that copies an +exception_ptr:
++ +exception_ptr p1 = current_exception(); +exception_ptr p2 = copy_exception( p1 ); ++But this is not at all what it does. The above actually creates an +exception_ptr p2 that contains a copy of p1, not of +the exception to which p1 refers! +
++This is, of course, all my fault; in my defence, I used copy_exception +because I was unable to think of a better name. +
++But I believe that, based on what we've seen so far, any other name would be better. +
++Therefore, I propose copy_exception to be renamed to +create_exception: +
+-template<class E> exception_ptr create_exception(E e); +Proposed resolution:
--
- +
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, -just before the member declaration +with the following explanatory paragraph after it:
-explicit discrete_distribution(const param_type& parm); ++Creates an exception_ptr that refers to a copy of e. ++ +[ +2009-05-13 Daniel adds: +]
+ + +++ ++What about +
++make_exception_ptr+in similarity to make_pair and make_tuple, make_error_code and +make_error_condition, or make_shared? Or, if a stronger symmetry to +current_exception is preferred: +
+make_exception +-insert +We have not a single create_* function in the library, it was always +make_* used.
+[ +2009-05-13 Peter adds: +]
+ -discrete_distribution(initializer_list<double> wl); ++make_exception_ptr works for me. ++ +[ +2009-06-02 Thomas J. Gritzan adds: +]
+ + +++To avoid surprises and unwanted recursion, how about making a call to +std::make_exception_ptr with an exception_ptr illegal? +
++It might work like this: +
+-template<class E> +exception_ptr make_exception_ptr(E e); +template<> +exception_ptr make_exception_ptr<exception_ptr>(exception_ptr e) = delete;+ + + - +Proposed resolution:
-Between p.4 and p.5 of the same section insert a new -paragraph as part of the new member description: +Change 18.8.5 [propagation]:
-discrete_distribution(initializer_list<double> wl); ++-template<class E> exception_ptrcopy_exceptionmake_exception_ptr(E e);-Effects: Same as discrete_distribution(wl.begin(), wl.end()). +++-11- Effects: Creates an exception_ptr that refers +to a copy of e, as if +
+ ++ +try { + throw e; +} catch(...) { + return current_exception(); +} +...
-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].
+1131. C++0x does not need alignment_of
+Section: 20.6.4.3 [meta.unary.prop] Status: New + Submitter: Niels Dekker Opened: 2009-06-01 Last modified: 2009-06-02
+View other active issues in [meta.unary.prop].
+View all other issues in [meta.unary.prop].
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. +The alignment_of template is no longer necessary, now that the +core language will provide alignof. Scott Meyers raised this +issue at comp.std.c++, +C++0x: alignof vs. alignment_of, +May 21, 2009. In a reply, Daniel Krügler pointed out that +alignof was added to the working paper after +alignment_of. So it appears that alignment_of is only +part of the current Working Draft +(N2857) +because it is in TR1. +
++Having both alignof and alignment_of would cause +unwanted confusion. In general, I think TR1 functionality should not be +brought into C++0x if it is entirely redundant with other C++0x language +or library features.
Proposed resolution:
--
- +
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, -just before the member declaration +Remove from Header <type_traits> synopsis 20.6.2 [meta.type.synop]:
- -explicit piecewise_constant_distribution(const param_type& parm); +template <class T> struct alignment_of;-insert +Remove the first row of Table 34 ("Type property queries"), from +Type properties 20.6.4.3 [meta.unary.prop]:
++-+
+Table 34 -- Type property queries ++ ++ template <class T> struct alignment_of;+ alignof(T).
+Precondition: T shall be a complete type, a reference +type, or an array of unknown bound, but shall not be a function type or +(possibly cv-qualified) void.+-template<typename Func> -piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); -+Change text in Table 41 ("Other transformations"), from Other +transformations 20.6.7 [meta.trans.other], as follows: +
++-+
+Table 41 -- Other transformations +... ++ Align shall be equal to + +alignment_of<T>::value+ alignof(T) + for some type T or to default-alignment. +... +- + + + + +
-
+1132. JP-30: nested exceptions
+Section: 18.8.6 [except.nested] Status: New + Submitter: Seiji Hayashida Opened: 2009-06-01 Last modified: 2009-06-02
+View other active issues in [except.nested].
+View all other issues in [except.nested].
+View all issues with New status.
+Discussion:
+Addresses JP 30
+ ++C++0x nested_exception cannot handle a structured exception well. The +following codes show two types of tree structured exception handling. +
++The first one is based on nested_exception in C++0x, +while the second one is based on my library trickerr.h (in Japanese). +http://tricklib.com/cxx/dagger/trickerr.h +
++Assume that Function A() calls two sub functions A_a() and A_b(), both might +throw tree structured exceptions, and A_b() must be called even if A_a() +throws an exception. +
-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: +List A (code of tree structured exception handling based on nested_exception +in C++0x)
--template<typename Func> -piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); -+void A() +{ + try + { + std::vector<exception_ptr> exception_list; + try + { + // A_a() does a similar processing as A(). + A_a(); + } + catch(...) + { + exception_list.push_back(current_exception()); + } -+ // ***The processing A() has to do even when A_a() fails. *** + try + { + // A_b() does a similar processing as A(). + A_b(); + } + catch(...) + { + exception_list.push_back(current_exception()); + } + if (!exception_list.empty()) + { + throw exception_list; + } + } + catch(...) + { + throw_with_nested(A_exception("someone error")); + } +} +void print_tree_exception(exception_ptr e, const std::string & indent ="") +{ + const char * indent_unit = " "; + const char * mark = "- "; + try + { + rethow_exception(e); + } + catch(const std::vector<exception_ptr> e) + { + for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i) + { + print_tree_exception(i, indent); + } + } + catch(const std::nested_exception e) + { + print_tree_exception(evil_i(e), indent +indent_unit); + } + catch(const std::exception e) + { + std::cout << indent << mark << e.what() << std::endl; + } + catch(...) + { + std::cout << indent << mark << "unknown exception" << std::endl; + } +} +int main(int, char * []) +{ + try + { + A(); + } + catch() + { + print_tree_exception(current_exception()); + } + return EXIT_SUCCESS; +} +-[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw. +List B ( code of tree structured exception handling based on trickerr.h. ) +"trickerr.h" (in Japanese), refer to: +http://tricklib.com/cxx/dagger/trickerr.h.
++ +void A() +{ + tricklib::error_listener_type error_listener; + // A_a() is like A(). A_a() can throw tree structured exception. + A_a(); + + // *** It must do process so that A_a() throws exception in A(). *** + // A_b() is like A(). A_b() can throw tree structured exception. + A_b(); + + if (error_listener.has_error()) // You can write this "if block" in destructor + // of class derived from error_listener_type. + { + throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error())); + } +} +void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "") +{ + const char * indent_unit = " "; + const char * mark = "- "; + + tricklib::error_type error = a_error; + while(error) + { + std::cout << indent << mark << error->message << std::endl; + if (error->children) + { + print_tree_error(error->children, indent +indent_unit); + } + error = error->next; + } +} +int main(int, char * []) +{ + tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread. + + try + { + A(); + } + catch(error_type error) + { + print_tree_error(error); + } + catch(...) + { + std::cout << "- unknown exception" << std::endl; + } + return EXIT_SUCCESS; +} ++Prospect +
-[p5_2] Requires: +We will focus on the method A() since the other methods, also main(), occur +only once respectively.
--
+- -fw shall be callable with one argument of type RealType, and shall - return values of a type convertible to double; -
+
- -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; + In the List A above (of the nested exception handling), it is hard to + find out an active reason to use the nested exception handling at this + scene. Rather, we can take a simpler description by throwing the entire + exception_list directly to the top level.
- -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. + The code in the same example gives us a kind of redundant impression, + which might have come from the fact that the try-throw-catch framework does + not assume a tree structured exception handling.
--[p5_3] Effects: +According to the above observation, we cannot help concluding that it is not +so easy to use the nested_exception handling as a tree structured exception +handling mechanism in a practical sense. +
++This text is based on the web page below (in Japanese). +http://d.hatena.ne.jp/wraith13/20081231/1230715424
--
+- -
-If nf == 0,
--
-- -lets the sequence w have length n = 1 and consist of the single - value w0 = 1, and -
-- -lets the sequence b have length n+1 with b0 = 0 and b1 = 1. -
-- -
-Otherwise,
--
-- -sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of -length n+1, and -
-- -
-lets the sequences w have length n and for each k = 0, . . . ,n-1, - calculates:
-xk = 0.5*(bk+1 + bk) -wk = fw(xk) +Proposed resolution:
++
+ + + + + +
+1133. Does N2844 break current specification of list::splice?
+Section: 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] Status: New + Submitter: Alisdair Meredith Opened: 2009-05-09 Last modified: 2009-06-09
+View other active issues in [forwardlist.ops].
+View all other issues in [forwardlist.ops].
+View all issues with New status.
+Discussion:
++IIUC, +N2844 +means that lvalues will no longer bind to rvalue references. +Therefore, the current specification of list::splice (list +operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing +programs. That is because we changed the signature to swallow via an rvalue +reference rather than the lvalue reference used in 03. +
++Retaining this form would be safer, requiring an explicit move when splicing +from lvalues. However, this will break existing programs. +We have the same problem with forward_list, although without the risk of +breaking programs so here it might be viewed as a positive feature. +
++The problem signatures: +
+-void splice_after(const_iterator position, forward_list<T,Alloc>&& x); +void splice_after(const_iterator position, forward_list<T,Alloc>&& x, + const_iterator i); +void splice_after(const_iterator position, forward_list<T,Alloc>&& x, + const_iterator first, const_iterator last); + +void splice(const_iterator position, list<T,Alloc>&& x); +void splice(const_iterator position, list<T,Alloc>&& x, + const_iterator i); +void splice(const_iterator position, list<T,Alloc>&& x, + const_iterator first, const_iterator last);- +Possible resolutions: + +
-+Option A. Add an additional (non-const) lvalue-reference +overload in each case +
++Option B. Change rvalue reference back to (non-const) +lvalue-reference overload in each case +
++Option C. Add an additional (non-const) lvalue-reference +overload in just the std::list cases +
++I think (B) would be very unfortunate, I really like the forward_list +behaviour in (C) but feel (A) is needed for consistency. +
++My actual preference would be NAD, ship with this as a breaking change as it +is a more explicit interface. I don't think that will fly though! +
+ ++See the thread starting with c++std-lib-23725 for more discussion. +
+ + +Proposed resolution:
+ + + + + +
+1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h
+Section: 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] Status: New + Submitter: Robert Klarer Opened: 2009-05-26 Last modified: 2009-06-14
+View all issues with New status.
+Discussion:
++This is probably editorial. +
++The following items should be removed from the draft, because they're +redundant with Annex D, and they arguably make some *.h headers +non-deprecated: +
++18.4.2 [stdinth] (regarding <stdint.h>) +
++26.3.2 [fenv] (regarding <fenv.h> +
++Line 3 of 26.8 [c.math] (regarding <tgmath.h>) +
++26.4.11 [cmplxh] (regarding <complex.h>, though the note in this subclause is not redundant) +
+ +[ +2009-06-10 Ganesh adds: +]
+ + ++While searching for stdint in the CD, I found that <stdint.h> is also +mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to +<cstdint> instead. ++ + +Proposed resolution:
++Remove the section 18.4.2 [stdinth]. +
++Remove the section 26.3.2 [fenv]. +
++Remove 26.8 [c.math], p3: +
+ +++-3- The header <tgmath.h> effectively includes the headers <complex.h> +and <math.h>.++Remove the section 26.4.11 [cmplxh]. +
+ + + + + +
+1135. exception_ptr should support contextual conversion to bool
+Section: 18.8.5 [propagation] Status: New + Submitter: Daniel Krügler Opened: 2007-06-06 Last modified: 2009-06-09
+View other active issues in [propagation].
+View all other issues in [propagation].
+View all issues with New status.
+Discussion:
-Constructs a piecewise_constant_distribution object with -the above computed sequence b as the interval boundaries -and with the probability densities: +As of +N2857 +18.8.5 [propagation]/5, the implementation-defined type +exception_ptr does provide the following ways to check whether +it is a null value:
-ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1. ++void f(std::exception_ptr p) { + p == nullptr; + p == 0; + p == exception_ptr(); +}+This is rather cumbersome way of checking for the null value +and I suggest to require support for evaluation in a boolean +context like so: +
-+ +void g(std::exception_ptr p) { + if (p) {} + !p; +} +Proposed resolution:
++In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6: +
+ ++ +An object e of type exception_ptr can be contextually converted to bool. +The effect shall be as if e != exception_ptr() had been evaluated in place +of e. There shall be no implicit conversion to arithmetic type, to +enumeration type or to pointer type. +-
-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].
+1136. Incomplete specification of nested_exception::rethrow_nested()
+Section: 18.8.6 [except.nested] Status: New + Submitter: Daniel Krügler Opened: 2007-06-06 Last modified: 2009-06-09
+View other active issues in [except.nested].
+View all other issues in [except.nested].
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. +It was recently mentioned in a newsgroup article +http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d +that the specification of the member function rethrow_nested() of the +class nested_exception is incomplete, specifically it remains unclear +what happens, if member nested_ptr() returns a null value. In +18.8.6 [except.nested] we find only the following paragraph related to that:
+void rethrow_nested() const; // [[noreturn]] +++-4- Throws: the stored exception captured by this nested_exception object. ++-Due to earlier support for copy-on-write, we find the following -unnecessary limitations for C++0x: +This is a problem, because it is possible to create an object of +nested_exception with exactly such a state, e.g.
+#include <exception> +#include <iostream> --
- +int main() try { + std::nested_exception e; // OK, calls current_exception() and stores it's null value + e.rethrow_nested(); // ? + std::cout << "A" << std::endl; +} +catch(...) { + std::cout << "B" << std::endl; +} +- -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. -
-- -Missing complexity guarantees: data() and c_str() simply return -a pointer to their guts, which is guaranteed O(1). This should be -spelled out. -
-- -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. -
--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. +I suggest to follow the proposal of the reporter, namely to invoke +terminate() if nested_ptr() return a null value of exception_ptr instead +of relying on the fallback position of undefined behavior. This would +be consistent to the behavior of a throw; statement when no +exception is being handled.
Proposed resolution:
--
+- -
--
-- -
-In 21.3.4 [string.capacity], just after p. 1 add a new paragraph: +
+Change around 18.8.6 [except.nested]/4 as indicated:
-Throws: Nothing. -- -- -
-In 21.3.5 [string.access] replace p. 1 by the following 4 paragraghs: +-4- Throws: the stored exception captured by this nested_exception +object, if nested_ptr() != nullptr
- -+ + + + + +-Requires: pos ≤ size(). +- Remarks: If nested_ptr() == nullptr, terminate() +shall be called.
+
+1137. Return type of conj and proj
+Section: 26.4.9 [cmplx.over] Status: New + Submitter: Marc Steinbach Opened: 2009-06-11 Last modified: 2009-06-14
+View all other issues in [cmplx.over].
+View all issues with New status.
+Discussion:
-Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns -a reference to a charT() that shall not be modified. +In clause 1, the Working Draft +(N2857) +specifies overloads of the +functions
+arg, conj, imag, norm, proj, real +-Throws: Nothing. +for non-complex arithmetic types (float, double, +long double, and integers). +The only requirement (clause 2) specifies type promotion of arguments.
-Complexity: Constant time. +I strongly suggest to add the following requirement on the return types:
++All the specified overloads must return real (i.e., non-complex) values, +specifically, the nested value_type of promoted arguments.-- -
-In 21.3.7.1 [string.accessors] replace the now common returns -clause of c_str() and data() by the following three paragraphs: +(This has no effect on arg, imag, norm, real: +they are real-valued anyway.)
-+-Rationale:
-Returns: A pointer p such that p+i == &operator[](i) for each i -in [0, size()]. -
+Mathematically, conj() and proj(), like the transcendental functions, are +complex-valued in general but map the (extended) real line to itself. +In fact, both functions act as identity on the reals. +A typical user will expect conj() and proj() to preserve this essential +mathematical property in the same way as exp(), sin(), etc. +A typical use of conj(), e.g., is the generic scalar product of n-vectors: + + +template<typename T> +inline T +scalar_product(size_t n, T const* x, T const* y) { + T result = 0; + for (size_t i = 0; i < n; ++i) + result += std::conj(x[i]) * y[i]; + return result; +} +-Throws: Nothing. +This will work equally well for real and complex floating-point types T if +conj() returns T. It will not work with real types if conj() +returns complex values.
-Complexity: Constant time. +Instead, the implementation of scalar_product becomes either less efficient +and less useful (if a complex result is always returned), or unnecessarily +complicated (if overloaded versions with proper return types are defined). +In the second case, conj() is not used with real arguments.
-- -
--
-- -
-In 21.3.5 [string.access] replace p.2 and p.3 by: +Any use of conj() I can think of would benefit from the proposed return type +requirement, in a similar way. +It will not harm use cases where a complex value is expected, because of +implicit conversion to complex. +Without the proposed return type guarantee, I find an overloaded conj() not +only useless but actually troublesome.
---Requires: pos ≤ size() +I believe that the same applies to proj(), althought up to now I had no need +for it.
+ + + +Proposed resolution:
-Throws: out_of_range if pos > size(). +Insert a new paragraph after 26.4.9 [cmplx.over]/2:
-+ +All of the specified overloads shall have a return type which is the nested value_type of +the promoted arguments. + +
-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].
+1138. unusal return value for operator+
+Section: 21.4.8.1 [string::op+] Status: New + Submitter: Alisdair Meredith Opened: 2009-06-12 Last modified: 2009-06-15
View all issues with New status.
Discussion:
-+
+Many of the basic_string operator+ overloads return an rvalue-reference. Is +that really intended? +
++I'm considering it might be a mild performance tweak to avoid making +un-necessary copies of a cheaply movable type, but it opens risk to dangling +references in code like: +
-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. +- -auto && s = string{"x"} + string{y}; ++
+and I'm not sure about: +
-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. +- -auto s = string{"x"} + string{y}; +-There are also 203 occurrences of "Throws: Nothing." scattered -throughout the spec. +
Proposed resolution:
++Strike the && from the return type in the following function +signatures: +
- -+
+-+21.3 [string.classes] p2 Header Synopsis +
-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. +-template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>-&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + const basic_string<charT,traits,Allocator>& rhs); - -+template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>
-&&+ operator+(const basic_string<charT,traits,Allocator>& lhs, + basic_string<charT,traits,Allocator>&& rhs); -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. +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + basic_string<charT,traits,Allocator>&& rhs); --For example, given the following definition of -the std::uninitialized_copy function template and a -user-defined type SomeType: +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>
-&&+ operator+(const charT* lhs, + basic_string<charT,traits,Allocator>&& rhs); ---struct SomeType { - SomeType (const SomeType&) throw (); -}template <class InputIterator, class ForwardIterator> -ForwardIterator -uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) -{ - typedef iterator_traits<ForwardIterator>::value_type ValueType; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs); - ForwardIterator start = res; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + const charT* rhs); - try { - for (; first != last; ++first, ++res) - ::new (&*res) ValueType (*first); - } - catch (...) { - for (; start != res; --start) - (&*start)->~ValueType (); - throw; - } - return res; -} +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs); ++
+21.4.8.1 [string::op+] +
-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<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>+&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + const basic_string<charT,traits,Allocator>& rhs); - ---template <> SomeType* -uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res) -{ - for (; first != last; ++first, ++res) - ::new (res) SomeType (*first); +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>-&&+ operator+(const basic_string<charT,traits,Allocator>& lhs, + basic_string<charT,traits,Allocator>&& rhs); - return res; -}+template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>
-&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + basic_string<charT,traits,Allocator>&& rhs); -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. -+template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>
-&&+ operator+(const charT* lhs, + basic_string<charT,traits,Allocator>&& rhs); -For example, given the following definitions of -class MayThrow and WontThrow and the two -statements below: +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs); ---MayThrow *a = new MayThrow [N]; -WontThrow *b = new WontThrow [N];struct MayThrow { - MayThrow (); -}; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, + const charT* rhs); -struct WontThrow { - WontThrow () throw (); -}; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator>&&+ operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs); +-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. +
+1139. Response to US 93
+Section: 30 [thread] Status: New + Submitter: Beman Dawes Opened: 2009-06-15 Last modified: 2009-06-15
+View other active issues in [thread].
+View all other issues in [thread].
+View all issues with New status.
+Discussion:
- -+
Addresses US 93, JP 79, UK 333, JP 81
-Counterarguments: ++The thread chapter is not concept enabled. +
- --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. -
--
-
- -- +
-Proposed resolution:
-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. -- -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. -
-- -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. +
-
+1140. Response to US 84
+Section: 26 [numerics] Status: New + Submitter: Beman Dawes Opened: 2009-06-15 Last modified: 2009-06-15
+View other active issues in [numerics].
+View all other issues in [numerics].
+View all issues with New status.
+Discussion:
-+
Addresses US 84
-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(...). ++The numerics chapter is not concept enabled. +
- -+
+The portion of this comment dealing with random numbers was resolved by +N2836, +which was accepted in Summit. +
-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:
- - -Proposed resolution:
--We propose two possible solutions. Our recommendation is to adopt -Option 1 below. -
--Option 1: -
-+
+1141. Response to US 85
+Section: 27 [input.output] Status: New + Submitter: Beman Dawes Opened: 2009-06-15 Last modified: 2009-06-15
+View other active issues in [input.output].
+View all other issues in [input.output].
+View all issues with New status.
+Discussion:
-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." +Addresses US 85, JP 67, JP 68, JP 69, JP 72
- -+
+The input/output chapter is not concept enabled. +
-Option 2: - --For consistency, replace all occurrences of the empty exception -specification with a "Throws: Nothing." clause. +
Proposed resolution:
+ - -
-878. forward_list preconditions
-Section: 23.2.3 [forwardlist] Status: New - Submitter: Martin Sebor Date: 2008-08-23
+1142. Response to US 86
+Section: 28 [re] Status: New + Submitter: Beman Dawes Opened: 2009-06-15 Last modified: 2009-06-15
+View other active issues in [re].
+View all other issues in [re].
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: +
Addresses US 86, UK 309, UK 310
- -+-+The regular expressions chapter is not concept enabled. +
-Requires: position is dereferenceable or equal -to before_begin(). --I believe what's actually intended is this: +
Proposed resolution:
- --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:
-+
+1143. Response to US 87
+Section: 29 [atomics] Status: New + Submitter: Beman Dawes Opened: 2009-06-15 Last modified: 2009-06-15
+View other active issues in [atomics].
+View all other issues in [atomics].
+View all issues with New status.
+Discussion:
-Change the Requires clause as follows: +Addresses US 87, UK 311
- -+- diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html index a056c3e..2f26c18 100644 --- a/libstdc++-v3/doc/html/ext/lwg-closed.html +++ b/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -14,11 +14,11 @@ del {background-color:#FFA0A0}+The atomics chapter is not concept enabled. +
+ ++Needs to also consider issues 923 and 924. +
+ + + +Proposed resolution:
-Requires: position is in the range -[before_begin(), end())dereferenceable -or equal to before_begin(). --
Doc. no. -N2729=08-0239 +N2896=09-0086 Date: -2008-08-24 +2009-06-21 Project: @@ -29,9 +29,9 @@ del {background-color:#FFA0A0}Howard Hinnant <howard.hinnant@gmail.com> C++ Standard Library Closed Issues List (Revision R59)
+C++ Standard Library Closed Issues List (Revision R65)
-Reference ISO/IEC IS 14882:1998(E)
+Reference ISO/IEC IS 14882:2003(E)
Also see:
- Table of Contents for all library issues.
@@ -51,6 +51,148 @@ del {background-color:#FFA0A0}Revision History
+
@@ -73,11 +215,11 @@ del {background-color:#FFA0A0}- R65: +2009-06-19 pre-Frankfurt mailing. +
++
+- Summary:
++
- 378 open issues, up by 32.
+- 765 closed issues, up by 0.
+- 1143 issues total, up by 32.
+- Details:
++
- Added the following New issues: 1115, 1116, 1117, 1118, 1119, 1120, 1121, 1122, 1123, 1124, 1125, 1126, 1127, 1128, 1129, 1130, 1131, 1132, 1133, 1134, 1135, 1136, 1137, 1138, 1139, 1140, 1141, 1142, 1143.
+- Added the following Open issues: 1112, 1113, 1114.
+- Changed the following issues from Pending NAD Editorial to NAD Editorial: 937.
+- Changed the following issues from New to Open: 696, 716, 727, 865, 900, 911, 916, 917, 920, 933, 935, 941, 947, 951, 953, 954, 955, 956, 977, 978, 985, 989, 996, 1033, 1054, 1056, 1057, 1059, 1062, 1068, 1069, 1071, 1072, 1076, 1090, 1092, 1096, 1098, 1099, 1105, 1106, 1108, 1110.
+- Changed the following issues from Review to Open: 817, 971, 992, 1004, 1010, 1012, 1015, 1019.
+- Changed the following issues from New to Review: 780, 835, 897, 919, 939, 957, 983, 1001, 1080, 1091, 1093, 1094, 1095, 1097, 1102, 1104, 1111.
+- Changed the following issues from Open to Review: 921, 987, 1087.
+- Changed the following issues from New to Tentatively NAD: 568, 701, 702, 785, 863, 903, 912, 918, 946, 995, 1074.
+- Changed the following issues from Open to Tentatively NAD: 458, 644, 667, 668, 669.
+- Changed the following issues from Review to Tentatively NAD: 901.
+- Changed the following issues from Tentatively Ready to Tentatively NAD: 822, 988.
+- Changed the following issues from New to Tentatively NAD Editorial: 837, 862, 867, 927, 945, 952, 969, 972, 973, 979, 1058, 1060, 1061, 1077, 1101, 1109.
+- Changed the following issues from Open to Tentatively NAD Editorial: 424, 825, 830, 884.
+- Changed the following issues from Review to Tentatively NAD Editorial: 1023.
+- Changed the following issues from Open to Tentatively NAD Future: 96.
+- Changed the following issues from New to Tentatively Ready: 810, 898, 906, 910, 913, 914, 915, 925, 974, 976, 981, 982, 984, 990, 998, 999, 1063, 1067, 1070, 1073, 1100, 1103, 1107.
+- Changed the following issues from Open to Tentatively Ready: 688, 814.
+- Changed the following issues from Review to Tentatively Ready: 899, 907, 909, 934, 938, 940, 943, 950, 965, 970, 975, 986, 991, 993, 994, 997, 1002, 1006, 1011, 1013, 1014, 1021, 1024, 1037, 1038, 1039, 1040, 1044, 1045, 1065, 1066.
+- R64: +2009-05-01 mid-term mailing. +
++
+- Summary:
++
- 346 open issues, up by 19.
+- 765 closed issues, up by 0.
+- 1111 issues total, up by 19.
+- Details:
++
- Added the following New issues: 1093, 1094, 1095, 1096, 1097, 1098, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, 1111.
+- Changed the following issues from DR to CD1: 130, 386, 406, 409, 413, 434, 438, 444, 445, 455, 457, 460, 469, 533.
+- Changed the following issues from Review to New: 1070.
+- R63: +2009-03-20 post-Summit mailing. +
++
+- Summary:
++
- 327 open issues, up by 96.
+- 765 closed issues, up by 14.
+- 1092 issues total, up by 110.
+- Details:
++
- Added the following NAD Editorial issues: 1022.
+- Added the following NAD Future issues: 1025.
+- Added the following New issues: 983, 984, 985, 989, 990, 995, 996, 998, 999, 1001, 1033, 1054, 1056, 1057, 1058, 1059, 1060, 1061, 1062, 1063, 1067, 1068, 1069, 1071, 1072, 1073, 1074, 1076, 1077, 1080, 1090, 1091, 1092.
+- Added the following Open issues: 987, 1000, 1007, 1008, 1016, 1017, 1018, 1020, 1026, 1027, 1028, 1029, 1030, 1031, 1032, 1034, 1035, 1036, 1041, 1042, 1046, 1048, 1051, 1052, 1053, 1055, 1064, 1075, 1078, 1079, 1081, 1082, 1083, 1084, 1085, 1086, 1087, 1088, 1089.
+- Added the following Review issues: 986, 991, 992, 993, 994, 997, 1002, 1003, 1004, 1005, 1006, 1009, 1010, 1011, 1012, 1013, 1014, 1015, 1019, 1021, 1023, 1024, 1037, 1038, 1039, 1040, 1043, 1044, 1045, 1047, 1049, 1050, 1065, 1066, 1070.
+- Added the following Tentatively Ready issues: 988.
+- Changed the following issues from New to Dup: 905, 942.
+- Changed the following issues from New to NAD: 980.
+- Changed the following issues from New to NAD Editorial: 874, 875.
+- Changed the following issues from Open to NAD Editorial: 732, 793, 794, 800.
+- Changed the following issues from Pending NAD Editorial to NAD Editorial: 683, 892.
+- Changed the following issues from Ready to NAD Editorial: 803.
+- Changed the following issues from NAD to Open: 466.
+- Changed the following issues from NAD Future to Open: 111, 138, 149, 219.
+- Changed the following issues from New to Open: 880, 891, 893, 902, 908, 921, 923, 924, 926, 930, 936, 944, 958, 959, 960, 961, 962, 963, 964, 966, 967, 968.
+- Changed the following issues from Ready to Open: 788.
+- Changed the following issues from New to Pending NAD Editorial: 937.
+- Changed the following issues from New to Review: 879, 899, 901, 907, 909, 929, 934, 938, 940, 943, 950, 965, 970, 971, 975.
+- Changed the following issues from Open to Review: 817.
+- Changed the following issues from New to Tentatively Ready: 904, 922, 928, 931, 932, 948, 949.
+- Changed the following issues from Open to Tentatively Ready: 890.
+- Changed the following issues from Review to Tentatively Ready: 765, 822, 853, 869, 878, 888.
+- Changed the following issues from Ready to WP: 752, 753, 758, 821, 866, 894.
+- R62: +2009-02-06 pre-Summit mailing. +
++
+- Summary:
++
- 231 open issues, up by 44.
+- 751 closed issues, up by 0.
+- 982 issues total, up by 44.
+- Details:
+- R61: +2008-12-05 mid-term mailing. + +
+- R60: +2008-10-03 post-San Francisco mailing. +
+
+- Summary:
++
- 167 open issues, down by 25.
+- 751 closed issues, up by 65.
+- 918 issues total, up by 40.
+- Details:
++
- Added the following CD1 issues: 882.
+- Added the following New issues: 879, 880, 891, 893, 897, 898, 899, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911, 912, 913, 914, 915, 916, 917, 918.
+- Added the following Open issues: 881, 883, 884, 885, 886, 887, 889, 890, 895, 896.
+- Added the following Pending NAD Editorial issues: 892.
+- Added the following Ready issues: 894.
+- Added the following Review issues: 888.
+- Changed the following issues from New to CD1: 818, 820, 843, 845, 846, 856, 858.
+- Changed the following issues from Ready to CD1: 180, 387, 396, 522, 629, 691, 713, 714, 720, 728, 762, 769, 771, 772, 776, 779, 787, 805, 806, 807, 808, 809, 813, 824, 829, 842, 844, 848, 850, 852.
+- Changed the following issues from Review to CD1: 23, 675, 692, 698, 709, 734, 804, 823.
+- Changed the following issues from WP to CD1: 44, 49, 76, 91, 92, 98, 103, 109, 117, 118, 120, 123, 136, 153, 165, 167, 171, 179, 182, 183, 184, 185, 186, 187, 198, 200, 201, 202, 206, 214, 221, 225, 226, 228, 229, 230, 231, 232, 233, 234, 235, 237, 238, 239, 240, 241, 242, 243, 247, 248, 250, 251, 252, 253, 254, 256, 258, 259, 260, 261, 262, 263, 264, 265, 266, 268, 270, 271, 272, 273, 274, 275, 276, 278, 280, 281, 282, 283, 284, 285, 286, 288, 291, 292, 294, 295, 297, 298, 300, 301, 303, 305, 306, 307, 308, 310, 311, 312, 315, 316, 317, 318, 319, 320, 321, 322, 324, 325, 327, 328, 329, 331, 333, 334, 335, 336, 337, 338, 339, 340, 341, 345, 346, 347, 349, 352, 354, 355, 358, 359, 360, 362, 363, 364, 365, 369, 370, 371, 373, 375, 376, 379, 380, 381, 383, 384, 389, 391, 395, 400, 401, 402, 403, 404, 405, 407, 410, 411, 412, 414, 415, 416, 420, 422, 425, 426, 428, 432, 435, 436, 441, 442, 443, 448, 449, 453, 456, 461, 464, 465, 467, 468, 474, 475, 478, 488, 495, 496, 497, 505, 507, 508, 518, 519, 520, 521, 524, 527, 530, 531, 534, 535, 537, 538, 540, 541, 542, 543, 545, 550, 551, 552, 559, 561, 562, 563, 566, 567, 574, 575, 576, 577, 578, 581, 586, 589, 593, 595, 596, 607, 608, 609, 610, 611, 612, 613, 616, 618, 619, 620, 621, 622, 623, 624, 628, 634, 638, 640, 643, 646, 650, 651, 652, 654, 655, 660, 661, 664, 665, 666, 672, 673, 674, 677, 678, 679, 680, 681, 682, 685, 687, 689, 693, 694, 695, 699, 700, 703, 705, 706, 710, 712, 715, 722, 740, 743, 744, 746, 749, 755, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783, 789, 792, 798.
+- Changed the following issues from Open to Dup: 670.
+- Changed the following issues from New to NAD: 849, 855, 871.
+- Changed the following issues from Open to NAD: 454, 832.
+- Changed the following issues from New to NAD Editorial: 811, 812, 841, 864, 870, 872.
+- Changed the following issues from Open to NAD Editorial: 299, 484, 556, 631, 676, 704, 724, 742.
+- Changed the following issues from Pending NAD Editorial to NAD Editorial: 532, 594, 717, 725, 738.
+- Changed the following issues from New to Open: 721, 751, 814, 816, 817, 819, 827, 836, 838, 847, 857, 859, 860, 861, 868, 873, 876, 877.
+- Changed the following issues from Pending NAD Editorial to Open: 424, 625.
+- Changed the following issues from Review to Open: 851.
+- Changed the following issues from New to Ready: 788, 821, 866.
+- Changed the following issues from Open to Ready: 753.
+- Changed the following issues from Review to Ready: 752, 758, 803.
+- Changed the following issues from New to Review: 765, 822, 853, 854, 869, 878.
+- Changed the following issues from TC to TC1: 1, 3, 5, 7, 8, 9, 11, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 46, 47, 48, 50, 51, 52, 53, 54, 55, 56, 57, 59, 60, 61, 62, 63, 64, 66, 68, 69, 70, 71, 74, 75, 78, 79, 80, 83, 86, 90, 106, 108, 110, 112, 114, 115, 119, 122, 124, 125, 126, 127, 129, 132, 133, 134, 137, 139, 141, 142, 144, 146, 147, 148, 150, 151, 152, 154, 155, 156, 158, 159, 160, 161, 164, 168, 169, 170, 172, 173, 174, 175, 176, 181, 189, 193, 195, 199, 208, 209, 210, 211, 212, 217, 220, 222, 223, 224, 227.
+- R59: 2008-08-22 pre-San Francisco mailing.
@@ -60,7 +202,7 @@ del {background-color:#FFA0A0}
- 878 issues total, up by 9.
- Details:
- 869 issues total, up by 8.
Details: @@ -91,24 +233,24 @@ del {background-color:#FFA0A0}-
- Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
+- 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.
+- Changed the following issues from WP to Ready: 387, 629.
+- Changed the following issues from Pending NAD Editorial to Review: 709.
Details: @@ -121,7 +263,7 @@ del {background-color:#FFA0A0}
- Added the following NAD issues: 840.
-- Added the following New issues: 841, 843, 845, 846, 847, 849, 853, 854, 855, 856, 857, 858, 859, 860, 861.
+- Added the following New issues: 841, 843, 845, 846, 847, 849, 853, 854, 855, 856, 857, 858, 859, 860, 861.
- Added the following Open issues: 839.
-- Added the following Ready issues: 842, 844, 848, 850, 852.
+- Added the following Ready issues: 842, 844, 848, 850, 852.
- Added the following Review issues: 851.
- Changed the following issues from New to NAD: 826.
- Changed the following issues from Open to NAD: 570.
- Changed the following issues from New to NAD Editorial: 786, 831.
- Changed the following issues from Open to NAD Editorial: 756, 767.
-- Changed the following issues from New to Open: 723, 726, 794, 815, 825, 830, 833, 834.
+- Changed the following issues from New to Open: 723, 726, 794, 815, 825, 830, 833, 834.
- Changed the following issues from Ready to Open: 471.
- Changed the following issues from Review to Open: 539, 711.
-- Changed the following issues from New to Ready: 713, 714, 769, 772, 779, 787, 805, 806, 807, 808, 809, 813, 824, 829.
-- Changed the following issues from Open to Ready: 180, 396, 522, 720, 762.
-- Changed the following issues from Review to Ready: 691, 728, 771, 776.
-- Changed the following issues from New to Review: 692, 698, 752, 804, 823, 828, 832.
-- Changed the following issues from Open to Review: 23, 675, 734, 803.
-- Changed the following issues from Ready to Review: 758.
-- Changed the following issues from Ready to WP: 387, 518, 550, 574, 595, 596, 612, 618, 629, 638, 672, 673, 685, 710, 715, 722, 740, 743, 744, 746, 749, 755, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783, 789, 792, 798.
+- Changed the following issues from New to Ready: 713, 714, 769, 772, 779, 787, 805, 806, 807, 808, 809, 813, 824, 829.
+- Changed the following issues from Open to Ready: 180, 396, 522, 720, 762.
+- Changed the following issues from Review to Ready: 691, 728, 771, 776.
+- Changed the following issues from New to Review: 692, 698, 752, 804, 823, 828, 832.
+- Changed the following issues from Open to Review: 23, 675, 734, 803.
+- Changed the following issues from Ready to Review: 758.
+- Changed the following issues from Ready to WP: 387, 518, 550, 574, 595, 596, 612, 618, 629, 638, 672, 673, 685, 710, 715, 722, 740, 743, 744, 746, 749, 755, 759, 761, 766, 768, 770, 775, 777, 778, 781, 782, 783, 789, 792, 798.
838 issues total, up by 25. Details: @@ -137,8 +279,8 @@ del {background-color:#FFA0A0}-
- Added the following New issues: 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838.
+- Added the following New issues: 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838.
- Changed the following issues from New to NAD: 802.
Details:
- Added the following Dup issues: 795.
- 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 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.
- Changed the following issues from NAD Future to Dup: 116.
- Changed the following issues from NAD Future to NAD: 188, 323.
@@ -147,15 +289,15 @@ del {background-color:#FFA0A0}- Changed the following issues from NAD Future to NAD Editorial: 140, 390.
- 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 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 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 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 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 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 Review: 711, 728, 771, 776.
+- 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.
- Changed the following issues from Tentatively Ready to WP: 527.
@@ -171,7 +313,7 @@ del {background-color:#FFA0A0}- 787 issues total, up by 23.
Details: -
- Added the following New issues: 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787.
+- Added the following New issues: 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787.
- Changed the following issues from NAD Future to Dup: 105, 348.
- Changed the following issues from NAD Future to NAD Editorial: 353.
- Changed the following issues from New to NAD Editorial: 697.
@@ -189,7 +331,7 @@ del {background-color:#FFA0A0}- 764 issues total, up by 10.
Details: @@ -204,16 +346,16 @@ del {background-color:#FFA0A0}754 issues total, up by 31. Details: -
- Added the following New issues: 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 750, 751, 752, 753, 754.
+- Added the following New issues: 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 750, 751, 752, 753, 754.
- Changed the following issues from NAD Future to Dup: 77, 350.
- Changed the following issues from New to NAD: 639, 657, 663.
- Changed the following issues from Open to NAD: 548.
-- Changed the following issues from New to Open: 546, 550, 564, 565, 573, 585, 588, 627, 629, 630, 632, 635, 653, 659, 667, 668, 669, 670, 671, 673, 686, 704, 707, 708.
+- Changed the following issues from New to Open: 546, 550, 564, 565, 573, 585, 588, 627, 629, 630, 632, 635, 653, 659, 667, 668, 669, 670, 671, 673, 686, 704, 707, 708.
- Changed the following issues from New to Pending NAD Editorial: 393, 592.
- Changed the following issues from New to Pending WP: 607, 608, 654, 655, 677, 682.
-- Changed the following issues from New to Ready: 561, 562, 563, 567, 581, 595, 620, 621, 622, 623, 624, 661, 664, 665, 666, 674, 675, 676, 679, 687, 688, 689, 693, 694, 695, 700, 703, 705, 706.
+- Changed the following issues from New to Ready: 561, 562, 563, 567, 581, 595, 620, 621, 622, 623, 624, 661, 664, 665, 666, 674, 675, 676, 679, 687, 688, 689, 693, 694, 695, 700, 703, 705, 706.
- Changed the following issues from Open to Ready: 680.
-- Changed the following issues from New to Review: 574, 596, 618, 638, 645, 672, 684, 685, 691.
+- Changed the following issues from New to Review: 574, 596, 618, 638, 645, 672, 684, 685, 691.
- Changed the following issues from New to WP: 552, 634, 650, 651, 652, 678, 681, 699, 712.
- Changed the following issues from Open to WP: 258, 401, 524.
- Changed the following issues from Ready to WP: 488, 577, 660.
@@ -229,7 +371,7 @@ del {background-color:#FFA0A0}- 723 issues total, up by 15.
Details: @@ -242,13 +384,13 @@ del {background-color:#FFA0A0}708 issues total, up by 12. Details: -
- Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
+- Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
- Changed the following issues from New to NAD: 583, 584, 662.
- Changed the following issues from Open to NAD: 528.
- Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
- Changed the following issues from Open to NAD Editorial: 525.
- Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
-- Changed the following issues from New to Open: 579, 631, 680.
+- Changed the following issues from New to Open: 579, 631, 680.
- Changed the following issues from Pending WP to Open: 258.
- Changed the following issues from Ready to Pending WP: 644.
- Changed the following issues from New to Ready: 577, 660.
@@ -269,7 +411,7 @@ del {background-color:#FFA0A0}- 696 issues total, up by 20.
Details: -
- Added the following New issues: 677, 678, 679, 680, 681, 682, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696.
+- Added the following New issues: 677, 678, 679, 680, 681, 682, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696.
- Added the following Pending NAD Editorial issues: 683.
- Changed the following issues from New to NAD Editorial: 587.
- Changed the following issues from Open to NAD Editorial: 590.
@@ -286,12 +428,12 @@ del {background-color:#FFA0A0}- 676 issues total, up by 20.
Details: -
- Added the following New issues: 657, 658, 659, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 676.
+- Added the following New issues: 657, 658, 659, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 676.
- Changed the following issues from Tentatively Ready to Dup: 479, 536.
-- Changed the following issues from Tentatively Ready to NAD: 385, 463, 466, 470, 515, 526, 547, 560, 572.
+- Changed the following issues from Tentatively Ready to NAD: 385, 463, 466, 470, 515, 526, 547, 560, 572.
- Changed the following issues from NAD to NAD Editorial: 351, 357, 368, 499, 504, 512, 513, 514, 516, 544, 549, 555, 558.
- Changed the following issues from Tentatively Ready to NAD Editorial: 482, 615.
-- Changed the following issues from NAD_Future to NAD Future: 77, 105, 111, 116, 128, 138, 140, 149, 180, 188, 190, 219, 323, 348, 350, 353, 388, 390.
+- Changed the following issues from NAD_Future to NAD Future: 77, 105, 111, 116, 128, 138, 140, 149, 180, 188, 190, 219, 323, 348, 350, 353, 388, 390.
- Changed the following issues from Tentatively Ready to Open: 471.
- Changed the following issues from New to Pending NAD Editorial: 633, 641, 656.
- Changed the following issues from Tentatively Ready to Pending NAD Editorial: 532, 553, 571, 591, 594.
@@ -313,11 +455,11 @@ del {background-color:#FFA0A0}- 656 issues total, up by 37.
Details: @@ -331,7 +473,7 @@ del {background-color:#FFA0A0}-
- 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.
+- 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 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 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.
619 issues total, up by 10. Details: @@ -347,10 +489,10 @@ 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. +Added new issues 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609. @@ -363,7 +505,7 @@ del {background-color:#FFA0A0}592 issues total, up by 5. Details: @@ -376,7 +518,7 @@ del {background-color:#FFA0A0}587 issues total, up by 13. Details: @@ -391,9 +533,9 @@ del {background-color:#FFA0A0}574 issues total, up by 8. Details: -
- Added new issues 567-572.
-- Moved issues 499, 501, 506, 509-511, 513, 514, 517 to NAD.
-- Moved issues 502, 503, 515, 516, 522, 525-529, 532, 536, 539, 548 to Open.
+- Added new issues 567, 568, 569, 570, 571, 572.
+- Moved issues 499, 501, 506, 509, 510, 511, 513, 514, 517 to NAD.
+- Moved issues 502, 503, 515, 516, 522, 525, 526, 527, 528, 529, 532, 536, 539, 548 to Open.
- Moved issue 504, 512, 521, 530, 531, 535, 537, 538, 540, 549 to Ready.
- Moved issues 247, 294, 362, 369, 371, 376, 384, 475, 478, 495, 497, 505, 507, 508, 519 to WP.
- Moved issue 534 to Review.
@@ -409,7 +551,7 @@ del {background-color:#FFA0A0}- 566 issues total, up by 31.
Details: @@ -424,7 +566,7 @@ del {background-color:#FFA0A0}535 issues total. Details: @@ -440,7 +582,7 @@ Moved issue 504-522. +Merged open TR1 issues in 504-522. Added new issues 523-523R37: @@ -449,7 +591,7 @@ Added new issues 454 were moved to "DR" status, and all issues +for 454 were moved to "DR" status, and all issues previously in "DR" status were moved to "WP". R35: @@ -497,7 +639,7 @@ Pre-Oxford mailing. Added new issues 253, which has been given a new proposed resolution, were -moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed +moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining concerns with 226 involve wording. @@ -556,7 +698,7 @@ Changed status of issues to Ready. Closed issues -111 277 279 287 +111 277 279 287 289 293 302 313 314 as NAD. @@ -582,7 +724,7 @@ issues 209, 210, 211, 212, 217, 220, 222, 223, 224, -227 to "DR". Reopened issue 23. Reopened +227 to "DR". Reopened issue 23. Reopened issue 187. Changed issues 2 and 4 to NAD. Fixed a typo in issue 17. Fixed issue 70: signature should be changed both places it @@ -635,7 +777,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99) pre-Dublin updated: Added issues 130, 131, 132, 133, 134, 135, 136, 137, -138, 139 (31 Mar 99) +138, 139 (31 Mar 99)R6: pre-Dublin mailing. Added issues 127, 128, @@ -648,7 +790,7 @@ for making list public. (30 Dec 98) R4: post-Santa Cruz II updated: Issues 110, -111, 112, 113 added, several +111, 112, 113 added, several issues corrected. (22 Oct 98) R3: @@ -669,7 +811,7 @@ format, 2. Auto_ptr conversions effects incorrect Section: D.9.1.3 [auto.ptr.conv] Status: NAD - Submitter: Nathan Myers Date: 1997-12-04
+ Submitter: Nathan Myers Opened: 1997-12-04 Last modified: 2006-12-29View all issues with NAD status.
Discussion:
Paragraph 1 in "Effects", says "Calls @@ -680,7 +822,7 @@ exists.)
Proposed resolution:
-Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from +
Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from "Calls p->release()" to "Calls p.release()".
@@ -694,15 +836,15 @@ exists.)
4. Basic_string size_type and difference_type should be implementation defined
-Section: 21.3 [basic.string] Status: NAD - Submitter: Beman Dawes Date: 1997-11-16
+Section: 21.4 [basic.string] Status: NAD + Submitter: Beman Dawes Opened: 1997-11-16 Last modified: 2006-12-27
View other active issues in [basic.string].
View all other issues in [basic.string].
View all issues with NAD status.
Discussion:
In Morristown we changed the size_type and difference_type typedefs for all the other containers to implementation defined with a -reference to 23.1 [container.requirements]. This should probably also have been +reference to 23.2 [container.requirements]. This should probably also have been done for strings.
@@ -719,8 +861,8 @@ from implementation defined.
6. File position not an offset unimplementable
-Section: 27.4.3 [fpos] Status: NAD - Submitter: Matt Austern Date: 1997-12-15
+Section: 27.5.3 [fpos] Status: NAD + Submitter: Matt Austern Opened: 1997-12-15 Last modified: 2006-12-27
View all other issues in [fpos].
View all issues with NAD status.
Discussion:
@@ -745,8 +887,8 @@ and that the above summary is what the Standard in effect says.
10. Codecvt<>::do unclear
-Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup - Submitter: Matt Austern Date: 1998-01-14
+Section: 22.4.1.5 [locale.codecvt.byname] Status: Dup + Submitter: Matt Austern Opened: 1998-01-14 Last modified: 2006-12-30
View all other issues in [locale.codecvt.byname].
View all issues with Dup status.
Duplicate of: 19
@@ -769,8 +911,8 @@ intended here.
12. Way objects hold allocators unclear
-Section: 20.1.2 [allocator.requirements] Status: NAD - Submitter: Angelika Langer Date: 1998-02-23
+Section: X [allocator.requirements] Status: NAD + Submitter: Angelika Langer Opened: 1998-02-23 Last modified: 2006-12-30
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with NAD status.
@@ -787,7 +929,7 @@ unspecified?Rationale:
Not a defect. The LWG believes that the Standard is already -clear. See 23.1 [container.requirements], paragraph 8.
+clear. See 23.2 [container.requirements], paragraph 8. @@ -795,8 +937,8 @@ clear. See 23.1 [container.requirements], paragraph 8.
43. Locale table correction
-Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup - Submitter: Brendan Kehoe Date: 1998-06-01
+Section: 22.4.1.5 [locale.codecvt.byname] Status: Dup + Submitter: Brendan Kehoe Opened: 1998-06-01 Last modified: 2006-12-30
View all other issues in [locale.codecvt.byname].
View all issues with Dup status.
Duplicate of: 33
@@ -812,14 +954,14 @@ clear. See 23.1 [container.requirements], paragraph 8.
45. Stringstreams read/write pointers initial position unclear
-Section: 27.7.3 [ostringstream] Status: NAD - Submitter: Matthias Mueller Date: 1998-05-27
+Section: 27.8.3 [ostringstream] Status: NAD + Submitter: Matthias Mueller Opened: 1998-05-27 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
In a comp.lang.c++.moderated Matthias Mueller wrote:
-"We are not sure how to interpret the CD2 (see 27.2 -[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1 +
"We are not sure how to interpret the CD2 (see 27.3 +[iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1 [stringbuf.cons]) with respect to the question as to what the correct initial positions of the write and read pointers of a stringstream should @@ -847,8 +989,8 @@ behavior is known to be different from strstreams.
58. Extracting a char from a wide-oriented stream
-Section: 27.6.1.2.3 [istream::extractors] Status: NAD - Submitter: Matt Austern Date: 1998-07-01
+Section: 27.7.1.2.3 [istream::extractors] Status: NAD + Submitter: Matt Austern Opened: 1998-07-01 Last modified: 2006-12-27
View all other issues in [istream::extractors].
View all issues with NAD status.
Discussion:
@@ -873,7 +1015,7 @@ this is the intent of the LWG.
65. Underspecification of strstreambuf::seekoff
Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD - Submitter: Matt Austern Date: 1998-08-18
+ Submitter: Matt Austern Opened: 1998-08-18 Last modified: 2006-12-27View all other issues in [depr.strstreambuf.virtuals].
View all issues with NAD status.
Discussion:
@@ -898,8 +1040,8 @@ to invest effort in this deprecated feature.
67. Setw useless for strings
-Section: 21.3.8.9 [string.io] Status: Dup - Submitter: Steve Clamage Date: 1998-07-09
+Section: 21.4.8.9 [string.io] Status: Dup + Submitter: Steve Clamage Opened: 1998-07-09 Last modified: 2006-12-30
View all other issues in [string.io].
View all issues with Dup status.
Duplicate of: 25
@@ -937,13 +1079,14 @@ parameters whatsoever.
72. Do_convert phantom member function
-Section: 22.2.1.4 [locale.codecvt] Status: Dup - Submitter: Nathan Myers Date: 1998-08-24
+Section: 22.4.1.4 [locale.codecvt] Status: Dup + Submitter: Nathan Myers Opened: 1998-08-24 Last modified: 2006-12-30
+View other active issues in [locale.codecvt].
View all other issues in [locale.codecvt].
View all issues with Dup status.
Duplicate of: 24
Discussion:
-In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function +
In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function "do_convert" is mentioned. This member was replaced with "do_in" and "do_out", the proper referents in the contexts above.
@@ -957,8 +1100,8 @@ contexts above.
73. is_open should be const
-Section: 27.8.1 [fstreams] Status: NAD - Submitter: Matt Austern Date: 1998-08-27
+Section: 27.9.1 [fstreams] Status: NAD + Submitter: Matt Austern Opened: 1998-08-27 Last modified: 2006-12-27
View all other issues in [fstreams].
View all issues with NAD status.
Discussion:
@@ -977,8 +1120,8 @@ meaningless.
77. Valarray operator[] const returning value
-Section: 26.5.2.3 [valarray.access] Status: Dup - Submitter: Levente Farkas Date: 1998-09-09
+Section: 26.6.2.3 [valarray.access] Status: Dup + Submitter: Levente Farkas Opened: 1998-09-09 Last modified: 2007-10-11
View all other issues in [valarray.access].
View all issues with Dup status.
Duplicate of: 389
@@ -1005,7 +1148,7 @@ One can't copy even from a const valarray eg:
way. That is what valarray was designed to do; that's where the "value array" name comes from. LWG members further comment that "we don't want valarray to be a full STL container." -26.5.2.3 [valarray.access] specifies properties that indicate "an +26.6.2.3 [valarray.access] specifies properties that indicate "an absence of aliasing" for non-constant arrays; this allows optimizations, including special hardware optimizations, that are not otherwise possible. @@ -1016,8 +1159,8 @@ otherwise possible.
81. Wrong declaration of slice operations
-Section: 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] Status: NAD + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-29
View all other issues in [template.slice.array].
View all issues with NAD status.
Discussion:
@@ -1043,8 +1186,9 @@ otherwise possible.
82. Missing constant for set elements
-Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 23.2.4 [associative.reqmts] Status: NAD + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2007-01-15
+View other active issues in [associative.reqmts].
View all other issues in [associative.reqmts].
View all issues with NAD status.
Discussion:
@@ -1070,8 +1214,8 @@ issue.
84. Ambiguity with string::insert()
-Section: 21.3.5 [string.access] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 21.4.5 [string.access] Status: NAD + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
If I try
@@ -1103,7 +1247,7 @@ defect in the Standard as such .
85. String char types
Section: 21 [strings] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+ Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-27View all other issues in [strings].
View all issues with NAD status.
Discussion:
@@ -1113,7 +1257,7 @@ traits::char_type?Rationale:
-There is already wording in 21.1 [char.traits] paragraph 3 that +
There is already wording in 21.2 [char.traits] paragraph 3 that requires them to be the same.
@@ -1121,8 +1265,8 @@ requires them to be the same.
87. Error in description of string::compare()
-Section: 21.3.6.8 [string::swap] Status: Dup - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 21.4.6.8 [string::swap] Status: Dup + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-30
View all other issues in [string::swap].
View all issues with Dup status.
Duplicate of: 5
@@ -1146,8 +1290,8 @@ exception)
88. Inconsistency between string::insert() and string::append()
-Section: 21.3.6.4 [string::insert], 21.3.6.2 [string::append] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 21.4.6.4 [string::insert], 21.4.6.2 [string::append] Status: NAD + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-27
View all other issues in [string::insert].
View all issues with NAD status.
Discussion:
@@ -1171,8 +1315,8 @@ serious to constitute a defect.
89. Missing throw specification for string::insert() and string::replace()
-Section: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: Dup - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] Status: Dup + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-30
View all other issues in [string::insert].
View all issues with Dup status.
Duplicate of: 83
@@ -1193,8 +1337,8 @@ of issue 93. Incomplete Valarray Subset Definitions -Section: 26.5 [numarray] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29
+Section: 26.6 [numarray] Status: NAD + Submitter: Nico Josuttis Opened: 1998-09-29 Last modified: 2006-12-29
View all other issues in [numarray].
View all issues with NAD status.
Discussion:
@@ -1230,8 +1374,8 @@ creates a temporary objects, which could be avoided without the cast.
94. May library implementors add template parameters to Standard Library classes?
-Section: 17.4.4 [conforming] Status: NAD - Submitter: Matt Austern Date: 1998-01-22
+Section: 17.6.4 [conforming] Status: NAD + Submitter: Matt Austern Opened: 1998-01-22 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
Is it a permitted extension for library implementors to add template parameters to @@ -1275,7 +1419,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.9 [res.on.exception.handling]:
+Add a new subclause [presumably 17.4.4.9] following 17.6.4.10 [res.on.exception.handling]:
17.4.4.9 Template Parameters
A specialization of a @@ -1286,7 +1430,7 @@ may be provided by a non-Standard implementation class:
Add "template parameters" to the list of subclauses at -the end of 17.4.4 [conforming] paragraph 1.
+the end of 17.6.4 [conforming] paragraph 1.[Kona: The LWG agreed the standard needs clarification. After discussion with John Spicer, it seems added template parameters can be @@ -1319,8 +1463,8 @@ of standard library class templates.
95. Members added by the implementation
-Section: 17.4.4.4 [member.functions] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 17.6.4.5 [member.functions] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual @@ -1351,7 +1495,7 @@ class vector_checking : public vector
Rationale:
This is not a defect in the Standard. The example is already -illegal. See 17.4.4.4 [member.functions] paragraph 2.
+illegal. See 17.6.4.5 [member.functions] paragraph 2. @@ -1359,7 +1503,7 @@ illegal. See 17.4.4.4 [member.functions] paragraph 2.
97. Insert inconsistent definition
Section: 23 [containers] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+ Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-27View other active issues in [containers].
View all other issues in [containers].
View all issues with NAD status.
@@ -1379,8 +1523,8 @@ the design, for better or for worse.
99. Reverse_iterator comparisons completely wrong
-Section: 24.4.1.3.13 [reverse.iter.op==] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 24.5.1.2.13 [reverse.iter.op==] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
The <, >, <=, >= comparison operator are wrong: they @@ -1401,8 +1545,10 @@ exactly what the Standard says.
100. Insert iterators/ostream_iterators overconstrained
-Section: 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 24.7 [insert.iterators], 24.6.4 [ostreambuf.iterator] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-27
+View other active issues in [insert.iterators].
+View all other issues in [insert.iterators].
View all issues with NAD status.
Discussion:
Overspecified For an insert iterator it, the expression *it is @@ -1422,8 +1568,8 @@ incorrect code to work, rather than the other way around.
101. No way to free storage for vector and deque
-Section: 23.2.6 [vector], 23.2.1 [array] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 23.3.6 [vector], 23.3.1 [array] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2007-02-19
View all other issues in [vector].
View all issues with NAD status.
Discussion:
@@ -1448,8 +1594,9 @@ expressed in a single line of code (where v is
102. Bug in insert range in associative containers
-Section: 23.1.4 [associative.reqmts] Status: Dup - Submitter: AFNOR Date: 1998-10-07
+Section: 23.2.4 [associative.reqmts] Status: Dup + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-30
+View other active issues in [associative.reqmts].
View all other issues in [associative.reqmts].
View all issues with Dup status.
Duplicate of: 264
@@ -1472,8 +1619,8 @@ container is O(1)!
104. Description of basic_string::operator[] is unclear
-Section: 21.3.4 [string.capacity] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 21.4.4 [string.capacity] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-27
View all other issues in [string.capacity].
View all issues with NAD status.
Discussion:
@@ -1495,10 +1642,10 @@ the Standard.
105. fstream ctors argument types desired
-Section: 27.8 [file.streams] Status: Dup - Submitter: AFNOR Date: 1998-10-07
+Section: 27.9 [file.streams] Status: Dup + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2008-01-05
View all issues with Dup status.
-Duplicate of: 454
+Duplicate of: 454
Discussion:
@@ -1518,8 +1665,8 @@ interesting extension for the next Standard.
107. Valarray constructor is strange
-Section: 26.5.2 [template.valarray] Status: NAD - Submitter: AFNOR Date: 1998-10-07
+Section: 26.6.2 [template.valarray] Status: NAD + Submitter: AFNOR Opened: 1998-10-07 Last modified: 2006-12-29
View all other issues in [template.valarray].
View all issues with NAD status.
Discussion:
@@ -1547,60 +1694,9 @@ perhaps other cases.
-111. istreambuf_iterator::equal overspecified, inefficient
-Section: 24.5.3.5 [istreambuf.iterator::equal] Status: NAD Future - Submitter: Nathan Myers Date: 1998-10-15
-View all issues with NAD Future status.
-Discussion:
-The member istreambuf_iterator<>::equal is specified to be -unnecessarily inefficient. While this does not affect the efficiency -of conforming implementations of iostreams, because they can -"reach into" the iterators and bypass this function, it does -affect users who use istreambuf_iterators.
- -The inefficiency results from a too-scrupulous definition, which -requires a "true" result if neither iterator is at eof. In -practice these iterators can only usefully be compared with the -"eof" value, so the extra test implied provides no benefit, -but slows down users' code.
- -The solution is to weaken the requirement on the function to return -true only if both iterators are at eof.
- - -Proposed resolution:
-Replace 24.5.3.5 [istreambuf.iterator::equal], -paragraph 1,
- --- --1- Returns: true if and only if both iterators are at end-of-stream, or neither is at - end-of-stream, regardless of what streambuf object they use.
-with
- --- - - --1- Returns: true if and only if both iterators are at - end-of-stream, regardless of what streambuf object they use.
-Rationale:
-It is not clear that this is a genuine defect. Additionally, the -LWG was reluctant to make a change that would result in -operator== not being a equivalence relation. One consequence of -this change is that an algorithm that's passed the range [i, i) -would no longer treat it as an empty range.
- - - - - -
113. Missing/extra iostream sync semantics
-Section: 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] Status: NAD - Submitter: Steve Clamage Date: 1998-10-13
+Section: 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted] Status: NAD + Submitter: Steve Clamage Opened: 1998-10-13 Last modified: 2006-12-27
View all other issues in [istream].
View all issues with NAD status.
Discussion:
@@ -1638,8 +1734,9 @@ desired functionality.
116. bitset cannot be constructed with a const char*
-Section: 23.3.5 [template.bitset] Status: Dup - Submitter: Judy Ward Date: 1998-11-06
+Section: 20.3.6 [template.bitset] Status: Dup + Submitter: Judy Ward Opened: 1998-11-06 Last modified: 2008-03-14
+View other active issues in [template.bitset].
View all other issues in [template.bitset].
View all issues with Dup status.
Duplicate of: 778
@@ -1683,13 +1780,13 @@ longer work.Proposed resolution:
-Add to 23.3.5 [template.bitset] a bitset constructor declaration
+Add to 20.3.6 [template.bitset] a bitset constructor declaration
-explicit bitset(const char*);and in Section 23.3.5.1 [bitset.cons] add:
+and in Section 20.3.6.1 [bitset.cons] add:
explicit bitset(const char* str);@@ -1710,15 +1807,15 @@ extension.
121. Detailed definition for ctype<wchar_t> specialization
-Section: 22.1.1.1.1 [locale.category] Status: NAD - Submitter: Judy Ward Date: 1998-12-15
+Section: 22.3.1.1.1 [locale.category] Status: NAD + Submitter: Judy Ward Opened: 1998-12-15 Last modified: 2006-12-27
View all other issues in [locale.category].
View all issues with NAD status.
Discussion:
Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , ctype<wchar_t>.
-Also Section 22.2.1.1 [locale.ctype] says:
+Also Section 22.4.1.1 [locale.ctype] says:
-The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and @@ -1726,14 +1823,14 @@ ctype<wchar_t>.
native character set.However, Section 22.2.1.3 [facet.ctype.special] +
However, Section 22.4.1.3 [facet.ctype.special] only has a detailed description of the ctype<char> specialization, not the ctype<wchar_t> specialization.
Proposed resolution:
Add the ctype<wchar_t> detailed class description to Section -22.2.1.3 [facet.ctype.special].
+22.4.1.3 [facet.ctype.special].Rationale:
@@ -1745,8 +1842,8 @@ ctype<wchar_t> specialization.
131. list::splice throws nothing
-Section: 23.2.4.4 [list.ops] Status: NAD - Submitter: Howard Hinnant Date: 1999-03-06
+Section: 23.3.4.4 [list.ops] Status: NAD + Submitter: Howard Hinnant Opened: 1999-03-06 Last modified: 2007-02-19
View all other issues in [list.ops].
View all issues with NAD status.
Discussion:
@@ -1763,8 +1860,8 @@ beyond max_size()?
135. basic_iostream doubly initialized
-Section: 27.6.1.5.1 [iostream.cons] Status: NAD - Submitter: Howard Hinnant Date: 1999-03-06
+Section: 27.7.1.5.1 [iostream.cons] Status: NAD + Submitter: Howard Hinnant Opened: 1999-03-06 Last modified: 2006-12-27
View all issues with NAD status.
Discussion:
-1- Effects Constructs an object of class basic_iostream, assigning @@ -1794,51 +1891,14 @@ standard.
-138. Class ctype_byname<char> redundant and misleading
-Section: 22.2.1.4 [locale.codecvt] Status: NAD Future - Submitter: Angelika Langer Date: 1999-03-18
-View all other issues in [locale.codecvt].
-View all issues with NAD Future status.
-Discussion:
-Section 22.2.1.4 [locale.codecvt] specifies that -ctype_byname<char> must be a specialization of the ctype_byname -template.
- -It is common practice in the standard that specializations of class templates are only -mentioned where the interface of the specialization deviates from the interface of the -template that it is a specialization of. Otherwise, the fact whether or not a required -instantiation is an actual instantiation or a specialization is left open as an -implementation detail.
- -Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The -fact, that ctype_byname<char> is specified as a specialization suggests that there -must be something "special" about it, but it has the exact same interface as the -ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best -redundant, at worst misleading - unless I am missing anything.
- -Naturally, an implementation will most likely implement ctype_byname<char> as a -specialization, because the base class ctype<char> is a specialization with an -interface different from the ctype template, but that's an implementation detail and need -not be mentioned in the standard.
- - -Rationale:
-The standard as written is mildly misleading, but the correct fix -is to deal with the underlying problem in the ctype_byname base class, -not in the specialization. See issue 228.
- - - - -
140. map<Key, T>::value_type does not satisfy the assignable requirement
-Section: 23.3.1 [map] Status: NAD Editorial - Submitter: Mark Mitchell Date: 1999-04-14
+Section: 23.4.1 [map] Status: NAD Editorial + Submitter: Mark Mitchell Opened: 1999-04-14 Last modified: 2008-03-14
View all other issues in [map].
View all issues with NAD Editorial status.
Discussion:
-23.1 [container.requirements]
+23.2 [container.requirements]
expression return type pre/post-condition
@@ -1848,7 +1908,7 @@ not in the specialization. See issue 143. C .h header wording unclearSection: D.5 [depr.c.headers] Status: NAD - Submitter: Christophe de Dinechin Date: 1999-05-04
+ Submitter: Christophe de Dinechin Opened: 1999-05-04 Last modified: 2006-12-27View all issues with NAD status.
Discussion:
[depr.c.headers] paragraph 2 reads:
@@ -1987,8 +2047,8 @@ write code that depends on Koenig lookup of C library functions.
145. adjustfield lacks default value
-Section: 27.4.4.1 [basic.ios.cons] Status: NAD - Submitter: Angelika Langer Date: 1999-05-12
+Section: 27.5.4.1 [basic.ios.cons] Status: NAD + Submitter: Angelika Langer Opened: 1999-05-12 Last modified: 2006-12-27
View all other issues in [basic.ios.cons].
View all issues with NAD status.
Discussion:
@@ -2014,93 +2074,20 @@ everybody expects anyway.Rationale:
This is not a defect. It is deliberate that the default is no bits -set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
- - - - -
-149. Insert should return iterator to first element inserted
-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.
-Discussion:
-Suppose that c and c1 are sequential containers and i is an -iterator that refers to an element of c. Then I can insert a copy of -c1's elements into c ahead of element i by executing
- -- -- -c.insert(i, c1.begin(), c1.end());- -If c is a vector, it is fairly easy for me to find out where the -newly inserted elements are, even though i is now invalid:
- -- -- -size_t i_loc = i - c.begin(); -c.insert(i, c1.begin(), c1.end());- -and now the first inserted element is at c.begin()+i_loc and one -past the last is at c.begin()+i_loc+c1.size().
- -
-
-But what if c is a list? I can still find the location of one past the -last inserted element, because i is still valid. To find the location -of the first inserted element, though, I must execute something like- -- -for (size_t n = c1.size(); n; --n) - --i;- -because i is now no longer a random-access iterator.
- -
-
-Alternatively, I might write something like- -- -bool first = i == c.begin(); -list<T>::iterator j = i; -if (!first) --j; -c.insert(i, c1.begin(), c1.end()); -if (first) - j = c.begin(); -else - ++j;- -which, although wretched, requires less overhead.
- - -
-
-But I think the right solution is to change the definition of insert -so that instead of returning void, it returns an iterator that refers -to the first element inserted, if any, and otherwise is a copy of its -first argument.Rationale:
-The LWG believes this was an intentional design decision and so is -not a defect. It may be worth revisiting for the next standard.
+set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
157. Meaningless error handling for pword() and iword()
-Section: 27.4.2.5 [ios.base.storage] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20
+Section: 27.5.2.5 [ios.base.storage] Status: Dup + Submitter: Dietmar Kühl Opened: 1999-07-20 Last modified: 2007-01-15
View all other issues in [ios.base.storage].
View all issues with Dup status.
Duplicate of: 41
Discussion:
-According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the +
According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the functions iword() and pword() "set the badbit (which might throw an exception)" on failure. ... but what does it mean for ios_base to set the @@ -2118,8 +2105,8 @@ character type used...
162. Really "formatted input functions"?
-Section: 27.6.1.2.3 [istream::extractors] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20
+Section: 27.7.1.2.3 [istream::extractors] Status: Dup + Submitter: Dietmar Kühl Opened: 1999-07-20 Last modified: 2007-01-15
View all other issues in [istream::extractors].
View all issues with Dup status.
Duplicate of: 60
@@ -2129,7 +2116,7 @@ defined in the paragraphs 1 to 5 to be "Formatted input function" but since these functions are defined in a section labeled "Formatted input functions" it is unclear to me whether these operators are considered formatted input functions which -have to conform to the "common requirements" from 27.6.1.2.1 +have to conform to the "common requirements" from 27.7.1.2.1 [istream.formatted.reqmts]: If this is the case, all manipulators, not just ws, would skip whitespace unless noskipws is set @@ -2148,14 +2135,14 @@ output
163. Return of gcount() after a call to gcount
-Section: 27.6.1.3 [istream.unformatted] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20
+Section: 27.7.1.3 [istream.unformatted] Status: Dup + Submitter: Dietmar Kühl Opened: 1999-07-20 Last modified: 2007-01-15
View all other issues in [istream.unformatted].
View all issues with Dup status.
Duplicate of: 60
Discussion:
It is not clear which functions are to be considered unformatted -input functions. As written, it seems that all functions in 27.6.1.3 +input functions. As written, it seems that all functions in 27.7.1.3 [istream.unformatted] are unformatted input functions. However, it does not really make much sense to construct a sentry object for @@ -2183,13 +2170,13 @@ clarification should be used.
166. Really "formatted output functions"?
-Section: 27.6.2.6.3 [ostream.inserters] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20
+Section: 27.7.2.6.3 [ostream.inserters] Status: Dup + Submitter: Dietmar Kühl Opened: 1999-07-20 Last modified: 2007-01-15
View all issues with Dup status.
Duplicate of: 60
Discussion:
-From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions -defined in 27.6.2.6.3 [ostream.inserters] have to construct a +
From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions +defined in 27.7.2.6.3 [ostream.inserters] have to construct a sentry object. Is this really intended?
This is basically the same problem as issue 162 but @@ -2204,8 +2191,8 @@ for output instead of input.
177. Complex operators cannot be explicitly instantiated
-Section: 26.3.6 [complex.ops] Status: NAD - Submitter: Judy Ward Date: 1999-07-02
+Section: 26.4.6 [complex.ops] Status: NAD + Submitter: Judy Ward Opened: 1999-07-02 Last modified: 2006-12-27
View all other issues in [complex.ops].
View all issues with NAD status.
Discussion:
@@ -2261,8 +2248,8 @@ syntax.
178. Should clog and cerr initially be tied to cout?
-Section: 27.3.1 [narrow.stream.objects] Status: NAD - Submitter: Judy Ward Date: 1999-07-02
+Section: 27.4.1 [narrow.stream.objects] Status: NAD + Submitter: Judy Ward Opened: 1999-07-02 Last modified: 2006-12-27
View all other issues in [narrow.stream.objects].
View all issues with NAD status.
Discussion:
@@ -2294,8 +2281,8 @@ ios_base::init to basic_ios::init().)
188. valarray helpers missing augmented assignment operators
-Section: 26.5.2.6 [valarray.cassign] Status: NAD - Submitter: Gabriel Dos Reis Date: 1999-08-15
+Section: 26.6.2.6 [valarray.cassign] Status: NAD + Submitter: Gabriel Dos Reis Opened: 1999-08-15 Last modified: 2008-03-11
View all issues with NAD status.
Discussion:
26.5.2.6 defines augmented assignment operators @@ -2331,8 +2318,8 @@ operators.
191. Unclear complexity for algorithms such as binary search
-Section: 25.3.3 [alg.binary.search] Status: NAD - Submitter: Nico Josuttis Date: 1999-10-10
+Section: 25.5.3 [alg.binary.search] Status: NAD + Submitter: Nico Josuttis Opened: 1999-10-10 Last modified: 2006-12-27
View all other issues in [alg.binary.search].
View all issues with NAD status.
Discussion:
@@ -2360,8 +2347,9 @@ iterators.
192. a.insert(p,t) is inefficient and overconstrained
-Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Ed Brey Date: 1999-06-06
+Section: 23.2.4 [associative.reqmts] Status: NAD + Submitter: Ed Brey Opened: 1999-06-06 Last modified: 2006-12-30
+View other active issues in [associative.reqmts].
View all other issues in [associative.reqmts].
View all issues with NAD status.
Duplicate of: 233
@@ -2406,7 +2394,7 @@ providing no disadvantage to the container implementation.Proposed resolution:
-In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 +
In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69 for a.insert(p,t) with the following two rows: