| Doc. no. | N3011=09-0201 |
| Date: | 2009-11-08 |
| Project: | Programming Language C++ |
| Reply to: | Howard Hinnant <howard.hinnant@gmail.com> |
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:2003(E) document.
This document contains only library issues which are actively being considered by the Library Working Group, i.e., issues which have a status of New, Open, Ready, or Review. See Library Defect Reports List for issues considered defects and Library Closed Issues List for issues considered closed.
The issues in these lists are not necessarily formal ISO Defect Reports (DR's). While some issues will eventually be elevated to official Defect Report status, other issues will be disposed of in other ways. See Issue Status.
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 into a single version.
This document includes [bracketed italicized notes] as a reminder to the LWG of current progress on issues. Such notes are strictly unofficial and should be read with caution as they may be incomplete or incorrect. Be aware that LWG support for a particular resolution can quickly change if new viewpoints or killer examples are presented in subsequent discussions.
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: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.
New - The issue has not yet been reviewed by the LWG. Any Proposed Resolution is purely a suggestion from the issue submitter, and should not be construed as the view of LWG.
Open - The LWG has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:
A Proposed Resolution for an open issue is still not be construed as the view of LWG. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.
Dup - The LWG has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.
NAD - The LWG has reached consensus that the issue is not a defect in the Standard.
NAD Editorial - The LWG has reached consensus that the issue can either be handled editorially, or is handled by a paper (usually linked to in the rationale).
NAD Concepts - The LWG has reached consensus that the issue is NAD for now, but represents a real issue when the library is done with language-supported concepts.
NAD Future - In addition to the regular status, the LWG believes that this issue should be revisited at the next revision of the standard.
Review - Exact wording of a Proposed Resolution is now available for review on an issue for which the LWG previously reached informal consensus.
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 full committee for further action as a Defect Report (DR).
DR - (Defect Report) - The full J16 committee has voted to forward the issue to the Project Editor to be processed as a Potential Defect Report. The Project Editor reviews the issue, and then forwards it to the WG21 Convenor, who returns it to the full committee for final disposition. This issues list accords the status of DR to all these Defect Reports regardless of where they are in that process.
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 complete and no further action is expected.
WP - (Working Paper) - The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.
Tentatively - This is a status qualifier. The issue has been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed for the qualified status. Tentatively qualified issues may be moved to the unqualified status and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues will be reviewed in subcommittee prior to forwarding to full committee. When a status is qualified with Tentatively, the issue is still considered active.
Pending - This is a status qualifier. When prepended to a status this indicates the issue has been processed by the committee, and a decision has been made to move the issue to the associated unqualified status. However for logistical reasons the indicated outcome of the issue has not yet appeared in the latest working paper.
Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the LWG is actively working on them. When the LWG has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready as appropriate. Once the full J16 committee votes to forward Ready issues to the Project Editor, they are given the status of Defect Report ( DR). These in turn may become the basis for Technical Corrigenda (TC), or are closed without action other than a Record of Response (RR ). The intent of this LWG process is that only issues which are truly defects in the Standard move to the formal ISO DR status.
Section: 20.3.4 [pairs] Status: Ready Submitter: Martin Sebor Opened: 2001-01-14 Last modified: 2009-10-26
View other active issues in [pairs].
View all other issues in [pairs].
View all issues with Ready status.
Discussion:
The synopsis of the header <utility> in 20.3 [utility] lists the complete set of equality and relational operators for pair but the section describing the template and the operators only describes operator==() and operator<(), and it fails to mention any requirements on the template arguments. The remaining operators are not mentioned at all.
[ 2009-09-27 Alisdair reopens. ]
The issue is a lack of wording specifying the semantics of std::pair relational operators. The rationale is that this is covered by catch-all wording in the relops component, and that as relops directly precedes pair in the document this is an easy connection to make.
Reading the current working paper I make two observations:
- relops no longer immediately precedes pair in the order of specification. However, even if it did, there is a lot of pair specification itself between the (apparently) unrelated relops and the relational operators for pair. (The catch-all still requires operator== and operator< to be specified explicitly)
- No other library component relies on the catch-all clause. The following all explicitly document all six relational operators, usually in a manner that could have deferred to the relops clause.
tuple unique_ptr duration time_point basic_string queue stack move_iterator reverse_iterator regex submatch thread::idThe container components provide their own (equivalent) definition in 23.2.1 [container.requirements.general] Table 90 -- Container requirements and do so do not defer to relops.
Shared_ptr explicitly documents operator!= and does not supply the other 3 missing operators (>,>=,<=) so does not meet the reqirements of the relops clause.
Weak_ptr only supports operator< so would not be covered by relops.
At the very least I would request a note pointing to the relops clause we rely on to provide this definition. If this route is taken, I would recommend reducing many of the above listed clauses to a similar note rather than providing redundant specification.
My preference would be to supply the 4 missing specifications consistent with the rest of the library.
[ 2009-10-11 Daniel opens 1233 which deals with the same issue as it pertains to unique_ptr. ]
[ 2009-10 Santa Cruz: ]
Move to Ready
Proposed resolution:
After p20 20.3.4 [pairs] add:
template <class T1, class T2> bool operator!=(const pair<T1,T2>& x, const pair<T1,T2>& y);Returns: !(x==y)template <class T1, class T2> bool operator> (const pair<T1,T2>& x, const pair<T1,T2>& y);Returns: y < xtemplate <class T1, class T2> bool operator>=(const pair<T1,T2>& x, const pair<T1,T2>& y);Returns: !(x < y)template <class T1, class T2> bool operator<=(const pair<T1,T2>& x, const pair<T1,T2>& y);Returns: !(y < x)
Rationale:
20.3.1 [operators] paragraph 10 already specifies the semantics. That paragraph says that, if declarations of operator!=, operator>, operator<=, and operator>= appear without definitions, they are defined as specified in 20.3.1 [operators]. There should be no user confusion, since that paragraph happens to immediately precede the specification of pair.
Section: 24.2.4 [bidirectional.iterators], 24.2.5 [random.access.iterators] Status: Open Submitter: John Potter Opened: 2001-01-22 Last modified: 2009-10-26
View all other issues in [bidirectional.iterators].
View all issues with Open status.
Discussion:
In section 24.2.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.
In section 24.2.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.
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.
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.
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.
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).
Note that the compromise resolution necessitates a change to reverse_iterator. It would need to use a proxy to support a[n] = t.
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.
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-09-18 Alisdair adds: ]
Why can't we write through the reference returned from operator[] on a random access iterator?
Recommended solution:
In table Table 104 -- Random access iterator requirements, replace
a[n] : convertible toconst T &T& if X is mutable, otherwise convertible to const T&
[ 2009-10 Santa Cruz: ]
Leave Open. Alisdair to spearhead a paper on revivification.
Proposed resolution:
In section 24.1.4 [lib.bidirectdional.iterators], change the return type in table 75 from "convertible to T" to T&.
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.
[Lillehammer: Real problem, but should be addressed as part of iterator redesign]
Rationale:
[ San Francisco: ]
Solved by N2758.
Section: 27.7.2.4 [ostream::sentry] Status: Open Submitter: Martin Sebor Opened: 2003-01-05 Last modified: 2009-10-20
View all other issues in [ostream::sentry].
View all issues with Open status.
Discussion:
17.4.4.8, p3 prohibits library dtors from throwing exceptions.
27.6.2.3, p4 says this about the ostream::sentry dtor:
-4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
is true, calls os.flush().
27.6.2.6, p7 that describes ostream::flush() says:
-7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
If that function returns ?-1 calls setstate(badbit) (which
may throw ios_base::failure (27.4.4.3)).
That seems like a defect, since both pubsync() and setstate() can throw an exception.
[ The contradiction is real. Clause 17 says destructors may never throw exceptions, and clause 27 specifies a destructor that does throw. In principle we might change either one. We're leaning toward changing clause 17: putting in an "unless otherwise specified" clause, and then putting in a footnote saying the sentry destructor is the only one that can throw. PJP suggests specifying that sentry::~sentry() should internally catch any exceptions it might cause. ]
[ See 418 and 622 for related issues. ]
[ 2009-07 Frankfurt ]
Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~sentry().
[ 2009-10-13 Daniel adds: ]
The proposed resolution of 835 is written to match the outcome of this issue.
[ 2009 Santa Cruz: ]
Move to Open. Our intent is to solve this issue with 835.
Proposed resolution:
Add after 27.7.2.4 [ostream::sentry] p17:
~sentry();-17- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception()) is true, calls os.flush().
Throws: Nothing.
Section: 24.2 [iterator.requirements] Status: Open Submitter: Nathan Myers Opened: 2003-06-03 Last modified: 2009-11-03
View other active issues in [iterator.requirements].
View all other issues in [iterator.requirements].
View all issues with Open status.
Discussion:
I've been discussing iterator semantics with Dave Abrahams, and a surprise has popped up. I don't think this has been discussed before.
X [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 to initialize the data member of a reverse_iterator<> in the default constructor. As a result, code like
std::vector<std::reverse_iterator<char*> > v(7); v.reserve(1000);
invokes undefined behavior, because it must default-initialize the vector elements, and then copy them to other storage. Of course many other vector operations on these adapters are also left undefined, and which those are is not reliably deducible from the standard.
I don't think that 24.1 was meant to make standard-library iterator types unsafe. Rather, it was meant to restrict what operations may be performed by functions which take general user- and standard iterators as arguments, so that raw pointers would qualify as iterators. However, this is not clear in the text, others have come to the opposite conclusion.
One question is whether the standard iterator adaptors have defined copy semantics. Another is whether they have defined destructor semantics: is
{ std::vector<std::reverse_iterator<char*> > v(7); }
undefined too?
Note this is not a question of whether algorithms are allowed to rely on copy semantics for arbitrary iterators, just whether the types we actually supply support those operations. I believe the resolution must be expressed in terms of the semantics of the adapter's argument type. It should make clear that, e.g., the reverse_iterator<T> constructor is actually required to execute T(), and so copying is defined if the result of T() is copyable.
Issue 235, which defines reverse_iterator's default constructor more precisely, has some relevance to this issue. However, it is not the whole story.
The issue was whether
reverse_iterator() { }
is allowed, vs.
reverse_iterator() : current() { }
The difference is when T is char*, where the first leaves the member uninitialized, and possibly equal to an existing pointer value, or (on some targets) may result in a hardware trap when copied.
8.5 paragraph 5 seems to make clear that the second is required to satisfy DR 235, at least for non-class Iterator argument types.
But that only takes care of reverse_iterator, and doesn't establish a policy for all iterators. (The reverse iterator adapter was just an example.) In particular, does my function
template <typename Iterator>
void f() { std::vector<Iterator> v(7); }
evoke undefined behavior for some conforming iterator definitions? I think it does, now, because vector<> will destroy those singular iterator values, and that's explicitly disallowed.
24.1 shouldn't give blanket permission to copy all singular iterators, because then pointers wouldn't qualify as iterators. However, it should allow copying of that subset of singular iterator values that are default-initialized, and it should explicitly allow destroying any iterator value, singular or not, default-initialized or not.
[ We don't want to require all singular iterators to be copyable, because that is not the case for pointers. However, default construction may be a special case. Issue: is it really default construction we want to talk about, or is it something like value initialization? We need to check with core to see whether default constructed pointers are required to be copyable; if not, it would be 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).
[ 2009-07 Frankfurt ]
This is related to LWG 1012.
Note that there is a bug in the proposed resolution to LWG 1012. The change to [reverse.iter.con] should be modified so that the word "default" in the second sentence of the Effects clause is replaced by "value."
We believe that the proposed fix to LWG 1012 (now corrected) is sufficient to solve the problem for reverse_iterator. However, Alisdair pointed out that LWG 1012 does not solve the general problem for authors of iterator adaptors.
There are some problems with the proposed resolution. The phrase "safely copyable" is not a term of art. Also, it mentions a DefaultConstructible? concept.
Move to Review after Alisdair updates the wording.
[ 2009-07-31 Alisdair revised wording: ]
[ 2009-08-17 Alisdair and Daniel collaborate on slightly revised wording. This issue depends upon 724 ]
[ 2009-10-14 Daniel adds: ]
There is a clear dependency on 1213, because the term "singular", which is used as part of the resolution, is not properly defined yet.
[ 2009-10 Santa Cruz: ]
Moved to Open. Alisdair will provide improved wording to make this have "value semantics" and otherwise behave like a valid iterator.
Proposed resolution:
Add a new paragrpah to Iterator concepts 24.2 [iterator.requirements] after para 5 (the one describing singular iterators)
Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding container. These values are called past-the-end values. Values of an iterator i for which the expression *i is defined are called dereferenceable. The library never assumes that past-the-end values are dereferenceable. Iterators can also have singular values that are not associated with any container. [Example: After the declaration of an uninitialized pointer x (as with int* x;), x must always be assumed to have a singular value of a pointer. — end example] Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value and the assignment of a non-singular value to an iterator that holds a singular value. In this case the singular value is overwritten the same way as any other value. Dereferenceable values are always non-singular.
After value-initialization, any iterator that satisfies the DefaultConstructible requirements ([defaultconstructible]) shall not introduce undefined behaviour when used as the source of a copy or move operation, 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]
Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Open Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-10-26
View other active issues in [facet.num.get.virtuals].
View all other issues in [facet.num.get.virtuals].
View all issues with Open status.
Discussion:
The requirements specified in Stage 2 and reiterated in the rationale of DR 221 (and echoed again in DR 303) specify that num_get<charT>:: do_get() compares characters on the stream against the widened elements of "012...abc...ABCX+-"
An implementation is required to allow programs to instantiate the num_get template on any charT that satisfies the requirements on a user-defined character type. These requirements do not include the ability of the character type to be equality comparable (the char_traits template must be used to perform tests for equality). Hence, the num_get template cannot be implemented to support any arbitrary character type. The num_get template must either make the assumption that the character type is equality-comparable (as some popular implementations do), or it may use char_traits<charT> to do the comparisons (some other popular implementations do that). This diversity of approaches makes it difficult to write portable programs that attempt to instantiate the num_get template on user-defined types.
[Kona: the heart of the problem is that we're theoretically supposed to use traits classes for all fundamental character operations like assignment and comparison, but facets don't have traits parameters. This is a fundamental design flaw and it appears all over the place, not just in this one place. It's not clear what the correct solution is, but a thorough review of facets and traits is in order. The LWG considered and rejected the possibility of changing numeric facets to use narrowing instead of widening. This may be a good idea for other reasons (see issue 459), but it doesn't solve the problem raised by this issue. Whether we use widen or narrow the num_get facet still has no idea which traits class the user wants to use for the comparison, because only streams, not facets, are passed traits classes. The standard does not require that two different traits classes with the same char_type must necessarily have the same behavior.]
Informally, one possibility: require that some of the basic character operations, such as eq, lt, and assign, must behave the same way for all traits classes with the same char_type. If we accept that limitation on traits classes, then the facet could reasonably be required to use char_traits<charT>.
[ 2009-07 Frankfurt ]
There was general agreement that the standard only needs to specify the behavior when the character type is char or wchar_t.
Beman: we don't need to worry about C++1x because there is a non-zero possibility that we would have a replacement facility for iostreams that would solve these problems.
We need to change the following sentence in [locale.category], paragraph 6 to specify that C is char and wchar_t:
"A template formal parameter with name C represents the set of all possible specializations on a parameter that satisfies the requirements for a character on which any member of the iostream components can be instantiated."
We also need to specify in 27 that the basic character operations, such as eq, lt, and assign use std::char_traits.
Daniel volunteered to provide wording.
[ 2009-09-19 Daniel provided wording. ]
[ 2009-10 Santa Cruz: ]
Leave as Open. Alisdair and/or Tom will provide wording based on discussions. We want to clearly state that streams and locales work just on char and wchar_t (except where otherwise specified).
Proposed resolution:
Change 22.3.1.1.1 [locale.category]/6:
[..] A template formal parameter with name C represents the set of all possible specializations on a char or wchar_t parameterthat satisfies the requirements for a character on which any of the iostream components can be instantiated. [..]
Add the following sentence to the end of 22.4.2 [category.numeric]/2:
[..] These specializations refer to [..], and also for the ctype<> facet to perform character classification. Implementations are encouraged but not required to use the char_traits<charT> functions for all comparisons and assignments of characters of type charT that do not belong to the set of required specializations.
Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
Stage 2: If in==end then stage 2 terminates. Otherwise a charT is taken from in and local variables are initialized as if by
char_type ct = *in; using tr = char_traits<char_type>; const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct); char c = src[find(atoms, atoms + sizeof(src) - 1, ct) - atomspos ? pos - atoms : sizeof(src) - 1]; if (tr::eq(ct,ct ==use_facet<numpunct<charT>(loc).decimal_point())) c = '.'; bool discard = tr::eq(ct,ct ==use_facet<numpunct<charT>(loc).thousands_sep()) && use_facet<numpunct<charT> >(loc).grouping().length() != 0;where the values src and atoms are defined as if by: [..]
[Remark of the author: I considered to replace the initialization "char_type ct = *in;" by the sequence "char_type ct; tr::assign(ct, *in);", but decided against it, because it is a copy-initialization context, not an assignment]
Add the following sentence to the end of 22.4.5 [category.time]/1:
[..] Their members use [..] , to determine formatting details. Implementations are encouraged but not required to use the char_traits<charT> functions for all comparisons and assignments of characters of type charT that do not belong to the set of required specializations.
Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
Add the following sentence to the end of 22.4.6 [category.monetary]/2:
Their members use [..] to determine formatting details. Implementations are encouraged but not required to use the char_traits<charT> functions for all comparisons and assignments of characters of type charT that do not belong to the set of required specializations.
Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
[..] The value units is produced as if by:
for (int i = 0; i < n; ++i) buf2[i] = src[char_traits<charT>::find(atoms,atoms+sizeof(src), buf1[i]) - atoms]; buf2[n] = 0; sscanf(buf2, "%Lf", &units);
Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
[..] for character buffers buf1 and buf2. If for the first character c in digits or buf2is equal to ct.widen('-')char_traits<charT>::eq(c, ct.widen('-')) == true, [..]
Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
As in the case of the inserters, these extractors depend on the locale's num_get<> (22.4.2.1) object to perform parsing the input stream data.(footnote) [..]
footnote) If the traits of the input stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
Effects: The classes num_get<> and num_put<> handle locale-dependent numeric formatting and parsing. These inserter functions use the imbued locale value to perform numeric formatting.(footnote) [..]
footnote) If the traits of the output stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
Returns: An object of unspecified type such that if in is an object of type basic_istream<charT, traits> then the expression in >> get_money(mon, intl) behaves as if it called f(in, mon, intl), where the function f is defined as:(footnote) [..]
footnote) If the traits of the input stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
Returns: An object of unspecified type such that if out is an object of type basic_ostream<charT, traits> then the expression out << put_money(mon, intl) behaves as a formatted input function that calls f(out, mon, intl), where the function f is defined as:(footnote) [..]
footnote) If the traits of the output stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
13) Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
Returns: An object of unspecified type such that if in is an object of type basic_istream<charT, traits> then the expression in >>get_time(tmb, fmt) behaves as if it called f(in, tmb, fmt), where the function f is defined as:(footnote) [..]
footnote) If the traits of the input stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
Returns: An object of unspecified type such that if out is an object of type basic_ostream<charT, traits> then the expression out <<put_time(tmb, fmt) behaves as if it called f(out, tmb, fmt), where the function f is defined as:(footnote) [..]
footnote) If the traits of the output stream has different semantics for lt(), eq(), and assign() than char_traits<char_type>, this may give surprising results.
Section: 26.6.2.4 [valarray.sub] Status: Open Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2009-11-04
View all issues with Open status.
Discussion:
The standard fails to specify the behavior of valarray::operator[](slice) and other valarray subset operations when they are passed an "invalid" slice object, i.e., either a slice that doesn't make sense at all (e.g., slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray object (e.g., slice (2, 1, 1) for a valarray of size 1).
[Kona: the LWG believes that invalid slices should invoke undefined behavior. Valarrays are supposed to be designed for high performance, so we don't want to require specific checking. We need wording to express this decision.]
[ Bellevue: ]
Please note that the standard also fails to specify the behavior of slice_array and gslice_array in the valid case. Bill Plauger will endeavor to provide revised wording for slice_array and gslice_array.
[ post-Bellevue: Bill provided wording. ]
[ 2009-07 Frankfurt ]
Move to Ready.
[ 2009-11-04 Pete opens: ]
The resolution to LWG issue 430 has not been applied --- there have been changes to the underlying text, and the resolution needs to be reworked.
Proposed resolution:
Insert after 26.6.2.4 [valarray.sub], paragraph 1:
The member operator is overloaded to provide several ways to select sequences of elements from among those controlled by *this. The first group of five member operators work in conjunction with various overloads of operator= (and other assigning operators) to allow selective replacement (slicing) of the controlled sequence. The selected elements must exist.
The first member operator selects element off. For example:
valarray<char> v0("abcdefghijklmnop", 16); v0[3] = 'A'; // v0 == valarray<char>("abcAefghijklmnop", 16)The second member operator selects those elements of the controlled sequence designated by slicearr. For example:
valarray<char> v0("abcdefghijklmnop", 16); valarray<char> v1("ABCDE", 5); v0[slice(2, 5, 3)] = v1; // v0 == valarray<char>("abAdeBghCjkDmnEp", 16)The third member operator selects those elements of the controlled sequence designated by gslicearr. For example:
valarray<char> v0("abcdefghijklmnop", 16); valarray<char> v1("ABCDEF", 6); const size_t lv[] = {2, 3}; const size_t dv[] = {7, 2}; const valarray<size_t> len(lv, 2), str(dv, 2); v0[gslice(3, len, str)] = v1; // v0 == valarray<char>("abcAeBgCijDlEnFp", 16)The fourth member operator selects those elements of the controlled sequence designated by boolarr. For example:
valarray<char> v0("abcdefghijklmnop", 16); valarray<char> v1("ABC", 3); const bool vb[] = {false, false, true, true, false, true}; v0[valarray<bool>(vb, 6)] = v1; // v0 == valarray<char>("abABeCghijklmnop", 16)The fifth member operator selects those elements of the controlled sequence designated by indarr. For example:
valarray<char> v0("abcdefghijklmnop", 16); valarray<char> v1("ABCDE", 5); const size_t vi[] = {7, 5, 2, 3, 8}; v0[valarray<size_t>(vi, 5)] = v1; // v0 == valarray<char>("abCDeBgAEjklmnop", 16)The second group of five member operators each construct an object that represents the value(s) selected. The selected elements must exist.
The sixth member operator returns the value of element off. For example:
valarray<char> v0("abcdefghijklmnop", 16); // v0[3] returns 'd'The seventh member operator returns an object of class valarray<Ty> containing those elements of the controlled sequence designated by slicearr. For example:
valarray<char> v0("abcdefghijklmnop", 16); // v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)The eighth member operator selects those elements of the controlled sequence designated by gslicearr. For example:
valarray<char> v0("abcdefghijklmnop", 16); const size_t lv[] = {2, 3}; const size_t dv[] = {7, 2}; const valarray<size_t> len(lv, 2), str(dv, 2); // v0[gslice(3, len, str)] returns // valarray<char>("dfhkmo", 6)The ninth member operator selects those elements of the controlled sequence designated by boolarr. For example:
valarray<char> v0("abcdefghijklmnop", 16); const bool vb[] = {false, false, true, true, false, true}; // v0[valarray<bool>(vb, 6)] returns // valarray<char>("cdf", 3)The last member operator selects those elements of the controlled sequence designated by indarr. For example:
valarray<char> v0("abcdefghijklmnop", 16); const size_t vi[] = {7, 5, 2, 3, 8}; // v0[valarray<size_t>(vi, 5)] returns // valarray<char>("hfcdi", 5)
Section: 24.2 [iterator.requirements], 23.2 [container.requirements] Status: Open Submitter: Andy Koenig Opened: 2003-12-16 Last modified: 2009-11-03
View other active issues in [iterator.requirements].
View all other issues in [iterator.requirements].
View all issues with Open status.
Discussion:
What requirements does the standard place on equality comparisons between iterators that refer to elements of different containers. For example, if v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true? Is it allowed to throw an exception?
The standard appears to be silent on both questions.
[Sydney: The intention is that comparing two iterators from different containers is undefined, but it's not clear if we say that, or even whether it's something we should be saying in clause 23 or in clause 24. Intuitively we might want to say that equality is defined only if one iterator is reachable from another, but figuring out how to say it in any sensible way is a bit tricky: reachability is defined in terms of equality, so we can't also define equality in terms of reachability. ]
[ 2009-07 Frankfurt ]
Daniel volunteered to work on this.
[ 2009-09-20 Daniel provided wording. ]
[ 2009-10 Santa Cruz: ]
Leave as Open. Alisdair has volunteered to refine the wording.
Proposed resolution:
Insert a new paragraph between 24.2 [iterator.requirements]/7+8:
[..] The result of the application of functions in the library to invalid ranges is undefined.
The result of directly or indirectly evaluating any comparison function or the binary - operator with two iterator values as arguments that were obtained from two different ranges r1 and r2 (including their past-the-end values) which are not subranges of one common range is undefined, unless explicitly described otherwise.
Section: 18.8.1 [exception] Status: Ready Submitter: Martin Sebor Opened: 2004-06-28 Last modified: 2009-10-26
View all issues with Ready status.
Discussion:
[lib.exception] specifies the following:
exception (const exception&) throw();
exception& operator= (const exception&) throw();
-4- Effects: Copies an exception object.
-5- Notes: The effects of calling what() after assignment
are implementation-defined.
First, does the Note only apply to the assignment operator? If so, what are the effects of calling what() on a copy of an object? Is the returned pointer supposed to point to an identical copy of the NTBS returned by what() called on the original object or not?
Second, is this Note intended to extend to all the derived classes in section 19? I.e., does the standard provide any guarantee for the effects of what() called on a copy of any of the derived class described in section 19?
Finally, if the answer to the first question is no, I believe it constitutes a defect since throwing an exception object typically implies invoking the copy ctor on the object. If the answer is yes, then I believe the standard ought to be clarified to spell out exactly what the effects are on the copy (i.e., after the copy ctor was called).
[Redmond: Yes, this is fuzzy. The issue of derived classes is fuzzy too.]
[ Batavia: Howard provided wording. ]
[ Bellevue: ]
Eric concerned this is unimplementable, due to nothrow guarantees. Suggested implementation would involve reference counting.
Is the implied reference counting subtle enough to call out a note on implementation? Probably not.
If reference counting required, could we tighten specification further to require same pointer value? Probably an overspecification, especially if exception classes defer evalutation of final string to calls to what().
Remember issue moved open and not resolved at Batavia, but cannot remember who objected to canvas a disenting opinion - please speak up if you disagree while reading these minutes!
Move to Ready as we are accepting words unmodified.
[ 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 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.
[ 2009-07-30 Niels adds: ]
Further discussion in the thread starting with c++std-lib-24512.
[ 2009-09-24 Niels provided updated wording: ]
I think the resolution should at least guarantee that the result of what() is independent of whether the compiler does copy-elision. And for any class derived from std::excepion that has a constructor that allows specifying a what_arg, it should make sure that the text of a user-provided what_arg is preserved, when the object is copied. Note that all the implementations I've tested already appear to satisfy the proposed resolution, including MSVC 2008 SP1, Apache stdcxx-4.2.1, GCC 4.1.2, GCC 4.3.2, and CodeGear C++ 6.13.
The proposed resolution was updated with help from Daniel Krügler; the update aims to clarify that the proposed postcondition only applies to homogeneous copying.
[ 2009-10 Santa Cruz: ]
Moved to Ready after inserting "publicly accessible" in two places.
Proposed resolution:
Change 18.8.1 [exception] to:
-1- The class exception defines the base class for the types of objects thrown as exceptions by C++ standard library components, and certain expressions, to report errors detected during program execution.
Each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception. These member functions shall preserve the following postcondition: If two objects lhs and rhs both have dynamic type T, and lhs is a copy of rhs, then strcmp(lhs.what(), rhs.what()) == 0.
...
exception(const exception& rhs) throw(); exception& operator=(const exception& rhs) throw();-4- Effects: Copies an exception object.
-5- Remarks: The effects of calling what() after assignment are implementation-defined.-5- Postcondition: If *this and rhs both have dynamic type exception then strcmp(what(), rhs.what()) == 0.
Section: 22.4.1.1 [locale.ctype] Status: Ready Submitter: Martin Sebor Opened: 2004-07-01 Last modified: 2009-10-21
View all issues with Ready status.
Discussion:
Most ctype member functions come in two forms: one that operates on a single character at a time and another form that operates on a range of characters. Both forms are typically described by a single Effects and/or Returns clause.
The Returns clause of each of the single-character non-virtual forms suggests that the function calls the corresponding single character virtual function, and that the array form calls the corresponding virtual array form. Neither of the two forms of each virtual member function is required to be implemented in terms of the other.
There are three problems:
1. One is that while the standard does suggest that each non-virtual member function calls the corresponding form of the virtual function, it doesn't actually explicitly require it.
Implementations that cache results from some of the virtual member functions for some or all values of their arguments might want to call the array form from the non-array form the first time to fill the cache and avoid any or most subsequent virtual calls. Programs that rely on each form of the virtual function being called from the corresponding non-virtual function will see unexpected behavior when using such implementations.
2. The second problem is that either form of each of the virtual functions can be overridden by a user-defined function in a derived class to return a value that is different from the one produced by the virtual function of the alternate form that has not been overriden.
Thus, it might be possible for, say, ctype::widen(c) to return one value, while for ctype::widen(&c, &c + 1, &wc) to set wc to another value. This is almost certainly not intended. Both forms of every function should be required to return the same result for the same character, otherwise the same program using an implementation that calls one form of the functions will behave differently than when using another implementation that calls the other form of the function "under the hood."
3. The last problem is that the standard text fails to specify whether one form of any of the virtual functions is permitted to be implemented in terms of the other form or not, and if so, whether it is required or permitted to call the overridden virtual function or not.
Thus, a program that overrides one of the virtual functions so that it calls the other form which then calls the base member might end up in an infinite loop if the called form of the base implementation of the function in turn calls the other form.
Lillehammer: Part of this isn't a real problem. We already talk about caching. 22.1.1/6 But part is a real problem. ctype virtuals may call each other, so users don't know which ones to override to avoid avoid infinite loops.
This is a problem for all facet virtuals, not just ctype virtuals, so we probably want a blanket statement in clause 22 for all facets. The LWG is leaning toward a blanket prohibition, that a facet's virtuals may never call each other. We might want to do that in clause 27 too, for that matter. A review is necessary. Bill will provide wording.
[ 2009-07 Frankfurt, Howard provided wording directed by consensus. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Add paragraph 3 to 22.4 [locale.categories]:
-3- Within this clause it is unspecified if one virtual function calls another virtual function.
Rationale:
We are explicitly not addressing bullet item #2, thus giving implementors more latitude. Users will have to override both virtual functions, not just one.
Section: 24.2.2 [output.iterators] Status: Ready Submitter: Chris Jefferson Opened: 2004-10-13 Last modified: 2009-10-26
View all other issues in [output.iterators].
View all issues with Ready status.
Discussion:
The note on 24.1.2 Output iterators insufficiently limits what can be performed on output iterators. While it requires that each iterator is progressed through only once and that each iterator is written to only once, it does not require the following things:
Note: Here it is assumed that x is an output iterator of type X which has not yet been assigned to.
a) That each value of the output iterator is written to: The standard allows: ++x; ++x; ++x;
b) That assignments to the output iterator are made in order X a(x); ++a; *a=1; *x=2; is allowed
c) Chains of output iterators cannot be constructed: X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current wording (I believe) x,a,b,c could be written to in any order.
I do not believe this was the intension of the standard?
[Lillehammer: Real issue. There are lots of constraints we intended but didn't specify. Should be solved as part of iterator redesign.]
[ 2009-07 Frankfurt ]
Bill provided wording according to consensus.
[ 2009-07-21 Alisdair requests change from Review to Open. See thread starting with c++std-lib-24459 for discussion. ]
[ 2009-10 Santa Cruz: ]
Modified wording. Set to Review.
[ 2009-10 Santa Cruz: ]
Move to Ready after looking at again in a larger group in Santa Cruz.
Proposed resolution:
Change Table 101 — Output iterator requirements in 24.2.2 [output.iterators]:
Table 101 — Output iterator requirements Expression Return type Operational semantics Assertion/note pre-/post-condition X(a) a = t is equivalent to X(a) = t. note: a destructor is assumed. X u(a);
X u = a;*r = o result is not used Post: r is not required to be dereferenceable. r is incrementable. ++r X& &r == &++r Post: r is dereferenceable, unless otherwise specified. r is not required to be incrementable. r++ convertible to const X& {X tmp = r;
++r;
return tmp;}Post: r is dereferenceable, unless otherwise specified. r is not required to be incrementable. *r++ = o; result is not used
Section: 26.7.3 [partial.sum] Status: Ready Submitter: Marc Schoolderman Opened: 2006-02-06 Last modified: 2009-10-24
View all issues with Ready status.
Discussion:
There are some problems in the definition of partial_sum and adjacent_difference in 26.4 [lib.numeric.ops]
Unlike accumulate and inner_product, these functions are not parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply specifies the effects clause as;
Assigns to every element referred to by iterator i in the range [result,result + (last - first)) a value correspondingly equal to
((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
And similarly for BinaryOperation. Using just this definition, it seems logical to expect that:
char i_array[4] = { 100, 100, 100, 100 };
int o_array[4];
std::partial_sum(i_array, i_array+4, o_array);
Is equivalent to
int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
i.e. 100, 200, 300, 400, with addition happening in the result type, int.
Yet all implementations I have tested produce 100, -56, 44, -112, because they are using an accumulator of the InputIterator's value_type, which in this case is char, not int.
The issue becomes more noticeable when the result of the expression *i + *(i+1) or binary_op(*i, *i-1) can't be converted to the value_type. In a contrived example:
enum not_int { x = 1, y = 2 };
...
not_int e_array[4] = { x, x, y, y };
std::partial_sum(e_array, e_array+4, o_array);
Is it the intent that the operations happen in the input type, or in the result type?
If the intent is that operations happen in the result type, something like this should be added to the "Requires" clause of 26.4.3/4 [lib.partial.sum]:
The type of *i + *(i+1) or binary_op(*i, *(i+1)) shall meet the requirements of CopyConstructible (20.1.3) and Assignable (23.1) types.
(As also required for T in 26.4.1 [lib.accumulate] and 26.4.2 [lib.inner.product].)
The "auto initializer" feature proposed in N1894 is not required to implement partial_sum this way. The 'narrowing' behaviour can still be obtained by using the std::plus<> function object.
If the intent is that operations happen in the input type, then something like this should be added instead;
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.
The 'widening' behaviour can then be obtained by writing a custom proxy iterator, which is somewhat involved.
In both cases, the semantics should probably be clarified.
26.4.4 [lib.adjacent.difference] is similarly underspecified, although all implementations seem to perform operations in the 'result' type:
unsigned char i_array[4] = { 4, 3, 2, 1 };
int o_array[4];
std::adjacent_difference(i_array, i_array+4, o_array);
o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
In any case, adjacent_difference doesn't mention the requirements on the value_type; it can be brought in line with the rest of 26.4 [lib.numeric.ops] by adding the following to 26.4.4/2 [lib.adjacent.difference]:
The type of *first shall meet the requirements of CopyConstructible (20.1.3) and Assignable (23.1) types."
[ Berlin: Giving output iterator's value_types very controversial. Suggestion of adding signatures to allow user to specify "accumulator". ]
[ Bellevue: ]
The intent of the algorithms is to perform their calculations using the type of the input iterator. Proposed wording provided.
[ Sophia Antipolis: ]
We did not agree that the proposed resolution was correct. For example, when the arguments are types (float*, float*, double*), the highest-quality solution would use double as the type of the accumulator. If the intent of the wording is to require that the type of the accumulator must be the input_iterator's value_type, the wording should specify it.
[ 2009-05-09 Alisdair adds: ]
Now that we have the facility, the 'best' accumulator type could probably be deduced as:
std::common_type<InIter::value_type, OutIter::reference>::typeThis 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.
[ 2009-07 Frankfurt ]
The proposed resolution isn't quite right. For example, "the type of *first" should be changed to "iterator::value_type" or similar. Daniel volunteered to correct the wording.
[ 2009-07-29 Daniel corrected wording. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Change 26.7.3 [partial.sum]/1 as indicated:
Effects: Let VT be InputIterator's value type. For a nonempty range, initializes an accumulator acc of type VT with *first and performs *result = acc. For every iterator i in [first + 1, last) in order, acc is then modified by acc = acc + *i or acc = binary_op(acc, *i) and is assigned to *(result + (i - first)).
Assigns to every element referred to by iterator i in the range [result,result + (last - first)) a value correspondingly equal to((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
orbinary_op(binary_op(..., binary_op(*first, *(first + 1)),...), *(first + (i - result)))
Change 26.7.3 [partial.sum]/3 as indicated:
Complexity: Exactly max((last - first) - 1, 0) applications ofbinary_opthe binary operation.
Change 26.7.3 [partial.sum]/4 as indicated:
Requires: VT shall be constructible from the type of *first, the result of acc + *i or binary_op(acc, *i) shall be implicitly convertible to VT, and the result of the expression acc shall be writable to the result output iterator. In the ranges [first,last] and [result,result + (last - first)] [..]
Change 26.7.4 [adjacent.difference]/1 as indicated:
Effects: Let VT be InputIterator's value type. For a nonempty range, initializes an accumulator acc of type VT with *first and performs *result = acc. For every iterator i in [first + 1, last) in order, initializes a value val of type VT with *i, assigns the result of val - acc or binary_op(val, acc) to *(result + (i - first)) and modifies acc = std::move(val).
Assigns to every element referred to by iterator i in the range [result + 1, result + (last - first)) a value correspondingly equal to*(first + (i - result)) - *(first + (i - result) - 1)
orbinary_op(*(first + (i - result)), *(first + (i - result) - 1)).
result gets the value of *first.
Change 26.7.4 [adjacent.difference]/2 as indicated:
Requires: VT shall be MoveAssignable ([moveassignable]) and shall be constructible from the type of *first. The result of the expression acc and the result of the expression val - acc or binary_op(val, acc) shall be writable to the result output iterator. In the ranges [first,last] [..]
Change 26.7.4 [adjacent.difference]/5 as indicated:
Complexity: Exactly max((last - first) - 1, 0) applications ofbinary_opthe binary operation.
Section: 25.4 [alg.sorting] Status: Review Submitter: Martin Sebor Opened: 2006-02-05 Last modified: 2009-10-25
View all other issues in [alg.sorting].
View all issues with Review 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...
[ Portland: Jack to define "convertible to bool" such that short circuiting isn't destroyed. ]
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10 Santa Cruz: ]
Move to Review once wording received. Stefanus to send proposed wording.
[ 2009-10 Santa Cruz: ]
Move to Review once wording received. Stefanus to send proposed wording.
[ 2009-10-24 Stefanus supplied wording. ]
Move to Review once wording received. Stefanus to send proposed wording. Current proposed wording proposed here: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.
Proposed resolution:
Change 25.4 [alg.sorting] p2:
Compare is used as a function object. 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 callwhich returns true if the first argumentis 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.
Rationale:
[ San Francisco: ]
Solved by (N2774).
Section: 20.2.1 [utility.arg.requirements] Status: Open Submitter: Niels Dekker Opened: 2006-11-02 Last modified: 2009-11-08
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
View all issues with Open status.
Discussion:
It seems undesirable to define the Swappable requirement in terms of CopyConstructible and Assignable requirements. And likewise, once the MoveConstructible and MoveAssignable requirements (N1860) have made it into the Working Draft, it seems undesirable to define the Swappable requirement in terms of those requirements. Instead, it appears preferable to have the Swappable requirement defined exclusively in terms of the existence of an appropriate swap function.
Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) says:
The Swappable requirement is met by satisfying one or more of the following conditions:
- T is Swappable if T satisfies the CopyConstructible requirements (20.1.3) and the Assignable requirements (23.1);
- T is Swappable if a namespace scope function named swap exists in the same namespace as the definition of T, such that the expression swap(t,u) is valid and has the semantics described in Table 33.
I can think of three disadvantages of this definition:
If a client's type T satisfies the first condition (T is both CopyConstructible and Assignable), the client cannot stop T from satisfying the Swappable requirement without stopping T from satisfying the first condition.
A client might want to stop T from satisfying the Swappable requirement, because swapping by means of copy construction and assignment might throw an exception, and she might find a throwing swap unacceptable for her type. On the other hand, she might not feel the need to fully implement her own swap function for this type. In this case she would want to be able to simply prevent algorithms that would swap objects of type T from being used, e.g., by declaring a swap function for T, and leaving this function purposely undefined. This would trigger a link error, if an attempt would be made to use such an algorithm for this type. For most standard library implementations, this practice would indeed have the effect of stopping T from satisfying the Swappable requirement.
A client's type T that does not satisfy the first condition can not be made Swappable by providing a specialization of std::swap for T.
While I'm aware about the fact that people have mixed feelings about providing a specialization of std::swap, it is well-defined to do so. It sounds rather counter-intuitive to say that T is not Swappable, if it has a valid and semantically correct specialization of std::swap. Also in practice, providing such a specialization will have the same effect as satisfying the Swappable requirement.
For a client's type T that satisfies both conditions of the Swappable requirement, it is not specified which of the two conditions prevails. After reading section 20.1.4 [lib.swappable], one might wonder whether objects of T will be swapped by doing copy construction and assignments, or by calling the swap function of T.
I'm aware that the intention of the Draft is to prefer calling the swap function of T over doing copy construction and assignments. Still in my opinion, it would be better to make this clear in the wording of the definition of Swappable.
I would like to have the Swappable requirement defined in such a way that the following code fragment will correctly swap two objects of a type T, if and only if T is Swappable:
using std::swap; swap(t, u); // t and u are of type T.
This is also the way Scott Meyers recommends calling a swap function, in Effective C++, Third Edition, item 25.
Most aspects of this issue have been dealt with in a discussion on comp.std.c++ about the Swappable requirement, from 13 September to 4 October 2006, including valuable input by David Abrahams, Pete Becker, Greg Herlihy, Howard Hinnant and others.
[ San Francisco: ]
Recommend NAD. Solved by N2774.
[ 2009-07 Frankfurt ]
Moved to Open. Waiting for non-concepts draft.
[ 2009-11-08 Howard adds: ]
This issue is very closely related to 742.
Proposed resolution:
Change section 20.1.4 [lib.swappable] as follows:
The Swappable requirement is met by satisfying
one or more of the following conditions:the following condition:
T is Swappable if T satisfies the CopyConstructible requirements (20.1.3) and the Assignable requirements (23.1);T is Swappable if a namespace scope function named swap exists in the same namespace as the definition of T, such that the expression swap(t,u) is valid and has the semantics described in Table 33.T is Swappable if an unqualified function call swap(t,u) is valid within the namespace std, and has the semantics described in Table 33.
Section: 17 [library] Status: Open Submitter: Martin Sebor Opened: 2007-01-20 Last modified: 2009-10-20
View other active issues in [library].
View all other issues in [library].
View all issues with Open status.
Duplicate of: 895
Discussion:
Many member functions of basic_string are overloaded,
with some of the overloads taking a string argument,
others value_type*, others size_type, and
others still iterators. Often, the requirements on one of
the overloads are expressed in the form of Effects,
Throws, and in the Working Paper
(N2134)
also Remark clauses, while those on the rest of the overloads
via a reference to this overload and using a Returns clause.
The difference between the two forms of specification is that per 17.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.
Since only Notes are explicitly defined to be informative and all other paragraphs are explicitly defined to be normative, like Effects and Returns, the new Remark clauses also impose normative requirements.
So by this strict reading of the standard there are some member
functions of basic_string that are required to throw an
exception under some conditions or use specific traits members while
many other otherwise equivalent overloads, while obliged to return the
same values, aren't required to follow the exact same requirements
with regards to the observable effects.
Here's an example of this problem that was precipitated by the change from informative Notes to normative Remarks (presumably made to address 424):
In the Working Paper, find(string, size_type) contains a
Remark clause (which is just a Note in the current
standard) requiring it to use traits::eq().
find(const charT *s, size_type pos) is specified to
return find(string(s), pos) by a Returns clause
and so it is not required to use traits::eq(). However,
the Working Paper has replaced the original informative Note
about the function using traits::length() with a
normative requirement in the form of a Remark. Calling
traits::length() may be suboptimal, for example when the
argument is a very long array whose initial substring doesn't appear
anywhere in *this.
Here's another similar example, one that existed even prior to the introduction of Remarks:
insert(size_type pos, string, size_type, size_type) is
required to throw out_of_range if pos >
size().
insert(size_type pos, string str) is specified to return
insert(pos, str, 0, npos) by a Returns clause and
so its effects when pos > size() are strictly speaking
unspecified.
I believe a careful review of the current Effects and Returns clauses is needed in order to identify all such problematic cases. In addition, a review of the Working Paper should be done to make sure that the newly introduced normative Remark clauses do not impose any undesirable normative requirements in place of the original informative Notes.
[ Batavia: Alan and Pete to work. ]
[ Bellevue: Marked as NAD Editorial. ]
[ Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. Reopened. ]
[ Batavia (2009-05): ]
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.
[ 2009-07 Frankfurt ]
Move to Tentatively NAD.
[ 2009 Santa Cruz: ]
Move to Open. Martin will work on proposed wording.
Proposed resolution:
Section: 25 [algorithms] Status: Review Submitter: James Kanze Opened: 2007-01-31 Last modified: 2009-10-24
View other active issues in [algorithms].
View all other issues in [algorithms].
View all issues with Review 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.4.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. ]
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10 Santa Cruz: ]
Move to Review. The small problem with the "iterator type" will be fixed. The cited functions (lower_bound, uppwer_bound, equal_range) don't actually use BinaryPredicate , and where it is used, it is consistent with [algorithm]/8, so the main complaint of the issue is moot.
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.
Rationale:
[ post San Francisco: ]
Solved by N2759.
Section: 22.4.2.2.2 [facet.num.put.virtuals] Status: Ready Submitter: John Salmon Opened: 2007-04-20 Last modified: 2009-10-21
View other active issues in [facet.num.put.virtuals].
View all other issues in [facet.num.put.virtuals].
View all issues with Ready status.
Discussion:
I am trying to understand how TR1 supports hex float (%a) output.
As far as I can tell, it does so via the following:
8.15 Additions to header <locale> [tr.c99.locale]
In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line: floatfield == ios_base::scientific %E
add the two lines:
floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a floatfield == ios_base::fixed | ios_base::scientific %A 2
[Note: The additional requirements on print and scan functions, later in this clause, ensure that the print functions generate hexadecimal floating-point fields with a %a or %A conversion specifier, and that the scan functions match hexadecimal floating-point fields with a %g conversion specifier. end note]
Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
For conversion from a floating-point type, if (flags & fixed) != 0 or if str.precision() > 0, then str.precision() is specified in the conversion specification.
This would seem to imply that when floatfield == fixed|scientific, the precision of the conversion specifier is to be taken from str.precision(). Is this really what's intended? I sincerely hope that I'm either missing something or this is an oversight. Please tell me that the committee did not intend to mandate that hex floats (and doubles) should by default be printed as if by %.6a.
[ Howard: I think the fundamental issue we overlooked was that with %f, %e, %g, the default precision was always 6. With %a the default precision is not 6, it is infinity. So for the first time, we need to distinguish between the default value of precision, and the precision value 6. ]
[ 2009-07 Frankfurt ]
Leave this open for Robert and Daniel to work on.
Straw poll: Disposition?
- Default is %.6a (i.e. NAD): 2
- Always %a (no precision): 6
- precision(-1) == %a: 3
Daniel and Robert have direction to write up wording for the "always %a" solution.
[ 2009-07-15 Robert provided wording. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end of Stage 1):
For conversion from a floating-point type, str.precision() is specified as precision in the conversion specification if floatfield != (ios_base::fixed | ios_base::scientific), else no precision is specified.
[ Kona (2007): Robert volunteers to propose wording. ]
Section: 23.5 [unord] Status: Review Submitter: Howard Hinnant Opened: 2007-05-05 Last modified: 2009-10-29
View all other issues in [unord].
View all issues with Review status.
Discussion:
Move semantics are missing from the unordered containers. The proposed resolution below adds move-support consistent with N1858 and the current working draft.
The current proposed resolution simply lists the requirements for each function. These might better be hoisted into the requirements table for unordered associative containers. Futhermore a mild reorganization of the container requirements could well be in order. This defect report is purposefully ignoring these larger issues and just focusing on getting the unordered containers "moved".
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10-17 Removed rvalue-swaps from wording. ]
[ 2009-10 Santa Cruz: ]
Move to Review. Alisdair will review proposed wording.
[ 2009-10-29 Daniel updates wording. ]
Proposed resolution:
unordered_map
Change 23.5.1 [unord.map]:
class unordered_map
{
...
unordered_map(const unordered_map&);
unordered_map(unordered_map&&);
~unordered_map();
unordered_map& operator=(const unordered_map&);
unordered_map& operator=(unordered_map&&);
...
// modifiers
std::pair<iterator, bool> insert(const value_type& obj);
template <class P> pair<iterator, bool> insert(P&& obj);
iterator insert(const_iterator hint, const value_type& obj);
template <class P> iterator insert(const_iterator hint, P&& obj);
...
mapped_type& operator[](const key_type& k);
mapped_type& operator[](key_type&& k);
...
};
Add to 23.5.1.1 [unord.map.cnstr]:
template <class InputIterator> unordered_map(InputIterator f, InputIterator l, size_type n = implementation-defined, const hasher& hf = hasher(), const key_equal& eql = key_equal(), const allocator_type& a = allocator_type());Requires: If the iterator's dereference operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.
Add to 23.5.1.2 [unord.map.elem]:
mapped_type& operator[](const key_type& k);...
Requires: key_type shall be CopyConstructible and mapped_type shall be DefaultConstructible.
mapped_type& operator[](key_type&& k);Effects: If the unordered_map does not already contain an element whose key is equivalent to k , inserts the value std::pair<const key_type, mapped_type>(std::move(k), mapped_type()).
Requires: mapped_type shall be DefaultConstructible.
Returns: A reference to x.second, where x is the (unique) element whose key is equivalent to k.
Add new section [unord.map.modifiers]:
pair<iterator, bool> insert(const value_type& x); template <class P> pair<iterator, bool> insert(P&& x); iterator insert(const_iterator hint, const value_type& x); template <class P> 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. 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 for 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.
unordered_multimap
Change 23.5.2 [unord.multimap]:
class unordered_multimap
{
...
unordered_multimap(const unordered_multimap&);
unordered_multimap(unordered_multimap&&);
~unordered_multimap();
unordered_multimap& operator=(const unordered_multimap&);
unordered_multimap& operator=(unordered_multimap&&);
...
// modifiers
iterator insert(const value_type& obj);
template <class P> iterator insert(P&& obj);
iterator insert(const_iterator hint, const value_type& obj);
template <class P> iterator insert(const_iterator hint, P&& obj);
...
};
Add to 23.5.2.1 [unord.multimap.cnstr]:
template <class InputIterator> unordered_multimap(InputIterator f, InputIterator l, size_type n = implementation-defined, const hasher& hf = hasher(), const key_equal& eql = key_equal(), const allocator_type& a = allocator_type());Requires: If the iterator's dereference operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.
Add new section [unord.multimap.modifiers]:
iterator insert(const value_type& x); template <class P> iterator insert(P&& x); iterator insert(const_iterator hint, const value_type& x); template <class P> 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. 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 for 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.
unordered_set
Change 23.5.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(const_iterator hint, const value_type& obj);
iterator insert(const_iterator hint, value_type&& obj);
...
};
Add to 23.5.3.1 [unord.set.cnstr]:
template <class InputIterator> unordered_set(InputIterator f, InputIterator l, size_type n = implementation-defined, const hasher& hf = hasher(), const key_equal& eql = key_equal(), const allocator_type& a = allocator_type());Requires: If the iterator's dereference operator returns an lvalue or a const rvalue value_type, then the value_type shall be CopyConstructible.
Add new section [unord.set.modifiers]:
pair<iterator, bool> insert(const value_type& x); pair<iterator, bool> insert(value_type&& x); iterator insert(const_iterator hint, const value_type& x); 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.
unordered_multiset
Change 23.5.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(const_iterator hint, const value_type& obj);
iterator insert(const_iterator hint, value_type&& obj);
...
};
Add to 23.5.4.1 [unord.multiset.cnstr]:
template <class InputIterator> unordered_multiset(InputIterator f, InputIterator l, size_type n = implementation-defined, const hasher& hf = hasher(), const key_equal& eql = key_equal(), const allocator_type& a = allocator_type());Requires: If the iterator's dereference operator returns an lvalue or a const rvalue value_type, then the value_type shall be CopyConstructible.
Add new section [unord.multiset.modifiers]:
iterator insert(const value_type& x); iterator insert(value_type&& x); iterator insert(const_iterator hint, const value_type& x); 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.
[ Voted to WP in Bellevue. ]
[ post Bellevue, Pete notes: ]
Please remind people who are reviewing issues to check that the text modifications match the current draft. Issue 676, for example, adds two overloads for unordered_map::insert taking a hint. One takes a const_iterator and returns a const_iterator, and the other takes an iterator and returns an iterator. This was correct at the time the issue was written, but was changed in Toronto so there is only one hint overload, taking a const_iterator and returning an iterator.
This issue is not ready. In addition to the relatively minor signature problem I mentioned earlier, it puts requirements in the wrong places. Instead of duplicating requirements throughout the template specifications, it should put them in the front matter that talks about requirements for unordered containers in general. This presentation problem is editorial, but I'm not willing to do the extensive rewrite that it requires. Please put it back into Open status.
Rationale:
[ San Francisco: ]
Solved by N2776.
Section: 23.2 [container.requirements] Status: Open Submitter: Howard Hinnant Opened: 2007-05-20 Last modified: 2009-10-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.
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.
| 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. |
| 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. |
| 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] |
| 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.. |
| 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.. |
| 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. |
[ 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. ]
[ 2009-07-20 Reopened by Howard: ]
This is one of the issues that was "solved by concepts" and is now no longer solved.
In a nutshell, concepts adopted the "minimum requirements" philosophy outlined in the discussion of this issue, and enforced it. My strong suggestion is that we translate the concepts specification into documentation for the containers.
What this means for vendors is that they will have to implement container members being careful to only use those characteristics of a type that the concepts specification formally allowed. Note that I am not talking about enable_if'ing everything. I am simply suggesting that (for example) we tell the vendor he can't call T's copy constructor or move constructor within the emplace member function, etc.
What this means for customers is that they will be able to use types within C++03 containers which are sometimes not CopyConstructible, and sometimes not even MoveConstructible, etc.
[ 2009-10 Santa Cruz: ]
Leave open. Howard to provide wording.
Proposed resolution:
Rationale:
[ post San Francisco: ]
Solved by N2776.
Section: 20.2.1 [utility.arg.requirements] Status: Open Submitter: Pablo Halpern Opened: 2007-09-12 Last modified: 2009-10-23
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.
[ Bellevue: ]
Walking into the default/value-initialization mess...
Why two lines? Because we need both expressions to be valid.
AJM not sure what the phrase "default constructed" means. This is unfortunate, as the phrase is already used 24 times in the library!
Example: const int would not accept first line, but will accept the second.
This is an issue that must be solved by concepts, but we might need to solve it independantly first.
It seems that the requirements are the syntax in the proposed first column is valid, but not clear what semantics we need.
A table where there is no post-condition seems odd, but appears to sum up our position best.
At a minimum an object is declared and is destuctible.
Move to open, as no-one happy to produce wording on the fly.
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-08-17 Daniel adds "[defaultconstructible]" to table title. 408 depends upon this issue. ]
[ 2009-08-18 Alisdair adds: ]
Looking at the proposed table in this issue, it really needs two rows:
Table 33: DefaultConstructible requirements [defaultconstructible] expression post-condition T t; t is default-initialized. T{} Object of type T is value-initialized. Note I am using the new brace-initialization syntax that is unambiguous in all use cases (no most vexing parse.)
[ 2009-10-03 Daniel adds: ]
The suggested definition T{} describing it as value-initialization is wrong, because it belongs to list-initialization which would - as the current rules are - always prefer a initializer-list constructor over a default-constructor. I don't consider this as an appropriate definition of DefaultConstructible. My primary suggestion is to ask core, whether the special case T{} (which also easily leads to ambiguity situations for more than one initializer-list in a class) would always prefer a default-constructor - if any - before considering an initializer-list constructor or to provide another syntax form to prefer value-initialization over list-initialization. If that fails I would fall back to suggest to use the expression T() instead of T{} with all it's disadvantages for the meaning of the expression
T t();
[ 2009-10 Santa Cruz: ]
Leave Open. Core is looking to make Alisdair's proposed resolution correct.
Proposed resolution:
In section 20.2.1 [utility.arg.requirements], before table 33, add the following table:
Table 33: DefaultConstructible requirements [defaultconstructible]
|
expression |
post-condition |
|
T
t; |
T is default constructed. |
Rationale:
[ San Francisco: ]
We believe concepts will solve this problem (N2774).
Section: 28.11.4 [re.alg.replace] Status: Open Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2009-10-23
View other active issues in [re.alg.replace].
View all other issues in [re.alg.replace].
View all issues with Open status.
Discussion:
Two overloads of regex_replace() are currently provided:
template <class OutputIterator, class BidirectionalIterator,
class traits, class charT>
OutputIterator
regex_replace(OutputIterator out,
BidirectionalIterator first, BidirectionalIterator last,
const basic_regex<charT, traits>& e,
const basic_string<charT>& fmt,
regex_constants::match_flag_type flags =
regex_constants::match_default);
template <class traits, class charT>
basic_string<charT>
regex_replace(const basic_string<charT>& s,
const basic_regex<charT, traits>& e,
const basic_string<charT>& fmt,
regex_constants::match_flag_type flags =
regex_constants::match_default);
The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
const string s("kitten");
const regex r("en");
cout << regex_replace(s, r, "y") << endl;
The compiler error message will be something like "could not deduce template argument for 'const std::basic_string<_Elem> &' from 'const char[1]'".
Users expect that anything taking a basic_string<charT> can also take a const charT *. In their own code, when they write a function taking std::string (or std::wstring), they can pass a const char * (or const wchar_t *), thanks to basic_string's implicit constructor. Because the regex algorithms are templated on charT, they can't rely on basic_string's implicit constructor (as the compiler error message indicates, template argument deduction fails first).
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.
[ Sophia Antipolis: ]
We note that Boost already has these overloads. However, the proposed wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis as well. We also note that this has impact on match_results::format, which may require further overloads.
[ 2009-07 Frankfurt: ]
Daniel to tweak for us.
[ 2009-07-25 Daniel tweaks both this issue and 727. ]
This is solved by the proposed resolution of 727.
[ 2009-10 Santa Cruz: ]
Leave Open. Though we believe this is solved by the proposed resolution to 727.
Proposed resolution:
Provide additional overloads for regex_replace(): one additional overload of the iterator-based form (taking const charT* fmt), and three additional overloads of the convenience form (one taking const charT* str, another taking const charT* fmt, and the third taking both const charT* str and const charT* fmt). 28.11.4 [re.alg.replace]:
template <class OutputIterator, class BidirectionalIterator, class traits, class charT> OutputIterator regex_replace(OutputIterator out, BidirectionalIterator first, BidirectionalIterator last, const basic_regex<charT, traits>& e, const basic_string<charT>& fmt, regex_constants::match_flag_type flags = regex_constants::match_default); 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);
Section: 28.11.4 [re.alg.replace] Status: Review Submitter: Stephan T. Lavavej Opened: 2007-09-22 Last modified: 2009-10-23
View other active issues in [re.alg.replace].
View all other issues in [re.alg.replace].
View all issues with Review 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.
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.
[ Batavia (2009-05): ]
Bill comments, "We need to look at the depth of this change."
Pete remarks that we are here dealing with a convenience function that saves a user from calling the iterato-based overload.
Move to Open.
[ 2009-07 Frankfurt: ]
Howard to ask Stephan Lavavej to provide wording.
[ 2009-07-17 Stephan provided wording. ]
[ 2009-07-25 Daniel tweaks both this issue and 726. ]
One relevant part of the proposed resolution below suggests to add a new overload of the format member function in the match_results class template that accepts two character pointers defining the begin and end of a format range. A more general approach could have proposed a pair of iterators instead, but the used pair of char pointers reflects existing practice. If the committee strongly favors an iterator-based signature, this could be simply changed. I think that the minimum requirement should be a BidirectionalIterator, but current implementations take advantage (at least partially) of the RandomAccessIterator sub interface of the char pointers.
Suggested Resolution:
[Moved into the proposed resloution]
[ 2009-07-30 Stephan agrees with Daniel's wording. Howard places Daniel's wording in the Proposed Resolution. ]
[ 2009-10 Santa Cruz: ]
Move to Review. Chair is anxious to move this to Ready in Pittsburgh.
Proposed resolution:
Change 28.4 [re.syn] as indicated:
// 28.11.4, function template regex_replace:
template <class OutputIterator, class BidirectionalIterator,
class traits, class charT, class ST, class SA>
OutputIterator
regex_replace(OutputIterator out,
BidirectionalIterator first, BidirectionalIterator last,
const basic_regex<charT, traits>& e,
const basic_string<charT, ST, SA>& 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, class ST, class SA,
class FST, class FSA>
basic_string<charT, ST, SA>
regex_replace(const basic_string<charT, ST, SA>& s,
const basic_regex<charT, traits>& e,
const basic_string<charT, FST, FSA>& fmt,
regex_constants::match_flag_type flags =
regex_constants::match_default);
template <class traits, class charT, class ST, class SA>
basic_string<charT, ST, SA>
regex_replace(const basic_string<charT, ST, SA>& 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, class ST, class SA>
basic_string<charT>
regex_replace(const charT* s,
const basic_regex<charT, traits>& e,
const basic_string<charT, ST, SA>& 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);
Change 28.10 [re.results]/3, class template match_results as indicated:
template <class OutputIter>
OutputIter
format(OutputIter out,
const char_type* fmt_first, const char_type* fmt_last,
regex_constants::match_flag_type flags =
regex_constants::format_default) const;
template <class OutputIter, class ST, class SA>
OutputIter
format(OutputIter out,
const string_typebasic_string<char_type, ST, SA>& fmt,
regex_constants::match_flag_type flags =
regex_constants::format_default) const;
template <class ST, class SA>
string_typebasic_string<char_type, ST, SA>
format(const string_typebasic_string<char_type, ST, SA>& fmt,
regex_constants::match_flag_type flags =
regex_constants::format_default) const;
string_type
format(const char_type* fmt,
regex_constants::match_flag_type flags =
regex_constants::format_default) const;
Insert at the very beginning of 28.10.4 [re.results.form] the following:
template <class OutputIter> OutputIter format(OutputIter out, const char_type* fmt_first, const char_type* fmt_last, regex_constants::match_flag_type flags = regex_constants::format_default) const;1 Requires: The type OutputIter shall satisfy the requirements for an Output Iterator (24.2.2 [output.iterators]).
2 Effects: Copies the character sequence [fmt_first,fmt_last) to OutputIter out. Replaces each format specifier or escape sequence in the copied range with either the character(s) it represents or the sequence of characters within *this to which it refers. The bitmasks specified in flags determines what format specifiers and escape sequences are recognized.
3 Returns: out.
Change 28.10.4 [re.results.form], before p. 1 until p. 3 (according to previous numbering) as indicated:
template <class OutputIter, class ST, class SA> OutputIter format(OutputIter out, conststring_typebasic_string<char_type, ST, SA>& fmt, regex_constants::match_flag_type flags = regex_constants::format_default) const;
Requires: The type OutputIter shall satisfy the requirements for an Output Iterator (24.2.3).
Effects: Copies the character sequence [fmt.begin(),fmt.end()) to OutputIter out. Replaces each format specifier or escape sequence in fmt with either the character(s) it represents or the sequence of characters within *this to which it refers. The bitmasks specified in flags determines what format specifiers and escape sequences are recognized.Returns:
outformat(out, fmt.data(), fmt.data() + fmt.size(), flags).
Change 28.10.4 [re.results.form], before p. 4 until p. 4 (according to previous numbering) as indicated:
template <class ST, class SA>string_typebasic_string<char_type, ST, SA> format(conststring_typebasic_string<char_type, ST, SA>& fmt, regex_constants::match_flag_type flags = regex_constants::format_default) const;Effects:
Returns a copy of the string fmt. Replaces each format specifier or escape sequence in fmt with either the character(s) it represents or the sequence of characters within *this to which it refers. The bitmasks specified in flags determines what format specifiers and escape sequences are recognized.Constructs an empty string result of type basic_string<char_type, ST, SA>, and calls format(back_inserter(result), fmt, flags).Returns: result
At the end of 28.10.4 [re.results.form] insert as indicated:
string_type format(const char_type* fmt, regex_constants::match_flag_type flags = regex_constants::format_default) const;Effects: Constructs an empty string result of type string_type, and calls format(back_inserter(result), fmt, fmt + char_traits<char_type>::length(fmt), flags).
Returns: result
Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
template <class OutputIterator, class BidirectionalIterator, class traits, class charT, class ST, class SA> OutputIterator regex_replace(OutputIterator out, BidirectionalIterator first, BidirectionalIterator last, const basic_regex<charT, traits>& e, const basic_string<charT, ST, SA>& 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);Effects: [..]. If any matches are found then, for each such match, if !(flags & regex_constants::format_no_copy) calls std::copy(m.prefix().first, m.prefix().second, out), and then calls m.format(out, fmt, flags) for the first form of the function and m.format(out, fmt, fmt + char_traits<charT>::length(fmt), flags) for the second form. [..].
Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
template <class traits, class charT, class ST, class SA, class FST, class FSA> basic_string<charT, ST, SA> regex_replace(const basic_string<charT, ST, SA>& s, const basic_regex<charT, traits>& e, const basic_string<charT, FST, FSA>& fmt, regex_constants::match_flag_type flags = regex_constants::match_default); template <class traits, class charT, class ST, class SA> basic_string<charT, ST, SA> regex_replace(const basic_string<charT, ST, SA>& s, const basic_regex<charT, traits>& e, const charT* fmt, regex_constants::match_flag_type flags = regex_constants::match_default);Effects: Constructs an empty string result of type basic_string<charT, ST, SA>, calls regex_replace(back_inserter(result), s.begin(), s.end(), e, fmt, flags), and then returns result.
At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
template <class traits, class charT, class ST, class SA> basic_string<charT> regex_replace(const charT* s, const basic_regex<charT, traits>& e, const basic_string<charT, ST, SA>& 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);Effects: Constructs an empty string result of type basic_string<charT>, calls regex_replace(back_inserter(result), s, s + char_traits<charT>::length(s), e, fmt, flags), and then returns result.
Section: 20.2.1 [utility.arg.requirements] Status: Open Submitter: Howard Hinnant Opened: 2007-10-10 Last modified: 2009-11-08
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
View all issues with Open status.
Discussion:
This issue was split from 672. 672 now just deals with changing the requirements of T in the Swappable requirement from CopyConstructible and CopyAssignable to MoveConstructible and MoveAssignable.
This issue seeks to widen the Swappable requirement to support proxy iterators. Here is example code:
namespace Mine {
template <class T>
struct proxy {...};
template <class T>
struct proxied_iterator
{
typedef T value_type;
typedef proxy<T> reference;
reference operator*() const;
...
};
struct A
{
// heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
void swap(A&);
...
};
void swap(A&, A&);
void swap(proxy<A>, A&);
void swap(A&, proxy<A>);
void swap(proxy<A>, proxy<A>);
} // Mine
...
Mine::proxied_iterator<Mine::A> i(...)
Mine::A a;
swap(*i1, a);
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.
That is, no standard library code needs to change. We simply need to have a more flexible definition of Swappable.
[ Bellevue: ]
While we believe Concepts work will define a swappable concept, we should still resolve this issue if possible to give guidance to the Concepts work.
Would an ambiguous swap function in two namespaces found by ADL break this wording? Suggest that the phrase "valid expression" means such a pair of types would still not be swappable.
Motivation is proxy-iterators, but facility is considerably more general. Are we happy going so far?
We think this wording is probably correct and probably an improvement on what's there in the WP. On the other hand, what's already there in the WP is awfully complicated. Why do we need the two bullet points? They're too implementation-centric. They don't add anything to the semantics of what swap() means, which is there in the post-condition. What's wrong with saying that types are swappable if you can call swap() and it satisfies the semantics of swapping?
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10 Santa Cruz: ]
Leave as Open. Dave to provide wording.
[ 2009-11-08 Howard adds: ]
Updated wording to sync with N3000. Also this issue is very closely related to 594.
Proposed resolution:
Change 20.2.1 [utility.arg.requirements]:
-1- The template definitions in the C++ Standard Library refer to various named requirements whose details are set out in tables 31-38. In these tables, T and V are
is 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, anduv has the value originally held bytwThe 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 MoveConstructible requirements (Table 33) and the MoveAssignable requirements (Table 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(
sw,tv) is valid and has the semantics described in this table.- T is Swappable if T is an array type whose element type is Swappable.
Rationale:
[ post San Francisco: ]
Solved by N2758.
Section: 23 [containers] Status: Open Submitter: Alisdair Meredith Opened: 2008-01-14 Last modified: 2009-10-31
View other active issues in [containers].
View all other issues in [containers].
View all issues with Open status.
Discussion:
It appears most containers declare but do not define a member-swap function.
This is unfortunate, as all overload the swap algorithm to call the member-swap function! (required for swappable guarantees [Table 37] and Container Requirements [Table 87])
Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b), yet for all containers we define swap(a,b) to call a.swap(b) - a circular definition.
A quick survey of clause 23 shows that the following containers provide a definition for member-swap:
array queue stack vector
Whereas the following declare it, but do not define the semantics:
deque list map multimap multiset priority_queue set unordered_map unordered_multi_map unordered_multi_set unordered_set
Suggested resolution:
Provide a definition for each of the affected containers...
[ Bellevue: ]
Move to Open and ask Alisdair to provide wording.
[ 2009-07 Frankfurt: ]
Daniel to provide wording. N2590 is no longer applicable.
[ 2009-07-28 Daniel provided wording. ]
- It assumes that the proposed resolution for 883 is applied, which breaks the circularity of definition between member swap and free swap.
- It uses the notation of the pre-concept allocator trait allocator_propagation_map, which might be renamed after the next refactoring phase of generalized allocators.
- It requires that compare objects, key equal functions and hash functions in containers are swapped via unqualified free swap according to 594.
[ 2009-09-30 Daniel adds: ]
The outcome of this issue should be considered with the outcome of 1198 both in style and in content (e.g. bullet 9 suggests to define the semantic of void priority_queue::swap(priority_queue&) in terms of the member swap of the container).
[ 2009-10 Santa Cruz: ]
Looked at, but took no action on as it overlaps too much with N2982. Waiting for a new draft WP.
[ 2009-10 Santa Cruz: ]
Leave as open. Pablo to provide wording.
[ 2009-10-26 Pablo updated wording. Here is the wording he replaced: ]
Add a new Throws clause just after X [allocator.propagation.map]/5:
static void swap(Alloc& a, Alloc& b);Effects: [..]
Throws: Nothing.
[ This exception requirement is added, such that it's combination with the general container requirements of N2723 [container.requirements.general]/9 make it unambiguously clear that the following descriptions of "swaps the allocators" have the following meaning: (a) This swap is done by calling allocator_propagation_map<allocator_type>::swap and (b) This allocator swap does never propagate an exception ]
Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
For associative containers, no swap function throws an exception unless that exception is thrown by thecopy constructor or copy assignment operatorswap of the container's Pred objects(if any).Change 23.2.5.1 [unord.req.except]/3 as indicated:
For unordered associative containers, no swap function throws an exception unless that exception is thrown by thecopy constructor or copy assignment operatorswap of the container's Hash or Pred objects, respectively(if any).Insert a new paragraph just after 23.3 [sequences]/1:
In addition to being available via inclusion of the <algorithm> header, the swap function templates in 25.3.3 [alg.swap] are also available when the header <queue> is included.[ There is a new issue in process that will suggest a minimum header for swap and move. If this one is provided, this text can be removed and the header dependency should be added to <queue> ]
Add one further clause at the end of 23.3.1.2 [array.special]:
[This part is added, because otherwise array::swap would otherwise contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]
Throws: Nothing, unless one of the element-wise swap calls throws an exception.
In 23.3.2 [deque], class template deque synopsis change as indicated:
void swap(deque<T,Alloc>&);At the end of 23.3.2.3 [deque.modifiers] add as indicated:
void swap(deque& x);Effects: Exchanges the contents and swaps the allocators of *this with that of x.
Complexity: Constant time.
In 23.3.3 [forwardlist], class template forward_list synposis change as indicated:
void swap(forward_list<T,Allocator>&);At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
void swap(forward_list& x);Effects: Exchanges the contents and swaps the allocators of *this with that of x.
Complexity: Constant time.
In 23.3.4 [list], class template list synopsis change as indicated:
void swap(list<T,Allocator>&);At the end of 23.3.4.3 [list.modifiers] add as indicated:
void swap(list& x);Effects: Exchanges the contents and swaps the allocators of *this with that of x.
Complexity: Constant time.
At the end of 23.3.5.2.2 [priqueue.members] add a new prototype description:
void swap(priority_queue& q);Requires: Compare shall satisfy the Swappable requirements ( [swappable]).
[ This requirement is added to ensure that even a user defined swap which is found by ADL for Compare satisfies the Swappable requirements ]
Effects: this->c.swap(q.c); swap(this->comp, q.comp);
Throws: What and if c.swap(q.c) and swap(comp, q.comp) throws.
[ This part is added, because otherwise priority_queue::swap would otherwise contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5 ]
In 23.3.6 [vector], class template vector synopsis change as indicated:
void swap(vector<T,Allocator>&);Change 23.3.6.2 [vector.capacity]/8 as indicated:
void swap(vector<T,Allocator>& x);Effects: Exchanges the contents and capacity() and swaps the allocators of *this with that of x.Insert a new paragraph just before 23.4 [associative]/1:
In addition to being available via inclusion of the <algorithm> header, the swap function templates in 25.3.3 [alg.swap] are also available when any of the headers <map> or <set> are included.
In 23.4.1 [map], class template map synopsis change as indicated:
void swap(map<Key,T,Compare,Allocator>&);At the end of 23.4.1.3 [map.modifiers] add as indicated:
void swap(map& x);Requires: Compare shall satisfy the Swappable requirements ( [swappable]).
[ This requirement is added to ensure that even a user defined swap which is found by ADL for Compare satisfies the Swappable requirements ]
Effects: Exchanges the contents and swaps the allocators of *this with that of x, followed by an unqualified swap of the comparison objects of *this and x.
Complexity: Constant time
In 23.4.2 [multimap], class template multimap synopsis change as indicated:
void swap(multimap<Key,T,Compare,Allocator>&);At the end of 23.4.2.2 [multimap.modifiers] add as indicated:
void swap(multimap& x);Requires: Compare shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and swaps the allocators of *this with that of x, followed by an unqualified swap of the comparison objects of *this and x.
Complexity: Constant time
In 23.4.3 [set], class template set synopsis change as indicated:
void swap(set<Key,Compare,Allocator>&);After section 23.4.3.1 [set.cons] add a new section set modifiers [set.modifiers] and add the following paragraphs:
void swap(set& x);Requires: Compare shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and swaps the allocators of *this with that of x, followed by an unqualified swap of the comparison objects of *this and x.
Complexity: Constant time
In 23.4.4 [multiset], class template multiset synosis, change as indicated:
void swap(multiset<Key,Compare,Allocator>&);After section 23.4.4.1 [multiset.cons] add a new section multiset modifiers [multiset.modifiers] and add the following paragraphs:
void swap(multiset& x);Requires: Compare shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and swaps the allocators of *this with that of x, followed by an unqualified swap of the comparison objects of *this and x.
Complexity: Constant time
Insert a new paragraph just before 23.5 [unord]/1:
In addition to being available via inclusion of the <algorithm> header, the swap function templates in 25.3.3 [alg.swap] are also available when any of the headers <unordered_map> or <unordered_set> are included.After section 23.5.1.2 [unord.map.elem] add a new section unordered_map modifiers [unord.map.modifiers] and add the following paragraphs:
void swap(unordered_map& x);Requires: Hash and Pred shall satisfy the Swappable requirements ( [swappable]).
[ This requirement is added to ensure that even a user defined swap which is found by ADL for Hash and Pred satisfies the Swappable requirements ]
Effects: Exchanges the contents and hash policy and swaps the allocators of *this with that of x, followed by an unqualified swap of the Pred objects and an unqualified swap of the Hash objects of *this and x.
Complexity: Constant time
After section 23.5.2.1 [unord.multimap.cnstr] add a new section unordered_multimap modifiers [unord.multimap.modifiers] and add the following paragraphs:
void swap(unordered_multimap& x);Requires: Hash and Pred shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and hash policy and swaps the allocators of *this with that of x, followed by an unqualified swap of the Pred objects and an unqualified swap of the Hash objects of *this and x
Complexity: Constant time
After section 23.5.3.1 [unord.set.cnstr] add a new section unordered_set modifiers [unord.set.modifiers] and add the following paragraphs:
void swap(unordered_set& x);Requires: Hash and Pred shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and hash policy and swaps the allocators of *this with that of x, followed by an unqualified swap of the Pred objects and an unqualified swap of the Hash objects of *this and x
Complexity: Constant time
After section 23.5.4.1 [unord.multiset.cnstr] add a new section unordered_multiset modifiers [unord.multiset.modifiers] and add the following paragraphs:
void swap(unordered_multiset& x);Requires: Hash and Pred shall satisfy the Swappable requirements ( [swappable]).
Effects: Exchanges the contents and hash policy and swaps the allocators of *this with that of x, followed by an unqualified swap of the Pred objects and an unqualified swap of the Hash objects of *this and x
Complexity: Constant time
[ 2009-10-30 Pablo and Daniel updated wording. ]
Proposed resolution:
[ This resolution is based on the September 2009 WP, N2960, except that it assumes that N2982 and issues 883 and 1232 have already been applied. Note in particular that Table 91 in N2960 is refered to as Table 90 because N2982 removed the old Table 90. This resolution also addresses issue 431. ]
In 23.2.1 [container.requirements.general], replace the a.swap(b) row in table 90, "container requirements" (was table 91 before the application of N2982 to the WP):
a.swap(b)voidswap(a,b)Exchange the contents of a and b.(Note A) swap(a,b)voida.swap(b)(Note A)
Modify the notes immediately following Table 90 in 23.2.1 [container.requirements.general] as follows (The wording below is after the application of N2982 to N2960. The editor might also want to combine Notes A and B into one.):
Notes: the algorithms
swap(),equal() and lexicographical_compare() are defined in Clause 25. Those entries marked "(Note A)" or "(Note B)"shouldhave linear complexity for array and constant complexity for all other standard containers.
In 23.2.1 [container.requirements.general], after paragraph 9, add:
The expression
a.swap(b), for containersaandbof a standard container type other thanarray, exchanges the values ofaandbwithout invoking any move, copy, or swap operations on the individual container elements. AnyCompare,Pred, orHashfunction objects belonging toaandbshall satisfy theSwappablerequirements and are exchanged by unqualified calls to non-memberswap. Ifallocator_traits<allocator_type>::propagate_on_container_swap::value == true, then the allocators ofaandbare also exchanged using an unqualified call to non-memberswap. Otherwise, the behavior is undefined unlessa.get_allocator() == b.get_allocator(). Each iterator refering to an element in one container before the swap shall refer to the same element in the other container after the swap. It is unspecified whether an iterator with valuea.end()before the swap will have valueb.end()after the swap. In addition to being available via inclusion of the<utility>header, theswapfunction template in 25.3.3 [alg.swap] is also available within the definition of every standard container'sswapfunction.
[ Note to the editor: Paragraph 2 starts with a sentence fragment, clearly from an editing or source-control error. ]
Modify 23.2.4.1 [associative.reqmts.except] as follows:
23.2.4.1 Exception safety guarantees 23.2.4.1 [associative.reqmts.except]
For associative containers, no
clear()function throws an exception.erase(k)does not throw an exception unless that exception is thrown by the container'sobject (if any).PredCompareFor associative containers, if an exception is thrown by any operation from within an
insert()function inserting a single element, theinsert()function has no effect.For associative containers, no
swapfunction throws an exception unless that exception is thrown by thecopy constructor or copy assignment operatorswap of the container'sobject (if any).PredCompare
Modify 23.2.5.1 [unord.req.except], paragraph 3 as follows:
For unordered associative containers, no
swapfunction throws an exception unless that exception is thrown by thecopy constructor or copy assignment operatorswap of the container'sHashorPredobject (if any).
Modify section 23.3.1.2 [array.special]:
array specialized algorithms 23.3.1.2 [array.special]
template <class T, size_t N> void swap(array<T,N>& x,array<T,N>& y);Effects:
swap_ranges(x.begin(), x.end(), y.begin() );x.swap(y);
Add a new section after 23.3.1.5 [array.fill] (Note to the editor: array::fill make use of a concept requirement that must be removed or changed to text.):
array::swap [array.swap]
void swap(array& y);Effects:
swap_ranges(this->begin(), this->end(), y.begin() );Throws: Nothing unless one of the element-wise swap calls throws an exception.
[Note: Unlike other containers'
swapfunctions,array::swaptakes linear, not constant, time, may exit via an exception, and does not cause iterators to become associated with the other container. — end note]
Insert a new paragraph just after 23.3.5 [container.adaptors]/1:
For container adaptors, no
swapfunction throws an exception unless that exception is thrown by the swap of the adaptor'sContainerorCompareobject (if any).
Section: 25.4.4 [alg.merge] Status: Review Submitter: Daniel Krügler Opened: 2008-01-25 Last modified: 2009-10-22
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.4.4 [alg.merge] in N2461 have no Requires element and the Effects element contains some requirements, which is probably editorial. Worse is that:
[ Post Summit Alisdair adds: ]
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.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).
[ Post Summit Daniel adds: ]
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.
[ Batavia (2009-05): ]
Pete points out the existing wording in [algorithms]/4 that permits the use of + in algorithm specifications.
Alisdair points out that that wording may not apply to input iterators.
Move to Review.
[ 2009-07 Frankfurt: ]
Move to Ready.
[ 2009-08-23 Daniel reopens: ]
The proposed wording must be rephrased, because the part
for every iterator i in [result,last) other than result, the condition *i < *(i - 1) or, respectively, comp(*i, *(i - 1)) will be false"isn't meaningful, because the range [result,last) is that of a pure OutputIterator, which is not readable in general.
[Howard: Proposed wording updated by Daniel, status moved from Ready to Review.]
[ 2009-10 Santa Cruz: ]
Matt has some different words to propose. Those words have been moved into the proposed wording section, and the original proposed wording now appears here:
In 25.4.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)) , such that resulting range will be sorted in non-decreasing order; that is for every pair of iterators i and j of either input ranges, where *i was copied to the output range before *j was copied to the output range, the condition *j < *i or, respectively, comp(*j, *i) will be false.Requires:The resulting range shall not overlap with either of the original ranges.
The list will be sorted in non-decreasing order according to the ordering defined by comp; that is, for every iterator i in [first,last) other than first, the condition *i < *(i - 1) or comp(*i, *(i - 1)) will be false.
Proposed resolution:
Effects: Merges two sorted ranges [first1,last1) and
[first2,last2) into the range [result, result + (last1 -
first1) + (last2 - first2)).
Effects: Copies all the elements of the two sorted ranges [first1,last1) and [first2,last2) into the range [result, result_last), where result_last is result + (last1 - first1) + (last2 - first2), such that the resulting range satisfies is_sorted(result, result_last) or is_sorted(result, result_last, comp), respectively.
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.
Section: 20.5 [tuple] Status: Open Submitter: Lawrence Crowl Opened: 2008-02-18 Last modified: 2009-10-23
View all other issues in [tuple].
View all issues with Open status.
Discussion:
Classes with trivial special member functions are inherently more efficient than classes without such functions. This efficiency is particularly pronounced on modern ABIs that can pass small classes in registers. Examples include value classes such as complex numbers and floating-point intervals. Perhaps more important, though, are classes that are simple collections, like pair and tuple. When the parameter types of these classes are trivial, the pairs and tuples themselves can be trivial, leading to substantial performance wins.
The current working draft make specification of trivial functions (where possible) much easer through defaulted and deleted functions. As long as the semantics of defaulted and deleted functions match the intended semantics, specification of defaulted and deleted functions will yield more efficient programs.
There are at least two cases where specification of an explicitly defaulted function may be desirable.
First, the std::pair template has a non-trivial default constructor, which prevents static initialization of the pair even when the types are statically initializable. Changing the definition to
pair() = default;
would enable such initialization. Unfortunately, the change is not semantically neutral in that the current definition effectively forces value initialization whereas the change would not value initialize in some contexts.
** Does the committee confirm that forced value initialization was the intent? If not, does the committee wish to change the behavior of std::pair in C++0x?
Second, the same default constructor issue applies to std::tuple. Furthermore, the tuple copy constructor is current non-trivial, which effectively prevents passing it in registers. To enable passing tuples in registers, the copy constructor should be make explicitly defaulted. The new declarations are:
tuple() = default; tuple(const tuple&) = default;
This changes is not implementation neutral. In particular, it prevents implementations based on pointers to the parameter types. It does however, permit implementations using the parameter types as bases.
** How does the committee wish to trade implementation efficiency versus implementation flexibility?
[ Bellevue: ]
General agreement; the first half of the issue is NAD.
Before voting on the second half, it was agreed that a "Strongly Favor" vote meant support for trivial tuples (assuming usual requirements met), even at the expense of other desired qualities. A "Weakly Favor" vote meant support only if not at the expense of other desired qualities.
Concensus: Go forward, but not at expense of other desired qualities.
It was agreed to Alisdair should fold this work in with his other pair/tuple action items, above, and that issue 801 should be "open", but tabled until Alisdair's proposals are disposed of.
[ 2009-05-27 Daniel adds: ]
This is partly solved by 1117.
[ 2009-07 Frankfurt: ]
Wait for dust to settle from fixing exception safety problem with rvalue refs.
[ 2009-07-20 Alisdair adds: ]
Basically, this issue is what should we do with the default constructor for pairs and tuples of trivial types. The motivation of the issue was to force static initialization rather than dynamic initialization, and was rejected in the case of pair as it would change the meaning of existing programs. The advice was "do the best we can" for tuple without changing existing meaning.
Frankfurt seems to simply wait and see the resolution on no-throw move constructors, which (I believe) is only tangentially related to this issue, but as good as any to defer until Santa Cruz.
Looking again now, I think constant (static) initialization for pair can be salvaged by making the default construct constexpr. I have a clarification from Core that this is intended to work, even if the constructor is not trivial/constexpr, so long as no temporaries are implied in the process (even if elided).
[ 2009-10 Santa Cruz: ]
Leave as open. Alisdair to provide wording.
Proposed resolution:
Section: 20.3.4 [pairs] Status: Open Submitter: Doug Gregor Opened: 2008-03-14 Last modified: 2009-10-23
View other active issues in [pairs].
View all other issues in [pairs].
View all issues with Open status.
Discussion:
#include <utility>
int main()
{
std::pair<char *, char *> p (0,0);
}
I just got a bug report about that, because it's valid C++03, but not C++0x. The important realization, for me, is that the emplace proposal---which made push_back variadic, causing the push_back(0) issue---didn't cause this break in backward compatibility. The break actually happened when we added this pair constructor as part of adding rvalue references into the language, long before variadic templates or emplace came along:
template<class U, class V> pair(U&& x, V&& y);
Now, concepts will address this issue by constraining that pair constructor to only U's and V's that can properly construct "first" and "second", e.g. (from N2322):
template<class U , class V > requires Constructible<T1, U&&> && Constructible<T2, V&&> pair(U&& x , V&& y );
[ San Francisco: ]
Suggested to resolve using pass-by-value for that case.
Side question: Should pair interoperate with tuples? Can construct a tuple of a pair, but not a pair from a two-element tuple.
Related to 885.
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10 Santa Cruz: ]
Leave as open. Howard to provide wording.
Proposed resolution:
Rationale:
[ San Francisco: ]
Solved by N2770.
Section: 20.7.15.2.4 [func.wrap.func.inv] Status: Open Submitter: Alisdair Meredith Opened: 2008-03-16 Last modified: 2009-10-23
View all issues with Open status.
Discussion:
std::function and reference_closure should use "perfect forwarding" as described in the rvalue core proposal.
[ Sophia Antipolis: ]
According to Doug Gregor, as far as std::function is concerned, perfect forwarding can not be obtained because of type erasure. Not everyone agreed with this diagnosis of forwarding.
[ 2009-05-01 Howard adds: ]
Sebastian Gesemann brought to my attention that the CopyConstructible requirement on function's ArgTypes... is an unnecessary restriction.
template<Returnable R, CopyConstructible... ArgTypes> class function<R(ArgTypes...)> ...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...); }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.
Furthermore we need to mandate that the invoker is coded as:
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)...); }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.
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:
#include <functional> #include <memory> #include <cassert> std::unique_ptr<int> f(std::unique_ptr<int> p, int& i) { ++i; return std::move(p); } 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); }[ Tested in pre-concepts rvalue-ref-enabled compiler. ]
In the example above, the first ArgType is unique_ptr<int> and the second ArgType is int&. Both must work!
[ 2009-05-27 Daniel adds: ]
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"
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:
function<R(ArgTypes...)>::operator()(ArgTypes... arg) const { if (f_ == 0) throw bad_function_call(); return (*f_)(std::forward<ArgTypes>(arg)...); }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?
[ 2009-07 Frankfurt: ]
Leave this open and wait until concepts are removed from the Working Draft so that we know how to write the proposed resolution in terms of diffs to otherwise stable text.
[ 2009-10 Santa Cruz: ]
Leave as open. Howard to provide wording. Howard welcomes any help.
Proposed resolution:
Section: 20.7.11.1.3 [func.bind.bind] Status: Ready Submitter: Stephan T. Lavavej Opened: 2008-02-08 Last modified: 2009-11-07
View other active issues in [func.bind.bind].
View all other issues in [func.bind.bind].
View all issues with Ready status.
Discussion:
Library Issue 527 notes that bind(f, t1, ..., tN) should be nofail when f, t1, ..., tN have nofail copy ctors.
However, no guarantees are provided for the copy ctor of the functor returned by bind(). (It's guaranteed to have a copy ctor, which can throw implementation-defined exceptions: bind() returns a forwarding call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. Everything without an exception-specification may throw implementation-defined exceptions unless otherwise specified, C++03 17.4.4.8/3.)
Should the nofail guarantee requested by Library Issue 527 be extended to cover both calling bind() and copying the returned functor?
[ Howard adds: ]
tuple construction should probably have a similar guarantee.
[ 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.
[ 2009-07 Frankfurt: ]
Related to 817 (see below). Leave Open.
[ 2009-10 Santa Cruz: ]
Move to Ready. Decoupling from issue 817.
Proposed resolution:
Add a new sentence to the end of paragraphs 2 and 4 of 20.7.11.1.3 [func.bind.bind]:
-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.
...
-5- 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.
Section: 20.7.11.1.3 [func.bind.bind] Status: Open Submitter: Howard Hinnant Opened: 2008-03-17 Last modified: 2009-11-08
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
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.
This issue is related to issue 816.
US 72:
bind should support move-only functors and bound arguments.
JP 38:
add the move requirement for bind's return type.
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));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.
Add the requirement of move to get rid of this useless copy.
And also, add the MoveConstructible as well as CopyConstructible.
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.
[ San Francisco: ]
Howard to provide wording.
[ Post Summit Alisdair and Howard provided wording. ]
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.11.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.
[ Batavia (2009-05): ]
We were going to recommend moving this issue to Tentatively Ready until we noticed potential overlap with issue 816 (q.v.).
Move to Open, and recommend both issues be considered together (and possibly merged).
[ 2009-07 Frankfurt: ]
The proposed resolution uses concepts. Leave Open.
[ 2009-10 Santa Cruz: ]
Leave as Open. Howard to provide deconceptified wording.
[ 2009-11-07 Howard updates wording. ]
Proposed resolution:
Change 20.7 [function.objects] p2:
template<class Fn, class...TypesBoundArgs> unspecified bind(Fn&&,TypesBoundArgs&&...); template<class R, class Fn, class...TypesBoundArgs> unspecified bind(Fn&&,TypesBoundArgs&&...);
Change 20.7.11.1.3 [func.bind.bind]:
Within this clause:
- Let FD be a synonym for the type decay<F>::type.
- Let fd be an lvalue of type FD constructed from std::forward<F>(f).
- Let Ti be a synonym for the ith type in the parameter pack BoundArgs.
- Let TiD be a synonym for the type decay<Ti>::type.
- Let ti be the ith argument in bound_args.
- Let tid be an lvalue of type TiD constructed from std::forward<Ti>(ti).
template<class F, class... BoundArgs> unspecified bind(F&& f, BoundArgs&&... bound_args);-1- Requires: is_constructible<FD, F>::value shall be true. is_constructible<TiD, Ti>::value shall be true.
F and each Ti in BoundArgs shall be CopyConstructible.INVOKE(fd, w1, w2, ..., wN) (20.7.2 [func.require]) shall be a valid expression for some values w1, w2, ..., wN, where N == sizeof...(bound_args).-2- Returns: A forwarding call wrapper g with a weak result type (20.7.2 [func.require]). The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv (V1, V2, ..., VN)>::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 FD or any of the types TiD throw an exception.
-3- Throws: Nothing unless the
copyconstructionorofFfd or of one of the values tidtypes in the BoundArgs... pack expansionthrows an exception.Remarks: The unspecified return type shall be MoveConstructible. If all of FD and TiD are CopyConstructible then the unspecified return type shall be CopyConstructible. [Note: This implies that all of FD and TiD shall be MoveConstructible — end note]
template<class R, class F, class... BoundArgs> unspecified bind(F&& f, BoundArgs&&... bound_args);-4- Requires: is_constructible<FD, F>::value shall be true. is_constructible<TiD, Ti>::value shall be true.
F and each Ti in BoundArgs shall be CopyConstructible.INVOKE(fd, w1, w2, ..., wN) shall be a valid expression for some values w1, w2, ..., wN, where N == sizeof...(bound_args).-5- 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(fd, 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 FD or any of the types TiD throw an exception.
-6- Throws: Nothing unless the
copyconstructionorofFfd or of one of the values tidtypes in the BoundArgs... pack expansionthrows an exception.Remarks: The unspecified return type shall be MoveConstructible. If all of FD and TiD are CopyConstructible then the unspecified return type shall be CopyConstructible. [Note: This implies that all of FD and TiD shall be MoveConstructible — end note]
-7- The values of the bound arguments v1, v2, ..., vN and their corresponding types V1, V2, ..., VN depend on the types TiD derived from
of the corresponding argument ti in bound_args of type Ti in BoundArgs inthe call to bind and the cv-qualifiers cv of the call wrapper g as follows:
- if
tiTiDis ofhas type reference_wrapper<T> the argument is tid.get() and its type Vi is T&;- if the value of std::is_bind_expression<TiD>::value is true the argument is tid(u1, u2, ..., uM) and its type Vi is result_of<TiD cv (U1&, U2&, ..., UM&)>::type;
- if the value j of std::is_placeholder<TiD>::value is not zero the argument is std::forward<Uj>(uj) and its type Vi is Uj&&;
- otherwise the value is tid and its type Vi is TiD cv &.
Section: 18.8.6 [except.nested] Status: Open Submitter: Alisdair Meredith Opened: 2008-03-25 Last modified: 2009-10-23
View other active issues in [except.nested].
View all other issues in [except.nested].
View all issues with Open status.
Discussion:
Looking at the wording I submitted for rethrow_if_nested, I don't think I got it quite right.
The current wording says:
template <class E> void rethrow_if_nested(const E& e);Effects: Calls e.rethrow_nested() only if e is publicly derived from nested_exception.
This is trying to be a bit subtle, by requiring e (not E) to be publicly derived from nested_exception the idea is that a dynamic_cast would be required to be sure. Unfortunately, if e is dynamically but not statically derived from nested_exception, e.rethrow_nested() is ill-formed.
[ San Francisco: ]
Alisdair was volunteered to provide wording.
[ 2009-10 Santa Cruz: ]
Leave as Open. Alisdair to provide wording.
Proposed resolution:
Section: 20.8.14.2 [unique.ptr.single] Status: Open Submitter: Daniel Krügler Opened: 2008-05-14 Last modified: 2009-10-26
View other active issues in [unique.ptr.single].
View all other issues in [unique.ptr.single].
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:
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.
[ 2009-07 Frankfurt: ]
Move to Ready.
[ 2009-10-15 Alisdair pulls from Ready: ]
I hate to pull an issue out of Ready status, but I don't think 834 is fully baked yet.
For reference the proposed resolution is to add the following words:
unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well defined behavior, and shall not throw exceptions.This leaves me with a big question : which operations?
Are all pointer operations required to be nothrow, including operations that have nothing to do with interactions with unique_ptr? This was much simpler with concepts where we could point to operations within a certain concept, and so nail down the interactions.
[ 2009-10-15 Daniel adds: ]
I volunteer to prepare a more fine-grained solution, but I would like to ask for feedback that helps me doing so. If this question is asked early in the meeting I might be able to fix it within the week, but I cannot promise that now.
[ 2009-10 Santa Cruz: ]
Leave in open. Daniel to provide wording as already suggested.
Proposed resolution:
Add the following sentence just at the end of the newly proposed 20.8.14.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.
Section: 27.5.4.2 [basic.ios.members] Status: Open Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-10-20
View other active issues in [basic.ios.members].
View all other issues in [basic.ios.members].
View all issues with Open status.
Discussion:
The fix for issue 581, now integrated into the working paper, overlooks a couple of minor problems.
First, being an unformatted function once again, flush()
is required to create a sentry object whose constructor must, among
other things, flush the tied stream. When two streams are tied
together, either directly or through another intermediate stream
object, flushing one will also cause a call to flush() on
the other tied stream(s) and vice versa, ad infinitum. The program
below demonstrates the problem.
Second, as Bo Persson notes in his
comp.lang.c++.moderated post,
for streams with the unitbuf flag set such
as std::stderr, the destructor of the sentry object will
again call flush(). This seems to create an infinite
recursion for std::cerr << std::flush;
#include <iostream>
int main ()
{
std::cout.tie (&std::cerr);
std::cerr.tie (&std::cout);
std::cout << "cout\n";
std::cerr << "cerr\n";
}
[ Batavia (2009-05): ]
We agree with the proposed resolution. Move to Review.
[ 2009-05-26 Daniel adds: ]
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.
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().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)?
[ 2009-07 Frankfurt: ]
Daniel volunteered to modify the proposed resolution to address his two questions.
Move back to Open.
[ 2009-07-26 Daniel provided wording. Moved to Review. ]
[ 2009-10-13 Daniel adds: ]
This proposed wording is written to match the outcome of 397.
[ 2009 Santa Cruz: ]
Move to Open. Martin to propose updated wording that will also resolve issue 397 consistently.
Proposed resolution:
[ based on N2960 numbering ]
Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
Requires: If (tiestr != 0) is true, tiestr must not be reachable by traversing the linked list of tied stream objects starting from tiestr->tie().
Change 27.7.2.4 [ostream::sentry]/4 as indicated:
If ((os.flags() & ios_base::unitbuf) && !uncaught_exception()&& os.good()) is true, callsos.flush()os.rdbuf()->pubsync(). If that function returns -1 sets badbit in os.rdstate() without propagating an exception.
money_base::space and
money_base::none on money_get
Section: 22.4.6.1.2 [locale.money.get.virtuals] Status: Ready Submitter: Martin Sebor Opened: 2008-05-17 Last modified: 2009-10-21
View all other issues in [locale.money.get.virtuals].
View all issues with Ready status.
Duplicate of: 670
Discussion:
In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
Wherespaceornoneappears 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:
- where
money_base::spaceappears in the format, at least one space is required, and- where
money_base::noneappears in the format, space is allowed but not required.
The other is that:
where eithermoney_base::spaceormoney_base::noneappears in the format, white space is optional.
[ San Francisco: ]
Martin will revise the proposed resolution.
[ 2009-07 Frankfurt: ]
There is a noun missing from the proposed resolution. It's not clear that the last sentence would be helpful, even if the word were not missing:
In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.Strike this sentence and move to Review.
[ Howard: done. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
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:
Whenmoney_base::spaceormoney_base::noneappears 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::spaceappears in any of the initial elements of the format pattern, at least one white space character is required. Wheremoney_base::noneappears in any of the initial elements of the format pattern, white space is allowed but not required. If(str.flags() & str.showbase)isfalse, ...
Section: 20.8.14.1.1 [unique.ptr.dltr.dflt] Status: Ready Submitter: Howard Hinnant Opened: 2008-06-18 Last modified: 2009-10-21
View all issues with Ready status.
Discussion:
No relationship between U and T in the converting constructor for default_delete template.
Requirements: U* is convertible to T* and has_virtual_destructor<T>; the latter should also become a concept.
Rules out cross-casting.
The requirements for unique_ptr conversions should be the same as those on the deleter.
[ Howard adds 2008-11-26: ]
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 }I've removed "&& HasVirtualDestructor<T>" from the requires clause in the proposed wording.
[ Post Summit: ]
Alisdair: This issue has to stay in review pending a paper constraining unique_ptr.
Consensus: We agree with the resolution, but unique_ptr needs to be constrained, too.
Recommend Keep in Review.
[ Batavia (2009-05): ]
Keep in Review status for the reasons cited.
[ 2009-07 Frankfurt: ]
The proposed resolution uses concepts. Howard needs to rewrite the proposed resolution.
Move back to Open.
[ 2009-07-26 Howard provided rewritten proposed wording and moved to Review. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Add after 20.8.14.1.1 [unique.ptr.dltr.dflt], p1:
template <class U> default_delete(const default_delete<U>& other);-1- Effects: ...
Remarks: This constructor shall participate in overload resolution if and only if U* is implicitly convertible to T*.
Section: 26 [numerics] Status: Ready Submitter: Lawrence Crowl Opened: 2008-06-23 Last modified: 2009-10-23
View all other issues in [numerics].
View all issues with Ready 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.
[ San Francisco: ]
Nick: I think we already say that these functions do not introduce data races; see 17.6.5.6/20
Pete: there's more to it than not introducing data races; are these states maintained per thread?
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.
Nick: POSIX has a list of not-safe functions. All other functions are implicitly thread safe.
Lawrence is to form a group between meetings to attack this issue. Nick and Tom volunteered to work with Lawrence.
Move to Open.
[ Post Summit: ]
Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
Nick: Default wording seems to cover this? Hole in POSIX, these functions need to be added to list of thread-unsafe functions.
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."
Hans: Suggest the following wording: "The floating point environment is maintained per-thread."
Walter: Any other examples of state being thread safe that are not already covered elsewhere?
Have thread unsafe functions paper which needs to be updated. Should just fold in 26.3 [cfenv] functions.
Recommend Open. Lawrence instead suggests leaving it open until we have suitable wording that may or may not include the thread local commentary.
[ 2009-09-23 Hans provided wording. ]
If I understand the history correctly, Nick, as the Posix liaison, should probably get a veto on this, since I think it came from Posix (?) via WG14 and should probably really be addressed there (?). But I think we are basically in agreement that there is no other sane way to do this, and hence we don't have to worry too much about stepping on toes. As far as I can tell, this same issue also exists in the latest Posix standard (?).
[ 2009-10 Santa Cruz: ]
Moved to Ready.
Proposed resolution:
Add at the end of 26.3.1 [cfenv.syn]:
2 The header defines all functions, types, and macros the same as C99 7.6.
A separate floating point environment shall be maintained for each thread. Each function accesses the environment corresponding to its calling thread.
Section: 23.2 [container.requirements] Status: Open Submitter: Daniel Krügler Opened: 2008-06-24 Last modified: 2009-10-24
View other active issues in [container.requirements].
View all other issues in [container.requirements].
View all issues with Open status.
Discussion:
Table 89, Container requirements, defines operator== in terms of the container member function size() and the algorithm std::equal:
== is an equivalence relation. a.size() == b.size() && equal(a.begin(), a.end(), b.begin()
The new container forward_list does not provide a size member function by design but does provide operator== and operator!= without specifying it's semantic.
Other parts of the (sequence) container requirements do also depend on size(), e.g. empty() or clear(), but this issue explicitly attempts to solve the missing EqualityComparable specification, because of the special design choices of forward_list.
I propose to apply one of the following resolutions, which are described as:
Both proposal choices are discussed, the preferred choice of the author is to apply (A).
[ San Francisco: ]
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.
[ post San Francisco: ]
Martin provided wording for Option C.
[ 2009-07 Frankfurt ]
Other operational semantics (see, for example, Tables 82 and 83) are written in terms of a container's size() member. Daniel to update proposed resolution C.
[ Howard: Commented out options A and B. ]
[ 2009-07-26 Daniel updated proposed resolution C. ]
[ 2009-10 Santa Cruz: ]
Mark NAD Editorial. Addressed by N2986.
[ 2009-10 Santa Cruz: ]
Reopened. N2986 was rejected in full committee on procedural grounds.
Proposed resolution:
Option (C):
[ The changes are relative to N2914 but concept-free. ]
In 23.2.1 [container.requirements.general] change Table 80 -- Container requirements as indicated:
Change the text in the Assertion/note column in the row for "X u;" as follows:
post: u.size() == 0empty() == trueChange the text in the Assertion/note column in the row for "X();" as follows:
X().size() == 0empty() == trueChange the text in the Operational Semantics column in the row for "a == b" as follows:
== is an equivalence relation.a.size()distance(a.begin(), a.end()) ==b.size()distance(b.begin(), b.end()) && equal(a.begin(), a.end(), b.begin())Change the text in the Operational Semantics column in the row for "a.size()" as follows:
a.end() - a.begin()distance(a.begin(), a.end())Change the text in the Operational Semantics column in the row for "a.max_size()" as follows:
size()distance(begin(), end()) of the largest possible containerChange the text in the Operational Semantics column in the row for "a.empty()" as follows:
a.size() == 0a.begin() == a.end()In 23.2.1 [container.requirements.general] change Table 82 -- Allocator-aware container requirements as indicated:
Change the text in the Assertion/note column in the row for "X() / X u;" as follows:
Requires: A is DefaultConstructible post:u.size() == 0u.empty() == true, get_allocator() == A()Change the text in the Assertion/note column in the row for "X(m) / X u(m);" as follows:
post:u.size() == 0u.empty() == true, get_allocator() == mIn 23.2.3 [sequence.reqmts] change Table 83 -- Sequence container requirements as indicated:
Change the text in the Assertion/note column in the row for "X(n, t) / X a(n, t)" as follows:
post:size()distance(begin(), end()) == n [..]Change the text in the Assertion/note column in the row for "X(i, j) / X a(i, j)" as follows:
[..] post:size() == distance between i and jdistance(begin(), end()) == distance(i, j) [..]Change the text in the Assertion/note column in the row for "a.clear()" as follows:
a.erase(a.begin(), a.end()) post:size() == 0a.empty() == trueIn 23.2.4 [associative.reqmts] change Table 85 -- Associative container requirements as indicated:
[ Not every occurrence of size() was replaced, because all current associative containers have a size. The following changes ensure consistency regarding the semantics of "erase" for all tables and adds some missing objects ]
Change the text in the Complexity column in the row for "a.insert(i, j)" as follows:
N log(a.size() + N)(N is the distance from i to j)where N == distance(i, j)Change the text in the Complexity column in the row for "a.erase(k)" as follows:
log(a.size()) + a.count(k)Change the text in the Complexity column in the row for "a.erase(q1, q2)" as follows:
log(a.size()) + N where Nis the distance from q1 to q2== distance(q1, q2).Change the text in the Assertion/note column in the row for "a.clear()" as follows:
a.erase(a.begin(),a.end()) post:size() == 0a.empty() == trueChange the text in the Complexity column in the row for "a.clear()" as follows:
linear in a.size()Change the text in the Complexity column in the row for "a.count(k)" as follows:
log(a.size()) + a.count(k)In 23.2.5 [unord.req] change Table 87 -- Unordered associative container requirements as indicated:
[ The same rational as for Table 85 applies here ]
Change the text in the Assertion/note column in the row for "a.clear()" as follows:
[..] Post: a.size() == 0empty() == true
Section: 25.3.6 [alg.fill], 25.3.7 [alg.generate] Status: Ready Submitter: Daniel Krügler Opened: 2008-07-13 Last modified: 2009-10-23
View all issues with Ready 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:
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);
In both cases the minimum requirements on the iterator are OutputIterator, which means according to the requirements of 24.2.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.
[ 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.
Move to Open.
[ 2009-07 Frankfurt ]
We have a consensus for moving forward on this issue, but Daniel needs to deconceptify it.
[ 2009-07-25 Daniel provided non-concepts wording. ]
[ 2009-10 Santa Cruz: ]
Moved to Ready.
Proposed resolution:
Replace the current declaration of fill_n in 25 [algorithms]/2, header <algorithm> synopsis and in 25.3.6 [alg.fill] by
template<class OutputIterator, class Size, class T>voidOutputIterator fill_n(OutputIterator first, Size n, const T& value);
Just after the effects clause add a new returns clause saying:
Returns: For fill_n and positive n, returns first + n. Otherwise returns first for fill_n.
Replace the current declaration of generate_n in 25 [algorithms]/2, header <algorithm> synopsis and in 25.3.7 [alg.generate] by
template<class OutputIterator, class Size, class Generator>voidOutputIterator generate_n(OutputIterator first, Size n, Generator gen);
Just after the effects clause add a new returns clause saying:
For generate_n and positive n, returns first + n. Otherwise returns first for generate_n.
Section: 23 [containers] Status: Ready Submitter: Alberto Ganesh Barbati Opened: 2008-07-22 Last modified: 2009-10-20
View other active issues in [containers].
View all other issues in [containers].
View all issues with Ready 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.
[ San Francisco: ]
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.
This issue relates to Issue 886 tuple construction
[ 2009-07 Frankfurt ]
The proposed resolution is incomplete.
Move to Tentatively NAD Future. Howard will contact Ganesh for wording. If wording is forthcoming, Howard will move it back to Review.
[ 2009-07-18 Ganesh updated the proposed wording. ]
Howard: Moved back to Review. Note that 20.2.1 [utility.arg.requirements] refers to a section that is not in the current working paper, but does refer to a section that we expect to reappear after the de-concepts merge. This was a point of confusion we did not recognize when we reviewed this issue in Frankfurt.
Howard: Ganesh also includes a survey of places in the WP surveyed for changes of this nature and purposefully not treated:
Places where changes are not being proposed
In the following paragraphs, we are not proposing changes because it's not clear whether we actually prefer value-initialization over default-initialization (now partially covered by 1012):
20.8.14.2.1 [unique.ptr.single.ctor] para 3 e 7
24.5.1.3.1 [reverse.iter.cons] para 1
24.5.3.3.1 [move.iter.op.const] para 1
In the following paragraphs, the expression "default constructed" need not be changed, because the relevant type does not depend on a template parameter and has a user-provided constructor:
[func.referenceclosure.invoke] para 12, type: reference_closure
30.3.1.2 [thread.thread.constr] para 30, type: thread
30.3.1.5 [thread.thread.member] para 52, type: thread_id
30.3.2 [thread.thread.this], para 1, type: thread_id
[ 2009-08-18 Daniel adds: ]
I have no objections against the currently suggested changes, but I also cross-checked with the list regarding intentionally excluded changes, and from this I miss the discussion of
21.4.1 [string.require]/2:
"[..] The Allocator object used shall be a copy of the Allocator> object passed to the basic_string object's constructor or, if the constructor does not take an Allocator argument, a copy of a default-constructed Allocator object."N2723, X [rand.req.eng], Table 109, expression "T()":
Pre-/post-condition: "Creates an engine with the same initial state as all other default-constructed engines of type X."as well as in 26.5.5 [rand.predef]/1-9 (N2914), 26.5.7.1 [rand.util.seedseq]/3, 27.7.1.1.1 [istream.cons]/3, 27.7.2.2 [ostream.cons]/9 (N2914), 28.13 [re.grammar]/2, 30.3.1.4 [thread.thread.assign]/1 (N2914),
[ Candidates for the "the expression "default constructed" need not be changed" list ]
I'm fine, if these would be added to the intentionally exclusion list, but mentioning them makes it easier for other potential reviewers to decide on the relevance or not-relevance of them for this issue.
I suggest to remove the reference of [func.referenceclosure.invoke] in the "it's not clear" list, because this component does no longer exist.
I also suggest to add a short comment that all paragraphs in the resolution whether they refer to N2723 or to N2914 numbering, because e.g. "Change 23.3.2.1 [deque.cons] para 5" is an N2723 coordinate, while "Change 23.3.2.2 [deque.capacity] para 1" is an N2914 coordinate. Even better would be to use one default document for the numbering (probably N2914) and mention special cases (e.g. "Change 20.2.1 [utility.arg.requirements] para 2" as referring to N2723 numbering).
[ 2009-08-18 Alisdair adds: ]
I strongly believe the term "default constructed" should not appear in the library clauses unless we very clearly define a meaning for it, and I am not sure what that would be.
In those cases where we do not want to replace "default constructed" with "vale initialized" we should be using "default initialized". If we have a term that could mean either, we reduce portability of programs.
I have not done an exhaustive review to clarify if that is a vendor freedom we have reason to support (e.g. value-init in debug, default-init in release) so I may yet be convinced that LWG has reason to define this new term of art, but generally C++ initialization is confusing enough without supporting further ill-defined terms.
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Change 20.2.1 [utility.arg.requirements] para 2:
In general, a default constructor is not required. Certain container class member function signatures specifythe default constructorT() as a default argument. T() shall be a well-defined expression (8.5) if one of those signatures is called using the default argument (8.3.6).
Change 23.3.2.1 [deque.cons] para 5:
Effects: Constructs a deque with ndefault constructedvalue-initialized elements.
Change 23.3.2.2 [deque.capacity] para 1:
Effects: If sz < size(), equivalent to erase(begin() + sz, end());. If size() < sz, appends sz - size()default constructedvalue-initialized elements to the sequence.
Change 23.3.3.1 [forwardlist.cons] para 5:
Effects: Constructs a forward_list object with ndefault constructedvalue-initialized elements.
Change 23.3.3.4 [forwardlist.modifiers] para 21:
Effects: [...] For the first signature the inserted elements aredefault constructedvalue-initialized, and for the second signature they are copies of c.
Change 23.3.4.1 [list.cons] para 5:
Effects: Constructs a list with ndefault constructedvalue-initialized elements.
Change 23.3.4.2 [list.capacity] para 15:
Effects: If sz < size(), equivalent to list<T>::iterator it = begin(); advance(it, sz); erase(it, end());. If size() < sz, appends sz - size()default constructedvalue-initialized elements to the sequence.
Change 23.3.6.1 [vector.cons] para 3:
Effects: Constructs a vector with ndefault constructedvalue-initialized elements.
Change 23.3.6.2 [vector.capacity] para 24:
Effects: If sz < size(), equivalent to erase(begin() + sz, end());. If size() < sz, appends sz - size()default constructedvalue-initialized elements to the sequence.
Section: 23.2.5 [unord.req] Status: Open Submitter: Daniel Krügler Opened: 2008-08-17 Last modified: 2009-10-20
View other active issues in [unord.req].
View all other issues in [unord.req].
View all issues with Open status.
Discussion:
Good ol' associative containers allow both function pointers and function objects as feasible comparators, as described in 23.2.4 [associative.reqmts]/2:
Each associative container is parameterized on Key and an ordering relation Compare that induces a strict weak ordering (25.3) on elements of Key. [..]. The object of type Compare is called the comparison object of a container. This comparison object may be a pointer to function or an object of a type with an appropriate function call operator.[..]
The corresponding wording for unordered containers is not so clear, but I read it to disallow function pointers for the hasher and I miss a clear statement for the equality predicate, see 23.2.5 [unord.req]/3+4+5:
Each unordered associative container is parameterized by Key, by a function object Hash that acts as a hash function for values of type Key, and by a binary predicate Pred that induces an equivalence relation on values of type Key.[..]
A hash function is a function object that takes a single argument of type Key and returns a value of type std::size_t.
Two values k1 and k2 of type Key are considered equal if the container's equality function object returns true when passed those values.[..]
and table 97 says in the column "assertion...post-condition" for the expression X::hasher:
Hash shall be a unary function object type such that the expression hf(k) has type std::size_t.
Note that 20.7 [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
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-10 Santa Cruz: ]
Ask Daniel to provide proposed wording that: makes it explicit that function pointers are function objects at the beginning of 20.7 [function.objects]; fixes the "requirements" for typedefs in 20.7.5 [refwrap] to instead state that the function objects defined in that clause have these typedefs, but not that these typedefs are requirements on function objects; remove the wording that explicitly calls out that associative container comparators may be function pointers.
Proposed resolution:
In 23.2.5 [unord.req]/3, just after the second sentence which is written as
Additionally, unordered_map and unordered_multimap associate an arbitrary mapped type T with the Key.
add one further sentence:
Both Hash and Pred may be pointers to function or objects of a type with an appropriate function call operator.
[Note1: Since the detailed requirements for Pred and Hash are given in p.4 and p.5, it an alternative resolution would be to insert a new paragraph just after p.5, which contains the above proposed sentence]
[Note2: I do not propose a change of above quoted element in table 97, because the mis-usage of the notion of "function object" seems already present in the standard at several places, even if it includes function pointers, see e.g. 25 [algorithms]/7. The important point is that in those places a statement is given that the actually used symbol, like "Predicate" applies for function pointers as well]
Rationale:
[ San Francisco: ]
This is fixed by N2776.
Section: 26.7.5 [numeric.iota] Status: Ready Submitter: Daniel Krügler Opened: 2008-08-20 Last modified: 2009-10-22
View all issues with Ready status.
Discussion:
According to the recent WP N2691, 26.7.5 [numeric.iota]/1, the requires clause of std::iota says:
T shall meet the requirements of CopyConstructible and Assignable types, and shall be convertible to ForwardIterator's value type.[..]
Neither CopyConstructible nor Assignable is needed, instead MoveConstructible seems to be the correct choice. I guess the current wording resulted as an artifact from comparing it with similar numerical algorithms like accumulate.
Note: If this function will be conceptualized, the here proposed MoveConstructible requirement can be removed, because this is an implied requirement of function arguments, see N2710/[temp.req.impl]/3, last bullet.
[ post San Francisco: ]
Issue pulled by author prior to review.
[ 2009-07-30 Daniel reopened: ]
with the absence of concepts, this issue (closed) is valid again and I suggest to reopen it. I also revised by proposed resolution based on N2723 wording:
[ 2009-10 Santa Cruz: ]
Change 'convertible' to 'assignable', Move To Ready.
Proposed resolution:
Change the first sentence of 26.7.5 [numeric.iota]/1:
Requires: T shallmeet the requirements of CopyConstructible and Assignable types, and shallbe assignable to ForwardIterator's value type. [..]
Section: 24.5.3.3.12 [move.iter.op.index] Status: Ready Submitter: Doug Gregor Opened: 2008-08-21 Last modified: 2009-10-23
View all issues with Ready status.
Discussion:
move_iterator's operator[] is declared as:
reference operator[](difference_type n) const;
This has the same problem that reverse_iterator's operator[] used to have: if the underlying iterator's operator[] returns a proxy, the implicit conversion to value_type&& could end up referencing a temporary that has already been destroyed. This is essentially the same issue that we dealt with for reverse_iterator in DR 386.
[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]
[ 2009-08-15 Howard adds: ]
I recommend closing this as a duplicate of 1051 which addresses this issue for both move_iterator and reverse_iterator.
[ 2009-10 Santa Cruz: ]
Move to Ready. Note that if 1051 is reopened, it may yield a better resolution, but 1051 is currently marked NAD.
Proposed resolution:
In 24.5.3.1 [move.iterator] and 24.5.3.3.12 [move.iter.op.index], change the declaration of move_iterator's operator[] to:
referenceunspecified operator[](difference_type n) const;
Rationale:
[ San Francisco: ]
NAD Editorial, see N2777.
Section: 20.3.4 [pairs] Status: Open Submitter: Alisdair Meredith Opened: 2008-09-15 Last modified: 2009-07-17
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 );
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?
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: ]
Would be NAD if better ctors fixed it.
Related to 811.
[ post San Francisco: ]
Possibly NAD Editorial, solved by N2770.
[ 2009-05-25 Alisdair adds: ]
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.
[ 2009-07 Frankfurt ]
We agree with the intent, but we need to wait for the dust to settle on concepts.
Proposed resolution:
Section: 30.5.1 [thread.condition.condvar] Status: Open Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2009-10-26
View other active issues in [thread.condition.condvar].
View all other issues in [thread.condition.condvar].
View all issues with Open status.
Discussion:
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:
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:
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; system_clock::time_point s_entry = system_clock::now(); typename Clock::time_point c_entry = 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; }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.
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).
[ Post Summit: ]
"POSIX people will review the proposed NAD resolution at their upcoming NY meeting.
See the minutes at: http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009.
[ 2009-07 Frankfurt ]
Move to NAD.
[ 2009-07-18 Detlef reopens the issue: ]
On Friday afternoon in Frankfurt is was decided that 887 is NAD. This decision was mainly based on a sample implementation presented by Howard that implemented one clock on top of another. Unfortunately this implementation doesn't work for the probably most important case where a system has a monotonic clock and a real-time clock (or "wall time" clock):
If the underlying "system_clock" is a monotonic clock, and the program waits on the real-time clock, and the real-time clock is set forward, the wait will unblock too late.
If the underlying "system_clock" is a real-time clock, and the program waits on the monotonic clock, and the real-time clock is set back, the wait again will unblock too late.
Sorry that I didn't remember this on Friday, but it was Friday afternoon after a busy week...
So as the decision was made on a wrong asumption, I propose to re-open the issue.
[ 2009-07-26 Howard adds: ]
Detlef correctly argues that condition_variable::wait_until could return "too late" in the context of clocks being adjusted during the wait. I agree with his logic. But I disagree that this makes this interface unimplementable on POSIX.
The POSIX spec also does not guarantee that pthread_cond_timedwait does not return "too late" when clocks are readjusted during the wait. Indeed, the POSIX specification lacks any requirements at all concerning how soon pthread_cond_timedwait returns after a time out. This is evidently a QOI issue by the POSIX standard. Here is a quote of the most relevant normative text concerning pthread_cond_timedwait found here.
The pthread_cond_timedwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned if the absolute time specified by abstime passes (that is, system time equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call.I.e. the POSIX specification speaks of the error code returned in case of a time out, but not on the timeliness of that return.
Might this simply be an oversight, or minor defect in the POSIX specification?
I do not believe so. This same section goes on to say in non-normative text:
For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred.Here is non-normative wording encouraging the implementation to ignore an advancing underlying clock and subsequently causing an early (spurious) return. There is no wording at all which addresses Detlef's example of a "late return". With pthread_cond_timedwait this would be caused by setting the system clock backwards. It seems reasonable to assume, based on the wording that is already in the POSIX spec, that again, the discontinuously changed clock would be ignored by pthread_cond_timedwait.
A noteworthy difference between pthread_cond_timedwait and condition_variable::wait_until is that the POSIX spec appears to say that ETIMEDOUT should be returned if pthread_cond_timedwait returns because of timeout signal, whether or not the system clock was discontinuously advanced during the wait. In contrast condition_variable::wait_until always returns:
Clock::now() < abs_timeThat is, the C++ spec requires that the clock be rechecked (detecting discontinuous adjustments during the wait) at the time of return. condition_variable::wait_until may indeed return early or late. But regardless it will return a value reflecting timeout status at the time of return (even if clocks have been adjusted). Of course the clock may be adjusted after the return value is computed but before the client has a chance to read the result of the return. Thus there are no iron-clad guarantees here.
condition_variable::wait_until (and pthread_cond_timedwait) is little more than a convenience function for making sure condition_variable::wait doesn't hang for an unreasonable amount of time (where the client gets to define "unreasonable"). I do not think it is in anyone's interest to try to make it into anything more than that.
I maintain that this is a useful and flexible specification in the spirit of C++, and is implementable on POSIX. The implementation technique described above is a reasonable approach. There may also be higher quality approaches. This specification, like the POSIX specification, gives a wide latitude for QOI.
I continue to recommend NAD, but would not object to a clarifying note regarding the behavior of condition_variable::wait_until. At the moment, I do not have good wording for such a note, but welcome suggestions.
[ 2009-09-30: See N2969. ]
[ 2009-10 Santa Cruz: ]
The LWG is in favor of Detlef to supply revision which adopts Option 2 from N2969 but is modified by saying that system_clock must be available for wait_until.
Proposed resolution:
Section: 30.3.1.1 [thread.thread.id] Status: Ready Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2009-10-22
View all other issues in [thread.thread.id].
View all issues with Ready status.
Discussion:
Addresses UK 324
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: ]
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.
Group expresses support for putting ids in both unordered and ordered containers.
[ post San Francisco: ]
Howard: It turns out the current working paper N2723 already has hash<thread::id> (20.7 [function.objects], 20.7.16 [unord.hash]). We simply overlooked it in the meeting. It is a good thing we voted in favor of it (again). :-)
Recommend NAD.
[ 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: ]
The recommendation for LWG-889/UK-324 is NAD, already specified.
It is not clear to me that the specification is complete.
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.16 [unord.hash], p1.
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.
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.
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.
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.
[ 2009-07 Frankfurt ]
Decided we want to move hash specialization for thread_id to the thread header. Alisdair to provide wording.
[ 2009-07-28 Alisdair provided wording, moved to Review. ]
[ 2009-10 Santa Cruz: ]
Add a strike for hash<thread::id>. Move to Ready
Proposed resolution:
Remove the following prototype from the synopsis in 20.7 [function.objects]:
template <> struct hash<std::thread::id>;
Add to 30.3 [thread.threads], p1 Header <thread> synopsis:
template <class T> struct hash; template <> struct hash<thread::id>;
Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
template <>
struct hash<thread::id> : public unary_function<thread::id, size_t> {
size_t operator()(thread::id val) const;
};
Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
[Note: Relational operators allow thread::id objects to be used as keys in associative containers. hash template specialization allow thread::id objects to be used as keys in unordered containers. — end note]
Add new paragraph to end of 30.3.1.1 [thread.thread.id]
template <> struct hash<thread::id>;An explicit specializations of the class template hash (20.7.16 [unord.hash]) shall be provided for the values of type thread::id suitable for use as keys in unordered associative containers (23.5 [unord]).
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-10-24
View other active issues in [thread.thread.constr].
View all other issues in [thread.thread.constr].
View all issues with Open status.
Discussion:
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.
There are two problems with this.
First, the specification (and implementation) in terms of std::bind allows, for example:
std::thread th( f, 1, std::bind( g ) );
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.
Second, assuming that we don't want the above, the specification has copied the wording
INVOKE(func, w1, w2, ..., wN) (20.6.2) shall be a valid expression for some values w1, w2, ..., wN
but this is not needed since we know that our argument list is args; it should simply be
INVOKE(func, args...) (20.6.2) shall be a valid expression
[ Summit: ]
Move to open.
[ Post Summit Anthony provided proposed wording. ]
[ 2009-07 Frankfurt ]
Leave Open. Await decision for thread variadic constructor.
[ 2009-10 Santa Cruz: ]
See proposed wording for 929 for this, for the formulation on how to solve this. 929 modifies the thread constructor to have "pass by value" behavior with pass by reference efficiency through the use of the decay trait. This same formula would be useful for call_once.
Proposed resolution:
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).
Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
template<class Callable, class ...Args> void call_once(once_flag& flag, Callable func, 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).
Section: 30.4.1.1 [thread.mutex.class] Status: Ready Submitter: Peter Dimov Opened: 2008-09-15 Last modified: 2009-10-22
View all other issues in [thread.mutex.class].
View all issues with Ready status.
Duplicate of: 905
Discussion:
30.4.1.1 [thread.mutex.class]/27 (in N2723) says that the behavior is undefined if:
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.
[ 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"
[ 2009-07 Frankfurt ]
Move to Review. Alisdair to provide note.
[ 2009-07-31 Alisdair provided note. ]
[ 2009-10 Santa Cruz: ]
Moved to Ready.
Proposed resolution:
In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
- ...
- 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- ...
Add the following note after p3 30.4.1.1 [thread.mutex.class]
[Note: a program may deadlock if the thread that owns a mutex object calls lock() or try_lock() on that object. If the program can detect the deadlock, a resource_deadlock_would_occur error condition may be observed. — end note]
Section: 20.8.15.2 [util.smartptr.shared] Status: Open Submitter: Hans Boehm Opened: 2008-09-16 Last modified: 2009-10-25
View all other issues in [util.smartptr.shared].
View all issues with Open status.
Discussion:
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.)
Pro thread-safety:
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.
Against thread-safety:
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.
[ San Francisco: ]
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
Detlef: I think that shared_ptr should not be thread-safe.
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.
Leave in Open. Detlef will submit an alternative proposed resolution that makes shared_ptr explicitly unsafe.
A third option is to support both threadsafe and non-safe share_ptrs, and to let the programmer decide which behavior they want.
Beman: Peter, do you support the PR?
Peter:
Yes, I support the proposed resolution, and I certainly oppose any attempts to make shared_ptr thread-unsafe.
I'd mildly prefer if
[Note: This is true in spite of that fact that such functions often modify use_count() --end note]is changed to
[Note: This is true in spite of that fact that such functions often cause a change in use_count() --end note](or something along these lines) to emphasise that use_count() is not, conceptually, a variable, but a return value.
[ 2009-07 Frankfurt ]
Vote: Do we want one thread-safe shared pointer or two? If two, one would allow concurrent construction and destruction of shared pointers, and one would not be thread-safe. If one, then it would be thread-safe.
No concensus on that vote.
Hans to improve wording in consultation with Pete. Leave Open.
[ 2009-10 Santa Cruz: ]
Move to Ready. Ask Editor to clear up wording a little when integrating to make it clear that the portion after the first comma only applies for the presence of data races.
[ 2009-10-24 Hans adds: ]
I think we need to pull 896 back from ready, unfortunately. My wording doesn't say the right thing.
I suspect we really want to say something along the lines of:
For purposes of determining the presence of a data race, member functions access and modify only the shared_ptr and weak_ptr objects themselves and not objects they refer to. Changes in use_count() do not reflect modifications that can introduce data races.But I think this needs further discussion by experts to make sure this is right.
Detlef and I agree continue to disagree on the resolution, but I think we agree that it would be good to try to expedite this so that it can be in CD2, since it's likely to generate NB comments no matter what we do. And lack of clarity of intent is probably the worst option. I think it would be good to look at this between meetings.
Proposed resolution:
Make it explicitly thread-safe, in this weak sense, as I believe was intended:
Insert in 20.8.15.2 [util.smartptr.shared], before p5:
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]
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.
Section: 27.9.1.8 [ifstream.assign] Status: Open Submitter: Niels Dekker Opened: 2008-09-20 Last modified: 2009-10-20
View all issues with Open status.
Discussion:
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:
ifstream1 = std::move(ifstream2);
The current Draft (N2723) specifies that the move-assignment of stream types like ifstream has the same effect as a swap:
Assign and swap 27.9.1.8 [ifstream.assign]
basic_ifstream& operator=(basic_ifstream&& rhs);Effects: swap(rhs).
[ Batavia (2009-05): ]
Howard agrees with the analysis and the direction proposed.
Move to Open pending specific wording to be supplied by Howard.
[ 2009-07 Frankfurt: ]
Howard is going to write wording.
[ 2009-07-26 Howard provided wording. ]
[ 2009-09-13 Niels adds: ]
Note: The proposed change of 27.9.1.3 [filebuf.assign]/1 depends on the resolution of LWG 1204, which allows implementations to assume that *this and rhs refer to different objects.
[ 2009 Santa Cruz: ]
Leave as Open. Too closely related to 911 to move on at this time.
Proposed resolution:
Change 27.8.1.2 [stringbuf.assign]/1:
basic_stringbuf& operator=(basic_stringbuf&& rhs);-1- Effects:swap(rhs).After the move assignment *this reflects the same observable state it would have if it had been move constructed from rhs (27.8.1.1 [stringbuf.cons]).
Change 27.8.2.2 [istringstream.assign]/1:
basic_istringstream& operator=(basic_istringstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Change 27.8.3.2 [ostringstream.assign]/1:
basic_ostringstream& operator=(basic_ostringstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Change 27.8.5.1 [stringstream.assign]/1:
basic_stringstream& operator=(basic_stringstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Change 27.9.1.3 [filebuf.assign]/1:
basic_filebuf& operator=(basic_filebuf&& rhs);-1- Effects:swap(rhs).Begins by calling this->close(). After the move assignment *this reflects the same observable state it would have if it had been move constructed from rhs (27.9.1.2 [filebuf.cons]).
Change 27.9.1.8 [ifstream.assign]/1:
basic_ifstream& operator=(basic_ifstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Change 27.9.1.12 [ofstream.assign]/1:
basic_ofstream& operator=(basic_ofstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Change 27.9.1.16 [fstream.assign]/1:
basic_fstream& operator=(basic_fstream&& rhs);-1- Effects:swap(rhs).Move assigns the base and members of *this with the respective base and members of rhs.
Section: 20.2.1 [utility.arg.requirements] Status: Open Submitter: Alberto Ganesh Barbati Opened: 2008-09-29 Last modified: 2009-11-03
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
View all issues with Open 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.
[ 2009-07 Frankfurt: ]
Need to look at again without concepts.
[ 2009-07 Frankfurt: ]
Walter will consult with Dave and Doug.
[ 2009-10 Santa Cruz: ]
We believe this is handled by the resolution to issue 1204, but there is to much going on in this area to be sure. Defer for now.
Proposed resolution:
In [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]
Section: 27.7.1 [input.streams], 27.7.2 [output.streams] Status: Open Submitter: Alberto Ganesh Barbati Opened: 2008-09-29 Last modified: 2009-10-20
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.
[ 2009-07 Frankfurt: ]
It's not clear that the use case is compelling.
Howard: This needs to be implemented and tested.
[ 2009-07-26 Howard adds: ]
I started out thinking I would recommend NAD for this one. I've turned around to agree with the proposed resolution (which I've updated to the current draft). I did not fully understand Ganesh's rationale, and attempt to describe my improved understanding below.
The move constructor, move assignment operator, and swap function are different for basic_istream, basic_ostream and basic_iostream than other classes. A timely conversation with Daniel reminded me of this long forgotten fact. These members are sufficiently different that they would be extremely confusing to use in general, but they are very much needed for derived clients.
- The move constructor moves everything but the rdbuf pointer.
- The move assignment operator moves everything but the rdbuf pointer.
- The swap function swaps everything but the rdbuf pointer.
The reason for this behavior is that for the std-derived classes (stringstreams, filestreams), the rdbuf pointer points back into the class itself (self referencing). It can't be swapped or moved. But this fact isn't born out at the stream level. Rather it is born out at the fstream/sstream level. And the lower levels just need to deal with that fact by not messing around with the rdbuf pointer which is stored down at the lower levels.
In a nutshell, it is very confusing for all of those who are not so intimately related with streams that they've implemented them. And it is even fairly confusing for some of those who have (including myself). I do not think it is safe to swap or move istreams or ostreams because this will (by necessary design) separate stream state from streambuffer state. Derived classes (such as fstream and stringstream must be used to keep the stream state and stream buffer consistently packaged as one unit during a move or swap.
I've implemented this proposal and am living with it day to day.
[ 2009 Santa Cruz: ]
Leave Open. Pablo expected to propose alternative wording which would rename move construction, move assignment and swap, and may or may not make them protected. This will impact issue 900.
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 swap free function signature
// swap: 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);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 swap free function signature
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);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 swap free function signature
// swap: 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 4
template <class charT, class traits> void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);Effects: x.swap(y).
Section: 25.4.7 [alg.min.max] Status: Open Submitter: Daniel Krügler Opened: 2008-10-04 Last modified: 2009-10-23
View all other issues in [alg.min.max].
View all issues with Open status.
Discussion:
It seems that the proposed changes for N2772 were not clear enough in this point:
25.4.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.
[ 2009-07 Frankfurt ]
Moved from Tentatively Ready to Open only because the wording needs to be tweaked for concepts removal.
[ 2009-08-18 Daniel adds: ]
Recommend NAD since the proposed changes have already been performed as part of editorial work of N2914.
[ 2009-10 Santa Cruz: ]
Can't find initializer_list form of minmax anymore, only variadic version. Seems like we had an editing clash with concepts. Leave Open, at least until editorial issues resolved. Bring this to Editor's attention.
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.4.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&,constT&>(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&,constT&>(x, y) where x is the smallest value and y largest value in the initializer_list.
Section: 20.7.14 [func.memfn] Status: Ready Submitter: Bronek Kozicki Opened: 2008-10-06 Last modified: 2009-10-23
View all other issues in [func.memfn].
View all issues with Ready status.
Duplicate of: 1230
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.
[ 2009-10-10 Daniel updated wording to post-concepts. ]
1230 has a similar proposed resolution
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Change 20.7 [function.objects]/2, header <functional> synopsis as follows:
// 20.7.14, member function adaptors: template<class R, class T> unspecified mem_fn(R T::*); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...)); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) volatile); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const volatile); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) volatile &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const volatile &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) volatile &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::*)(Args...) const volatile &&);
Change the prototype list of 20.7.14 [func.memfn] as follows [NB: 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. ]:
template<class R, class T> unspecified mem_fn(R T::* pm); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...)); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) volatile); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const volatile); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) volatile &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const volatile &); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) volatile &&); template<class R, class T, class ...Args> unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
Remove 20.7.14 [func.memfn]/5:
Remarks: Implementations may implement mem_fn as a set of overloaded function templates.
Section: 20.4.1 [ratio.ratio] Status: Ready Submitter: Pablo Halpern Opened: 2008-10-07 Last modified: 2009-10-21
View all other issues in [ratio.ratio].
View all issues with Ready 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.
[ 2009-07-21 Alisdair adds: ]
See 1121 for a potentially incompatible proposal.
[ 2009-10 Santa Cruz: ]
Move to Ready.
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 [..]
Section: 30.3.1.2 [thread.thread.constr] Status: Review Submitter: Anthony Williams Opened: 2008-10-23 Last modified: 2009-10-25
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.4 [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).
[ 2009-07 Frankfurt: ]
This is linked to N2901.
Howard to open a separate issue to remove (1176).
In Frankfurt there is no consensus for removing the variadic constructor.
[ 2009-10 Santa Cruz: ]
We want to move forward with this issue. If we later take it out via 1176 then that's ok too. Needs small group to improve wording.
[ 2009-10 Santa Cruz: ]
Stefanus provided revised wording. Moved to Review Here is the original wording:
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.
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.... Given a function as follows:Any return value from f is ignored. If f terminates with an uncaught exception, std::terminate() shall be called.template<typename T> typename decay<T>::type decay_copy(T&& v) { return std::forward<T>(v); }The new thread of execution executes INVOKE(decay_copy(f), decay_copy(args)...) with the calls to decay_copy() being evaluated in the constructing thread. Any return value from this invocation is ignored. [Note: this implies any exceptions not thrown from the invocation of the copy of f will be thrown in the constructing thread, not the new thread. — end note].
-6- Synchronization: The invocation of the constructor happens before the invocation of copy of f.
Section: 20.8.14.2.1 [unique.ptr.single.ctor] Status: Ready Submitter: Howard Hinnant Opened: 2008-11-26 Last modified: 2009-10-22
View other active issues in [unique.ptr.single.ctor].
View all other issues in [unique.ptr.single.ctor].
View all issues with Ready status.
Discussion:
Addresses US 79
20.8.14.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.
[ 2009-07 Frankfurt ]
Moved from Tentatively Ready to Open only because the wording needs to be improved for enable_if type constraining, possibly following Robert's formula.
[ 2009-07 Frankfurt: ]
We need to consider whether some requirements in the Requires paragraphs of [unique.ptr] should instead be Remarks.
Leave Open. Howard to provide wording, and possibly demonstrate how this can be implemented using enable_if.
[ 2009-07-27 Howard adds: ]
The two constructors to which this issue applies are not easily constrained with enable_if as they are not templated:
unique_ptr(); explicit unique_ptr(pointer p);To "SFINAE" these constructors away would take heroic effort such as specializing the entire unique_ptr class template on pointer deleter types. There is insufficient motivation for such heroics. Here is the expected and reasonable implementation for these constructors:
unique_ptr() : ptr_(pointer()) { static_assert(!is_pointer<deleter_type>::value, "unique_ptr constructed with null function pointer deleter"); } explicit unique_ptr(pointer p) : ptr_(p) { static_assert(!is_pointer<deleter_type>::value, "unique_ptr constructed with null function pointer deleter"); }I.e. just use static_assert to verify that the constructor is not instantiated with a function pointer for a deleter. The compiler will automatically take care of issuing a diagnostic if the deleter is a reference type (uninitialized reference error).
In keeping with our discussions in Frankfurt, I'm moving this requirement on the implementation from the Requires paragraph to a Remarks paragraph.
[ 2009-08-17 Daniel adds: ]
It is insufficient to require a diagnostic. This doesn't imply an ill-formed program as of 1.3.3 [defns.diagnostic] (a typical alternative would be a compiler warning), but exactly that seems to be the intend. I suggest to use the following remark instead:
Remarks: The program shall be ill-formed if this constructor is instantiated when D is a pointer type or reference type.Via the general standard rules of 1.4 [intro.compliance] the "diagnostic required" is implied.
[ 2009-10 Santa Cruz: ]
Moved to Ready.
Proposed resolution:
Change the description of the default constructor in 20.8.14.2.1 [unique.ptr.single.ctor]:
unique_ptr();-1- Requires: D shall be default constructible, and that construction shall not throw an exception.
D shall not be a reference type or pointer type (diagnostic required)....
Remarks: The program shall be ill-formed if this constructor is instantiated when D is a pointer type or reference type.
Add after 20.8.14.2.1 [unique.ptr.single.ctor]/8:
unique_ptr(pointer p);...
Remarks: The program shall be ill-formed if this constructor is instantiated when D is a pointer type or reference type.
Section: 20.3.3 [forward] Status: Ready Submitter: Alisdair Meredith Opened: 2008-12-11 Last modified: 2009-10-29
View all other issues in [forward].
View all issues with Ready 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. ]
[ 2009-07-20 Alisdair adds: ]
I'm not sure why this issue was not discussed at Frankfurt (or I missed the discussion) but the rationale is now fundamentally flawed. With the removal of concepts, std::identity again becomes an important library type so we cannot simply remove it.
At that point, we need to pick one of the other suggested resolutions, but have no guidance at the moment.
[ 2009-07-20 Howard adds: ]
I believe the rationale for not addressing this issue in Frankfurt was that it did not address a national body comment.
I also believe that removal of identity is still a practical option as my latest reformulation of forward, which is due to comments suggested at Summit, no longer uses identity. :-)
template <class T, class U, class = typename enable_if < !is_lvalue_reference<T>::value || is_lvalue_reference<T>::value && is_lvalue_reference<U>::value >::type, class = typename enable_if < is_same<typename remove_all<T>::type, typename remove_all<U>::type>::value >::type> inline T&& forward(U&& t) { return static_cast<T&&>(t); }[ The above code assumes acceptance of 1120 for the definition of remove_all. This is just to make the syntax a little more palatable. Without this trait the above is still very implementable. ]
Paper with rationale is on the way ... really, I promise this time! ;-)
[ 2009-07-30 Daniel adds: See 823 for an alternative resolution. ]
[ 2009-10 Santa Cruz: ]
Move to Ready. Howard will update proposed wording to reflect current draft.
Proposed resolution:
Strike from 20.3 [utility]:
template <class T> struct identity;
Remove from 20.3.3 [forward]:
template <class T> struct identity { typedef T type; const T& operator()(const T& x) const; };const T& operator()(const T& x) const;-2- Returns: x
Section: 24.4.4 [iterator.operations] Status: Ready Submitter: Thomas Opened: 2008-12-14 Last modified: 2009-10-22
View other active issues in [iterator.operations].
View all other issues in [iterator.operations].
View all issues with Ready status.
Discussion:
Addresses UK 270
Regarding the std::distance - function, 24.4.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.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.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 X [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.4 [iterator.operations] p4 as follows:
Effects: Returns the number of incrementsor decrementsneeded 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.
[ 2009-07 Frankfurt ]
Moved from Tentatively Ready to Open only because the wording needs to be tweaked for concepts removal.
[ 2009-07 Frankfurt: ]
Leave Open pending arrival of a post-Concepts WD.
[ 2009-10-14 Daniel provided de-conceptified wording. ]
[ 2009-10 Santa Cruz: ]
Move to Ready, replacing the Effects clause in the proposed wording with "If InputIterator meets the requirements of random access iterator then returns (last - first), otherwise returns the number of increments needed to get from first to list.".
Proposed resolution:
Change 24.2.5 [random.access.iterators], Table 105 as indicated [This change is not essential but it simplifies the specification] for the row with expression "b - a" and the column Operational semantics:
(a < b) ?distance(a,b): -distance(b,a)
Change 24.4.4 [iterator.operations]/4+5 as indicated:
template<class InputIterator> typename iterator_traits<InputIterator>::difference_type distance(InputIterator first, InputIterator last);4 Effects: If InputIterator meets the requirements of random access iterator then returns (last - first), otherwise
Rreturns the number of incrementsor decrementsneeded to get from first to last.5 Requires: If InputIterator meets the requirements of random access iterator then last shall be reachable from first or first shall be reachable from last, otherwise last shall be reachable from first.
Section: 20.8.14.2.1 [unique.ptr.single.ctor] Status: Ready Submitter: Howard Hinnant Opened: 2009-01-07 Last modified: 2009-10-21
View other active issues in [unique.ptr.single.ctor].
View all other issues in [unique.ptr.single.ctor].
View all issues with 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.
[ 2009-07 Frankfurt ]
Moved from Tentatively Ready to Open only because the wording needs to be improved for enable_if type constraining, possibly following Robert's formula.
[ 2009-08-01 Howard updates wording and sets to Review. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
Proposed resolution:
Change 20.8.14.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. [Note: These requirements imply that T and U are complete types. — end note]Remarks: If D is a reference type, then E shall be the same type as D, else this constructor shall not participate in overload resolution. unique_ptr<U, E>::pointer shall be implicitly convertible to pointer, else this constructor shall not participate in overload resolution. U shall not be an array type, else this constructor shall not participate in overload resolution. [Note: These requirements imply that T and U are complete types. — end note]
Change 20.8.14.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. [Note: These requirements imply that T and U are complete types. — end note]Remarks: unique_ptr<U, E>::pointer shall be implicitly convertible to pointer, else this operator shall not participate in overload resolution. U shall not be an array type, else this operator shall not participate in overload resolution. [Note: These requirements imply that T and U are complete types. — end note]
Section: 20.9.2.1 [time.traits.is_fp] Status: Open Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-10-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.
[ 2009-08-01 Howard adds: ]
I have surveyed all clauses of 20.9.2.2 [time.traits.duration_values], 20.9.2.3 [time.traits.specializations] and 20.9.3 [time.duration]. I can not find any clause which involves the use of a duration::rep type where the requirements on the rep type are not clearly spelled out. These requirements were carefully crafted to allow any arithmetic type, or any user-defined type emulating an arithmetic type.
Indeed, treat_as_floating_point becomes completely superfluous if duration::rep can never be a class type.
There will be some Rep types which will not meet the requirements of every duration operation. This is no different than the fact that vector<T> can easily be used for types T which are not DefaultConstructible, even though some members of vector<T> require T to be DefaultConstructible. This is why the requirements on Rep are specified for each operation individually.
In 20.9.2.1 [time.traits.is_fp] p1:
template <class Rep> struct treat_as_floating_point : is_floating_point<Rep> { };The duration template uses the treat_as_floating_point trait to help determine if a duration object can be converted to another duration with a different tick period. If treat_as_floating_point<Rep>::value is true, then Rep is a floating-point type and implicit conversions are allowed among durations. Otherwise, the implicit convertibility depends on the tick periods of the durations. If Rep is a class type which emulates a floating-point type, the author of Rep can specialize treat_as_floating_point so that duration will treat this Rep as if it were a floating-point type. Otherwise Rep is assumed to be an integral type or a class emulating an integral type.The phrases "a class type which emulates a floating-point type" and "a class emulating an integral type" are clarifying phrases which refer to the summation of all the requirements on the Rep type specified in detail elsewhere (and should not be repeated here).
This specification has been implemented, now multiple times, and the experience has been favorable. The current specification clearly specifies the requirements at each point of use (though I'd be happy to fix any place I may have missed, but none has been pointed out).
I am amenable to improved wording of this paragraph (and any others), but do not have any suggestions for improved wording at this time. I am strongly opposed to changes which would significantly alter the semantics of the specification under 20.9 [time] without firmly grounded and documented rationale, example implementation, testing, and user experience which relates a positive experience.
I recommend NAD unless someone wants to produce some clarifying wording.
[ 2009-10 Santa Cruz: ]
Stefanus to provide wording to turn this into a note.
Proposed resolution:
Section: 20.9.1 [time.clock.req] Status: Open Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-10-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.
[ 2009-08-01 Howard adds: ]
See commented dated 2009-08-01 in 951.
[ 2009-10 Santa Cruz: ]
Stefanus to provide wording to turn this into a note.
Proposed resolution:
Section: 20.9.1 [time.clock.req] Status: Ready Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-10-21
View other active issues in [time.clock.req].
View all other issues in [time.clock.req].
View all issues with Ready status.
Discussion:
Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
[ 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.
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)".
[ 2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided. ]
[ 2009-10 Santa Cruz: ]
Move to Ready.
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":
| C1::time_point | chrono::time_point<C1> or chrono::time_point<C2, C1::duration> |
The native time_point type of the clock.
|
Change the row starting with C1::period of the table "Clock Requirements":
| C1::period | a specialization of ratio | The tick period of the clock in seconds. |
Section: 20.9.1 [time.clock.req] Status: Open Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-10-24
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.
[ 2009-10-23 Pete provides wording: ]
Proposed resolution:
Remove every occurrence of "native" in 20.9.1 [time.clock.req].
Add the following sentence at the end of 20.9.1 [time.clock.req]/1:
A clock is a bundle consisting of anativeduration, anativetime_point, and a function now() to get the current time_point. A clock shall meet the requirements in Table 55. The duration and time_point types have the natural size and resolution suggested by the architecture of the execution environment.
Section: 20.9.5.1 [time.clock.system] Status: Ready Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2009-10-21
View all other issues in [time.clock.system].
View all issues with