| Doc. no. | D???? |
| Date: | 2025-11-12 |
| Project: | Programming Language C++ |
| Reply to: | Jonathan Wakely <lwgchair@gmail.com> |
Revised 2025-11-12 at 12:30:38 UTC
Reference ISO/IEC IS 14882:2024(E)
Also see:
This document contains only library issues which have been closed by the Library Working Group as duplicates or not defects. That is, issues which have a status ofDup orNAD. See theLibrary Defect Reports and Accepted Issues for issues considered defects. See theLibrary Active Issues List for active issues and more information. The introductory material in that document also applies to this document.
Section: 99 [auto.ptr.conv]Status:NADSubmitter: Nathan MyersOpened: 1997-12-04Last modified: 2016-08-09
Priority:Not Prioritized
View all otherissues in [auto.ptr.conv].
View all issues withNAD status.
Discussion:
Paragraph 1 in "Effects", says "Callsp->release()" where it clearly must be "Callsp.release()". (As it is, it seems to require usingauto_ptr<>::operator-> to refer to X::release, assuming thatexists.)
Proposed resolution:
Change 21.3.6.4[meta.unary.prop] paragraph 1 Effects from "Calls p->release()" to "Calls p.release()".
Rationale:
Not a defect: the proposed change is already found in the standard.[Originally classified as a defect, later reclassified.]
basic_stringsize_type anddifference_type should be implementation definedSection: 27.4.3[basic.string]Status:NADSubmitter: Beman DawesOpened: 1997-11-16Last modified: 2016-08-09
Priority:Not Prioritized
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD status.
Discussion:
In Morristown we changed thesize_type anddifference_type typedefsfor all the other containers to implementation defined with areference to 23.2[container.requirements]. This should probably also have beendone for strings.
Rationale:
Not a defect. [Originally classified as a defect, laterreclassified.]basic_string, unlike the other standard librarytemplate containers, is severely constrained by its use ofchar_traits. Those types are dictated by the traits class, and are farfrom implementation defined.
Section: 31.5.3[fpos]Status:NADSubmitter: Matt AusternOpened: 1997-12-15Last modified: 2016-08-09
Priority:Not Prioritized
View all otherissues in [fpos].
View all issues withNAD status.
Discussion:
Table 88, in I/O, is too strict; it's unimplementable on systemswhere a file position isn't just an offset. It also never says justwhatfpos<> is really supposed to be. [Here's my summary, whichJerry agrees is more or less accurate. "I think I now know whatthe class really is, at this point: it's a magic cookie thatencapsulates anmbstate_t and a file position (possibly represented asanfpos_t), it has syntactic support for pointer-like arithmetic, andimplementors are required to have real, not just syntactic, supportfor arithmetic." This isn't standardese, of course.]
Rationale:
Not a defect. The LWG believes that the Standard is already clear,and that the above summary is what the Standard in effect says.
Section: 28.3.4.2.6[locale.codecvt.byname]Status:DupSubmitter: Matt AusternOpened: 1998-01-14Last modified: 2016-08-09
Priority:Not Prioritized
View all otherissues in [locale.codecvt.byname].
View all issues withDup status.
Duplicate of:19
Discussion:
Section 22.2.1.5.2 says that codecvt<>::do_in and do_outshould return the value noconv if "no conversion wasneeded". However, I don't see anything anywhere that defines whatit means for a conversion to be needed or not needed. I can think ofseveral circumstances where one might plausibly think that aconversion is not "needed", but I don't know which one isintended here.
Rationale:
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: Angelika LangerOpened: 1998-02-23Last modified: 2016-08-09
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
I couldn't find a statement in the standard saying whether the allocator object held bya container is held as a copy of the constructor argument or whether a pointer ofreference is maintained internal. There is an according statement for compare objects andhow they are maintained by the associative containers, but I couldn't find anythingregarding allocators.
Did I overlook it? Is it an open issue or known defect? Or is it deliberately leftunspecified?
Rationale:
Not a defect. The LWG believes that the Standard is alreadyclear. See 23.2[container.requirements], paragraph 8.
Section: 28.3.4.2.6[locale.codecvt.byname]Status:DupSubmitter: Brendan KehoeOpened: 1998-06-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt.byname].
View all issues withDup status.
Duplicate of:33
Discussion:
Rationale:
Section: 31.8.4[ostringstream]Status:NADSubmitter: Matthias MuellerOpened: 1998-05-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ostringstream].
View all issues withNAD status.
Discussion:
In a comp.lang.c++.moderated Matthias Mueller wrote:
"We are not sure how to interpret the CD2 (see 31.3[iostream.forward], 31.8.4.2[ostringstream.cons], 31.8.2.2[stringbuf.cons])with respect to the question as to what the correct initial positionsof the write and read pointers of a stringstream shouldbe."
"Is it the same to output two strings or to initialize the stringstream with thefirst and to output the second?"
[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, andJerry Schwarz have all offered opinions; see reflector messageslib-6518, 6519, 6520, 6521, 6523, 6524.]
Rationale:
The LWG believes the Standard is correct as written. The behaviorof stringstreams is consistent with fstreams, and there is aconstructor which can be used to obtain the desired effect. Thisbehavior is known to be different from strstreams.
Section: 31.7.5.3.3[istream.extractors]Status:NADSubmitter: Matt AusternOpened: 1998-07-01Last modified: 2017-04-22
Priority:Not Prioritized
View all otherissues in [istream.extractors].
View all issues withNAD status.
Discussion:
27.6.1.2.3 has member functions for extraction of signed char andunsigned char, both singly and as strings. However, it doesn't saywhat it means to extract achar from abasic_streambuf<charT, Traits>.
basic_streambuf, after all, has no members to extract a char, sobasic_istream must somehow convert from charT to signed char orunsigned char. The standard doesn't say how it is to perform thatconversion.
Rationale:
The Standard is correct as written. There is no such extractor andthis is the intent of the LWG.
Section: 99 [depr.strstreambuf.virtuals]Status:NADSubmitter: Matt AusternOpened: 1998-08-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [depr.strstreambuf.virtuals].
View all issues withNAD status.
Discussion:
The standard says how this member function affects the currentstream position. (gptr orpptr) However, it does notsay how this member function affects the beginning and end of theget/put area.
This is an issue when seekoff is used to position the get pointerbeyond the end of the current read area. (Which is legal. This isimplicit in the definition ofseekhigh in D.7.1, paragraph 4.)
Rationale:
The LWG agrees that seekoff() is underspecified, but does not wishto invest effort in this deprecated feature.
Section: 27.4.4.4[string.io]Status:DupSubmitter: Steve ClamageOpened: 1998-07-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.io].
View all issues withDup status.
Duplicate of:25
Discussion:
In a comp.std.c++ posting Michel Michaud wrote: Whatshould be output by:
string text("Hello"); cout << '[' << setw(10) << right << text << ']';Shouldn't it be:
[ Hello]
Another person replied: Actually, according to the FDIS, the widthof the field should be the minimum of width and the length of thestring, so the output shouldn't have any padding. I think that this isa typo, however, and that what is wanted is the maximum of thetwo. (As written, setw is useless for strings. If that had been theintent, one wouldn't expect them to have mentioned using its value.)
It's worth pointing out that this is a recent correction anyway;IIRC, earlier versions of the draft forgot to mention formattingparameters whatsoever.
Rationale:
Section: 28.3.4.2.5[locale.codecvt]Status:DupSubmitter: Nathan MyersOpened: 1998-08-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt].
View all issues withDup status.
Duplicate of:24
Discussion:
In 28.3.4.2.5[locale.codecvt] par 3, and in 28.3.4.2.5.3[locale.codecvt.virtuals] par 8, a nonexistent member function"do_convert" is mentioned. This member was replaced with"do_in" and "do_out", the proper referents in thecontexts above.
Rationale:
is_open should be constSection: 31.10[file.streams]Status:NADSubmitter: Matt AusternOpened: 1998-08-27Last modified: 2017-06-15
Priority:Not Prioritized
View all otherissues in [file.streams].
View all issues withNAD status.
Discussion:
Classesbasic_ifstream,basic_ofstream, andbasic_fstream all have a member functionis_open. Itshould be aconst member function, since it does nothing butcall one ofbasic_filebuf's const member functions.
Rationale:
Not a defect. This is a deliberate feature; const streams would bemeaningless.
Section: 29.6.2.4[valarray.access]Status:DupSubmitter: Levente FarkasOpened: 1998-09-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.access].
View all issues withDup status.
Duplicate of:389
Discussion:
valarray:
T operator[] (size_t) const;
why not
const T& operator[] (size_t) const;
as in vector ???
One can't copy even from a const valarray eg:
memcpy(ptr, &v[0], v.size() * sizeof(double));
[I] find this bug in valarray is very difficult.
Rationale:
The LWG believes that the interface was deliberately designed thatway. That is what valarray was designed to do; that's where the"value array" name comes from. LWG members further commentthat "we don't want valarray to be a full STL container."29.6.2.4[valarray.access] specifies properties that indicate "anabsence of aliasing" for non-constant arrays; this allowsoptimizations, including special hardware optimizations, that are nototherwise possible.
Section: 29.6.5[template.slice.array], 29.6.7[template.gslice.array], 29.6.8[template.mask.array], 29.6.9[template.indirect.array]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [template.slice.array].
View all issues withNAD status.
Discussion:
Isn't the definition of copy constructor and assignment operators wrong? Instead of
slice_array(const slice_array&); slice_array& operator=(const slice_array&);
IMHO they have to be
slice_array(const slice_array<T>&); slice_array& operator=(const slice_array<T>&);
Same for gslice_array.
Rationale:
Not a defect. The Standard is correct as written.
Section: 23.2.7[associative.reqmts]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
Paragraph 5 specifies:
For set and multiset the value type is the same as the key type. Formap and multimap it is equal to pair<const Key, T>.
Strictly speaking, this is not correct because for set and multisetthe value type is the same as theconstant key type.
Rationale:
Not a defect. The Standard is correct as written; it uses adifferent mechanism (const &) forset andmultiset. See issue103(i) for a relatedissue.
Section: 27.4.3.6[string.access]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.access].
View all issues withNAD status.
Discussion:
If I try
s.insert(0,1,' ');
I get an nasty ambiguity. It might be
s.insert((size_type)0,(size_type)1,(charT)' ');
which inserts 1 space character at position 0, or
s.insert((char*)0,(size_type)1,(charT)' ')
which inserts 1 space character at iterator/address 0 (bingo!), or
s.insert((char*)0, (InputIterator)1, (InputIterator)' ')
which normally inserts characters from iterator 1 to iterator ''. But according to 23.1.1.9 (the "do the right thing" fix)it is equivalent to the second. However, it is still ambiguous,because of course I mean the first!
Rationale:
Not a defect. The LWG believes this is a "geneticmisfortune" inherent in the design of string and thus not adefect in the Standard as such .
Section: 27[strings]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [strings].
View all issues withNAD status.
Discussion:
The standard seems not to require that charT is equivalent totraits::char_type. So, what happens if charT is not equivalent totraits::char_type?
Rationale:
There is already wording in 27.2[char.traits] paragraph 3 thatrequires them to be the same.
Section: 27.4.3.7.8[string.swap]Status:DupSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-11-12
Priority:Not Prioritized
View all otherissues in [string.swap].
View all issues withDup status.
Duplicate of:5
Discussion:
The followingcompare() description is obviously a bug:
int compare(size_type pos, size_type n1, charT *s, size_type n2 = npos) const;
because without passingn2 it should compare up to the end of thestring instead of comparingnpos characters (which throws anexception)
Rationale:
Section: 27.4.3.7.4[string.insert], 27.4.3.7.2[string.append]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-11-12
Priority:Not Prioritized
View all otherissues in [string.insert].
View all issues withNAD status.
Discussion:
Why does
template<class InputIterator> basic_string& append(InputIterator first, InputIterator last);
return a string, while
template<class InputIterator> void insert(iterator p, InputIterator first, InputIterator last);
returns nothing ?
Rationale:
The LWG believes this stylistic inconsistency is not sufficiently serious to constitute a defect.
Section: 27.4.3.7.4[string.insert], 27.4.3.7.6[string.replace]Status:DupSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-11-12
Priority:Not Prioritized
View all otherissues in [string.insert].
View all issues withDup status.
Duplicate of:83
Discussion:
All insert() and replace() members for strings with an iterator asfirst argument lack a throw specification. The throwspecification should probably be: length_error if size exceedsmaximum.
Rationale:
Considered a duplicate because it will be solved by the resolutionof issue83(i).
Section: 29.6[numarray]Status:NADSubmitter: Nico JosuttisOpened: 1998-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numarray].
View all issues withNAD status.
Discussion:
You can easily create subsets, but you can't easily combine themwith other subsets. Unfortunately, you almost always needs anexplicit type conversion to valarray. This is because the standarddoes not specify that valarray subsets provide the same operations asvalarrays.
For example, to multiply two subsets and assign the result to a third subset, you can'twrite the following:
va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];
Instead, you have to code as follows:
va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * static_cast<valarray<double> >(va[slice(2,4,3)]);
This is tedious and error-prone. Even worse, it costs performance because each castcreates a temporary objects, which could be avoided without the cast.
Proposed resolution:
Extend all valarray subset types so that they offer all valarray operations.
Rationale:
This is not a defect in the Standard; it is a request for an extension.
Section: 16.4.6[conforming]Status:NADSubmitter: Matt AusternOpened: 1998-01-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [conforming].
View all issues withNAD status.
Discussion:
Is it a permitted extension for library implementors to add template parameters tostandard library classes, provided that those extra parameters have defaults? For example,instead of definingtemplate <class T, class Alloc = allocator<T> > classvector; defining it astemplate <class T, class Alloc = allocator<T>,int N = 1> class vector;
The standard may well already allow this (I can't think of any way that this extensioncould break a conforming program, considering that users are not permitted toforward-declare standard library components), but it ought to be explicitly permitted orforbidden.
comment from Steve Cleary via comp.std.c++:
I disagree [with the proposed resolution] for the following reason:consider user library code with template template parameters. Forexample, a user library object may be templated on the type ofunderlying sequence storage to use (deque/list/vector), since theseclasses all take the same number and type of template parameters; thiswould allow the user to determine the performance tradeoffs of theuser library object. A similar example is a user library objecttemplated on the type of underlying set storage (set/multiset) or mapstorage (map/multimap), which would allow users to change (withinreason) the semantic meanings of operations on that object.
I think that additional template parameters should be forbidden inthe Standard classes. Library writers don't lose any expressive power,and can still offer extensions because additional template parametersmay be provided by a non-Standard implementation class:
template <class T, class Allocator = allocator<T>, int N = 1> class __vector { ... }; template <class T, class Allocator = allocator<T> > class vector: public __vector<T, Allocator> { ... };
Proposed resolution:
Add a new subclause [presumably 17.4.4.9] following 16.4.6.14[res.on.exception.handling]:
17.4.4.9 Template Parameters
A specialization of a template class described in the C++ Standard Library behaves the same as if the implementation declares no additional template parameters.
Footnote: Additional template parameters with default values are thus permitted.
Add "template parameters" to the list of subclauses atthe end of 16.4.6[conforming] paragraph 1.
[Kona: The LWG agreed the standard needs clarification. Afterdiscussion with John Spicer, it seems added template parameters can bedetected by a program using template-template parameters. A straw vote- "should implementors be allowed to add templateparameters?" found no consensus ; 5 - yes, 7 - no.]
Rationale:
There is no ambiguity; the standard is clear as written. Libraryimplementors are not permitted to add template parameters to standardlibrary classes. This does not fall under the "as if" rule,so it would be permitted only if the standard gave explicit licensefor implementors to do this. This would require a change in the standard.
The LWG decided against making this change, because it would breakuser code involving template template parameters or specializationsof standard library class templates.
Section: 16.4.6.5[member.functions]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [member.functions].
View all otherissues in [member.functions].
View all issues withNAD status.
Discussion:
In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtualmembers a base class and break user derived classes.
Example:
// implementation code:struct _Base { // _Base is in the implementer namespace virtual void foo ();};class vector : _Base // deriving from a class is allowed{ ... };// user code:class vector_checking : public vector { void foo (); // don't want to override _Base::foo () as the // user doesn't know about _Base::foo ()};Proposed resolution:
Clarify the wording to make the example illegal.
Rationale:
This is not a defect in the Standard. The example is alreadyillegal. See 16.4.6.5[member.functions] paragraph 2.
Section: 23.3.13[vector]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [vector].
View all issues withNAD status.
Discussion:
vector<bool> is not a container as its reference andpointer types are not references and pointers.
Also it forces everyone to have a space optimization instead of aspeed one.
See also: 99-0008 == N1185 Vector<bool> isNonconforming, Forces Optimization Choice.
[In Santa Cruz the LWG felt that this was Not A Defect.]
[In Dublin many present felt that failure to meet Containerrequirements was a defect. There was disagreement as to whetheror not the optimization requirements constituted a defect.]
[The LWG looked at the following resolutions in some detail:
* Not A Defect.
* Add a note explaining that vector<bool> does not meetContainer requirements.
* Remove vector<bool>.
* Add a new category of container requirements whichvector<bool> would meet.
* Rename vector<bool>.
No alternative had strong, wide-spread, support and every alternativehad at least one "over my dead body" response.
There was also mention of a transition scheme something like (1) addvector_bool and deprecate vector<bool> in the next standard. (2)Remove vector<bool> in the following standard.]
[Modifying container requirements to permit returning proxies(thus allowing container requirements conforming vector<bool>)was also discussed.]
[It was also noted that there is a partial but ugly workaround inthat vector<bool> may be further specialized with a customerallocator.]
[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,vector<bool>: More Problems, Better Solutions. Much discussionof a two step approach: a) deprecate, b) provide replacement under anew name. LWG straw vote on that: 1-favor, 11-could live with, 2-overmy dead body. This resolution was mentioned in the LWG report to thefull committee, where several additional committee members indicatedover-my-dead-body positions.]
Discussed at Lillehammer. General agreement that we should deprecatevector<bool> and introduce this functionality under a different name, e.g.bit_vector. This might make it possible to remove thevector<bool> specialization in the standard that comes after C++0x. There was also a suggestion that in C++0x we could additional say that it's implementation defined whethervector<bool> refers to the specialization or to the primary template, but there wasn't general agreement that this was a good idea.
We need a paper for the newbit_vector class.
[Batavia:]
The LWG feels we need something closer to SGI's
bitvectorto ease migrationfromvector<bool>. Although some of the funcitonality fromN2050could well be used in such a template. The concern is easing the API migration for thoseusers who want to continue using a bit-packed container. Alan and Beman to work.
[Post Summit Alisdair adds:]
vector<bool>is now a conforming container under the revised terms of C++0x,which supports containers of proxies.Recommend NAD.
Two issues remain:
i/ premature optimization in the specification.There is still some sentiment that deprecation is the correct way to go,although it is still not clear what it would mean to deprecate a singlespecialization of a template.
Recommend: Create a new issue for the discussion, leave as Open.
ii/ Request for a new bitvector class to guarantee the optimization, perhapswith a better tuned interface.
This is a clear extension request that may be handled via a future TR.
[Batavia (2009-05):]
We note that most of this issue has become moot over time,and agree with Alisdair's recommendations.Move to NAD Future for reconsideration of part (ii).
[2009-07-29 Alisdair reopens:]
This infamous issue was closed as NAD Future when concepts introducedsupport for proxy iterators, so the only remaining requirement was toprovide a better type to support bitsets of dynamic length. I fear wemust re-open this issue until the post-concept form of iterators isavailable, and hopefully will support the necessary proxy functionalityto allow us to close this issue as NAD.
I recommend we spawn a separate issue (1184(i)) requesting a dynamic length bitsetand pre-emptively file it as NAD Future. It is difficult to resolve #96when it effectively contains two separate sub-issues.
[2009-10 Santa Cruz:]
Mark as NAD, and give rationale.
Proposed resolution:
Rationale:
We want to support proxy iterators but that is going to be separatework. Don't want to see this issue come back in these kinds of terms.We're interested in a separate container, and proxy iterators, but bothof those are separate issues.
We've looked at a lot of ways to fix this that would be close to this,but those things would break existing code. Attempts to fix thisdirectly have not been tractable, and removing it has not beentractable. Therefore we are closing.
Section: 23[containers]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [containers].
View all otherissues in [containers].
View all issues withNAD status.
Discussion:
insert(iterator, const value_type&) is defined both onsequences and on set, with unrelated semantics: insert here (insequences), and insert with hint (in associative containers). Theyshould have different names (B.S. says: do not abuse overloading).
Rationale:
This is not a defect in the Standard. It is a genetic misfortune ofthe design, for better or for worse.
Section: 24.5.1.8[reverse.iter.cmp]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2021-06-06
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
The <, >, <=, >= comparison operator are wrong: theyreturn the opposite of what they should.
Note: same problem in CD2, these were not even defined in CD1. SGISTL code is correct; this problem is known since the Morristownmeeting but there it was too late
Rationale:
This is not a defect in the Standard. A careful reading shows the Standard is correctas written. A review of several implementations show that they implementexactly what the Standard says.
Section: 24.5.2[insert.iterators], 24.6.5[ostreambuf.iterator]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [insert.iterators].
View all issues withNAD status.
Discussion:
Overspecified For an insert iterator it, the expression *it isrequired to return a reference to it. This is a simple possibleimplementation, but as the SGI STL documentation says, not the onlyone, and the user should not assume that this is the case.
Rationale:
The LWG believes this causes no harm and is not a defect in thestandard. The only example anyone could come up with caused someincorrect code to work, rather than the other way around.
Section: 23.3.13[vector], 23.3.3[array]Status:NAD EditorialSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [vector].
View all issues withNAD Editorial status.
Discussion:
Reserve can not free storage, unlike string::reserve
[2010-02-13 Alisdair adds:]
This issue has been revisited and addressed (755(i),850(i)). This issues should be reclassified to NAD Editorial to reflectthis action.
Rationale:
This is not a defect in the Standard. The LWG has considered thisissue in the past and sees no need to change the Standard. Deque hasno reserve() member function. For vector, shrink-to-fit can beexpressed in a single line of code (wherev isvector<T>):
vector<T>(v).swap(v); // shrink-to-fit v
Section: 23.2.7[associative.reqmts]Status:DupSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withDup status.
Duplicate of:264
Discussion:
Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seemsimpossible to implement, as it means that if [i, j) = [x], insert in an associativecontainer is O(1)!
Proposed resolution:
N+log (size()) if [i,j) is sorted according to value_comp()
Rationale:
Section: 27.4.3.5[string.capacity]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.capacity].
View all issues withNAD status.
Discussion:
It is not clear that undefined behavior applies when pos == size ()for the non const version.
Proposed resolution:
Rewrite as: Otherwise, if pos > size () or pos == size () andthe non-const version is used, then the behavior is undefined.
Rationale:
The Standard is correct. The proposed resolution already appears inthe Standard.
Section: 31.10[file.streams]Status:DupSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [file.streams].
View all issues withDup status.
Duplicate of:454
Discussion:
fstream ctors take a const char* instead of string.
fstream ctors can't take wchar_t
An extension to add a const wchar_t* to fstream would make theimplementation non conforming.
Rationale:
This is not a defect in the Standard. It might be aninteresting extension for the next Standard.
Section: 29.6.2[template.valarray]Status:NADSubmitter: AFNOROpened: 1998-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [template.valarray].
View all issues withNAD status.
Discussion:
The order of the arguments is (elem, size) instead of the normal(size, elem) in the rest of the library. Since elem often has anintegral or floating point type, both types are convertible to eachother and reversing them leads to a well formed program.
Proposed resolution:
Inverting the arguments could silently break programs. Introducethe two signatures (const T&, size_t) and (size_t, const T&),but make the one we do not want private so errors result in adiagnosed access violation. This technique can also be applied to STLcontainers.
Rationale:
The LWG believes that while the order of arguments is unfortunate,it does not constitute a defect in the standard. The LWG believes thatthe proposed solution will not work for valarray<size_t> andperhaps other cases.
istreambuf_iterator::equal overspecified, inefficientSection: 24.6.4.4[istreambuf.iterator.ops]Status:NADSubmitter: Nathan MyersOpened: 1998-10-15Last modified: 2017-11-29
Priority:Not Prioritized
View all otherissues in [istreambuf.iterator.ops].
View all issues withNAD status.
Discussion:
The memberistreambuf_iterator<>::equal is specified to beunnecessarily inefficient. While this does not affect the efficiencyof conforming implementations of iostreams, because they can"reach into" the iterators and bypass this function, it doesaffect users who useistreambuf_iterators.
The inefficiency results from a too-scrupulous definition, whichrequires a "true" result if neither iterator is at eof. Inpractice these iterators can only usefully be compared with the"eof" value, so the extra test implied provides no benefit,but slows down users' code.
The solution is to weaken the requirement on the function to returntrue only if both iterators are at eof.
[Summit:]
Reopened by Alisdair.
[Post Summit Daniel adds:]
Recommend NAD. The proposed wording would violate the axioms ofconcept requirement
EqualityComparableaxioms as part of conceptInputIteratorand more specifically it would violate the explicit wording of24.3.5.3[input.iterators]/7:If two iterators
aandbof the same type are equal, then eitheraandbare both dereferenceable or else neither is dereferenceable.[2009-07 Frankfurt]
Agree NAD.
Proposed resolution:
Replace [istreambuf.iterator::equal], paragraph 1,
-1-Returns: true if and only if both iterators are at end-of-stream, or neither is at end-of-stream, regardless of what streambuf object they use.
with
-1-Returns: true if and only if both iterators are at end-of-stream, regardless of what streambuf object they use.
Rationale:
It is not clear that this is a genuine defect. Additionally, theLWG was reluctant to make a change that would result inoperator== not being a equivalence relation. One consequence ofthis change is that an algorithm that's passed the range[i, i)would no longer treat it as an empty range.
Section: 31.7.5.2[istream], 31.7.5.4[istream.unformatted]Status:NADSubmitter: Steve ClamageOpened: 1998-10-13Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream].
View all issues withNAD status.
Discussion:
In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,paragraph 36.
Following the chain of definitions, I find that the various sync functions have definedsemantics for output streams, but no semantics for input streams. On the other hand,basic_ostream has no sync function.
The sync function should at minimum be added to basic_ostream, for internalconsistency.
A larger question is whether sync should have assigned semantics for input streams.
Classic iostreams said streambuf::sync flushes pending output and attempts to returnunread input characters to the source. It is a protected member function. The filebufversion (which is public) has that behavior (it backs up the read pointer). Classstrstreambuf does not override streambuf::sync, and so sync can't be called on astrstream.
If we can add corresponding semantics to the various sync functions, we should. If not,we should remove sync from basic_istream.
Rationale:
A sync function is not needed in basic_ostream because the flush function provides thedesired functionality.
As for the other points, the LWG finds the standard correct as written.
Section: 22.9.2[template.bitset]Status:DupSubmitter: Judy WardOpened: 1998-11-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [template.bitset].
View all issues withDup status.
Duplicate of:778
Discussion:
The following code does not compile with the EDG compiler:
#include <bitset>using namespace std;bitset<32> b("111111111");If you cast the ctor argument to a string, i.e.:
bitset<32> b(string("111111111"));then it will compile. The reason is that bitset has the following templatizedconstructor:
template <class charT, class traits, class Allocator>explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);
According to the compiler vendor, Steve Adamcyk at EDG, the usercannot pass this template constructor aconst char* andexpect a conversion tobasic_string. The reason is"When you have a template constructor, it can get used incontexts where type deduction can be done. Type deduction basicallycomes up with exact matches, not ones involving conversions."
I don't think the intention when this constructor becametemplatized was for construction from aconst char* to nolonger work.
Proposed resolution:
Add to 22.9.2[template.bitset] a bitset constructor declaration
explicit bitset(const char*);
and in Section 22.9.2.2[bitset.cons] add:
explicit bitset(const char* str);Effects:
Callsbitset((string) str, 0, string::npos);
Rationale:
Although the problem is real, the standard is designed that way soit is not a defect. Education is the immediate workaround. A futurestandard may wish to consider the Proposed Resolution as anextension.
Section: 28.3.3.1.2.1[locale.category]Status:NADSubmitter: Judy WardOpened: 1998-12-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.category].
View all issues withNAD status.
Discussion:
Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> ,ctype<wchar_t>.
Also Section 28.3.4.2.2[locale.ctype] says:
The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and ctype<wchar_t> , implement character classing appropriate to the implementation's native character set.
However, Section 28.3.4.2.4[facet.ctype.special]only has a detailed description of the ctype<char> specialization, not thectype<wchar_t> specialization.
Proposed resolution:
Add the ctype<wchar_t> detailed class description to Section 28.3.4.2.4[facet.ctype.special].
Rationale:
Specialization for wchar_t is not needed since the default is acceptable.
Section: 31.8[string.streams], 31.10[file.streams]Status:NADSubmitter: Angelika LangerOpened: 1999-02-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.streams].
View all issues withNAD status.
Discussion:
The following question came from Thorsten Herlemann:
You can set a mode when constructing or opening a file-stream or filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get that mode later on, e.g. in my own operator << or operator >> or when I want to check whether a file-stream or file-buffer object passed as parameter is opened for input or output or binary? Is there no possibility? Is this a design-error in the standard C++ library?
It is indeed impossible to find out what a stream's or streambuffer's open mode is, and without that knowledge you don't knowhow certain operations behave. Just think of the append mode.
Both streams and stream buffers should have amode() function that returns thecurrent open mode setting.
[post Bellevue: Alisdair requested to re-Open.]
[2009-07 Frankfurt]
Neither Howard nor Bill has received a customer request for this.
No consensus for change. The programmer can save this information to the side.
Moved to NAD.
Proposed resolution:
For stream buffers, add a function to the base class as a non-virtual functionqualified as const to 31.6.3[streambuf]:
openmode mode() const;
Returns the current open mode.
With streams, I'm not sure what to suggest. In principle, the modecould already be returned byios_base, but the mode is onlyinitialized for file and string stream objects, unless I'm overlookinganything. For this reason it should be added to the most derivedstream classes. Alternatively, it could be added tobasic_iosand would be default initialized inbasic_ios<>::init().
Rationale:
This might be an interesting extension for some future, but it isnot a defect in the current standard. The Proposed Resolution isretained for future reference.
Section: 23.3.11.5[list.ops]Status:NADSubmitter: Howard HinnantOpened: 1999-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [list.ops].
View all issues withNAD status.
Discussion:
What happens if a splice operation causes the size() of a list to grow beyond max_size()?
Rationale:
Size() cannot grow beyond max_size().
Section: 31.7.5.7.2[iostream.cons]Status:NADSubmitter: Howard HinnantOpened: 1999-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
-1- Effects Constructs an object of class basic_iostream, assigninginitial values to the base classes by callingbasic_istream<charT,traits>(sb) (lib.istream) andbasic_ostream<charT,traits>(sb) (lib.ostream)
The called for basic_istream and basic_ostream constructors callinit(sb). This means that the basic_iostream's virtual base class isinitialized twice.
Proposed resolution:
Change 27.6.1.5.1, paragraph 1 to:
-1- Effects Constructs an object of class basic_iostream, assigninginitial values to the base classes by callingbasic_istream<charT,traits>(sb) (lib.istream).
Rationale:
The LWG agreed that the init() function is calledtwice, but said that this is harmless and so not a defect in thestandard.
ctype_byname<char> redundant and misleadingSection: 28.3.4.2.5[locale.codecvt]Status:NADSubmitter: Angelika LangerOpened: 1999-03-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt].
View all issues withNAD status.
Discussion:
Section 28.3.4.2.5[locale.codecvt] specifies thatctype_byname<char> must be a specialization of thectype_bynametemplate.
It is common practice in the standard that specializations of class templates are onlymentioned where the interface of the specialization deviates from the interface of thetemplate that it is a specialization of. Otherwise, the fact whether or not a requiredinstantiation is an actual instantiation or a specialization is left open as animplementation detail.
Clause 22.2.1.4 deviates from that practice and for that reason is misleading. Thefact, thatctype_byname<char> is specified as a specialization suggests that theremust be something "special" about it, but it has the exact same interface as thectype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at bestredundant, at worst misleading - unless I am missing anything.
Naturally, an implementation will most likely implementctype_byname<char> as aspecialization, because the base classctype<char> is a specialization with aninterface different from thectype template, but that's an implementation detail and neednot be mentioned in the standard.
[Summit:]
Reopened by Alisdair.
[2009-07 Frankfurt]
Moved to NAD.
Rationale:
The standard as written is mildly misleading, but the correct fixis to deal with the underlying problem in thectype_byname base class,not in the specialization. See issue228(i).
Section: 23.4.3[map]Status:NAD EditorialSubmitter: Mark MitchellOpened: 1999-04-14Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [map].
View all issues withNAD Editorial status.
Discussion:
23.2[container.requirements]
expression return type pre/post-condition
------------- ----------- -------------------
X::value_type T T is assignable
23.4.3[map]
A map satisfies all the requirements of a container.
For a map<Key, T> ... the value_type is pair<const Key, T>.
There's a contradiction here. In particular, `pair<const Key,T>' is not assignable; the `const Key' cannot be assignedto. So, map<Key, T>::value_type does not satisfy theassignable requirement imposed by a container.
[See issue103(i) for the slightly related issue ofmodification of set keys.]
Rationale:
The LWG believes that the standard is inconsistent, but that thisis a design problem rather than a strict defect. May wish toreconsider for the next standard.
Section: 17.15[support.c.headers]Status:NADSubmitter: Christophe de DinechinOpened: 1999-05-04Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [support.c.headers].
View all issues withNAD status.
Discussion:
[depr.c.headers] paragraph 2 reads:
Each C header, whose name has the form name.h, behaves as if eachname placed in the Standard library namespace by the correspondingcname header is also placed within the namespace scope of thenamespace std and is followed by an explicit using-declaration(_namespace.udecl_)
I think it should mention the global name space somewhere... Currently, it indicates that name placed in std is also placed instd...
I don't know what is the correct wording. For instance, if structtm is defined in time.h, ctime declares std::tm. However, the currentwording seems ambiguous regarding which of the following would occurfor use of both ctime and time.h:
// version 1:namespace std { struct tm { ... };}using std::tm;// version 2:struct tm { ... };namespace std { using ::tm;}// version 3:struct tm { ... };namespace std { struct tm { ... };}I think version 1 is intended.
[Kona: The LWG agreed that the wording is not clear. It alsoagreed that version 1 is intended, version 2 is not equivalent toversion 1, and version 3 is clearly not intended. The example belowwas constructed by Nathan Myers to illustrate why version 2 is notequivalent to version 1.
Although not equivalent, the LWG is unsure if (2) is enough ofa problem to be prohibited. Points discussed in favor of allowing(2):
- It may be a convenience to implementors.
- The only cases that fail are structs, of which the C library contains only a few.
]
Example:
#include <time.h>#include <utility>int main() { std::tm * t; make_pair( t, t ); // okay with version 1 due to Koenig lookup // fails with version 2; make_pair not found return 0;}Proposed resolution:
Replace [depr.c.headers] paragraph 2 with:
Each C header, whose name has the form name.h, behaves as if eachname placed in the Standard library namespace by the correspondingcname header is also placed within the namespace scope of thenamespace std by name.h and is followed by an explicitusing-declaration (_namespace.udecl_) in global scope.
Rationale:
The current wording in the standard is the result of a difficultcompromise that averted delay of the standard. Based on discussionsin Tokyo it is clear that there is no still no consensus on stricterwording, so the issue has been closed. It is suggested that users notwrite code that depends on Koenig lookup of C library functions.
Section: 31.5.4.2[basic.ios.cons]Status:NADSubmitter: Angelika LangerOpened: 1999-05-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [basic.ios.cons].
View all issues withNAD status.
Discussion:
There is no initial value for the adjustfield defined, althoughmany people believe that the default adjustment were right. This is acommon misunderstanding. The standard only defines that, if noadjustment is specified, all the predefined inserters must add fillcharacters before the actual value, which is "as if" theright flag were set. The flag itself need not be set.
When you implement a user-defined inserter you cannot rely on rightbeing the default setting for the adjustfield. Instead, you must beprepared to find none of the flags set and must keep in mind that inthis case you should make your inserter behave "as if" theright flag were set. This is surprising to many people and complicatesmatters more than necessary.
Unless there is a good reason why the adjustfield should not beinitialized I would suggest to give it the default value thateverybody expects anyway.
Rationale:
This is not a defect. It is deliberate that the default is no bitsset. Consider Arabic or Hebrew, for example. See 28.3.4.3.3.3[facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
pword() andiword()Section: 31.5.2.6[ios.base.storage]Status:DupSubmitter: Dietmar KühlOpened: 1999-07-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ios.base.storage].
View all issues withDup status.
Duplicate of:41
Discussion:
According to paragraphs 2 and 4 of 31.5.2.6[ios.base.storage], thefunctionsiword() andpword() "set thebadbit (which might throw an exception)" onfailure. ... but what does it mean forios_base to set thebadbit? The state facilities of the IOStream library aredefined inbasic_ios, a derived class! It would be possibleto attempt a down cast but then it would be necessary to know thecharacter type used...
Rationale:
Section: 31.7.5.3.3[istream.extractors]Status:DupSubmitter: Dietmar KühlOpened: 1999-07-20Last modified: 2017-04-22
Priority:Not Prioritized
View all otherissues in [istream.extractors].
View all issues withDup status.
Duplicate of:60
Discussion:
It appears to be somewhat nonsensical to consider the functionsdefined in the paragraphs 1 to 5 to be "Formatted inputfunction" but since these functions are defined in a sectionlabeled "Formatted input functions" it is unclear to mewhether these operators are considered formatted input functions whichhave to conform to the "common requirements" from 31.7.5.3.1[istream.formatted.reqmts]: If this is the case, all manipulators, not justws, would skip whitespace unlessnoskipws is set(... but settingnoskipws using the manipulator syntax wouldalso skip whitespace :-)
See also issue166(i) for the same problem in formattedoutput
Rationale:
gcount() after a call togcountSection: 31.7.5.4[istream.unformatted]Status:DupSubmitter: Dietmar KühlOpened: 1999-07-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream.unformatted].
View all issues withDup status.
Duplicate of:60
Discussion:
It is not clear which functions are to be considered unformattedinput functions. As written, it seems that all functions in 31.7.5.4[istream.unformatted] are unformatted input functions. However, it does notreally make much sense to construct a sentry object forgcount(),sync(), ... Also it is unclear whathappens to thegcount() if eg.gcount(),putback(),unget(), orsync() is called:These functions don't extract characters, some of them even"unextract" a character. Should this still be reflected ingcount()? Of course, it could be read as if after a call togcount()gcount() return0 (the lastunformatted input function,gcount(), didn't extract anycharacter) and after a call toputback()gcount()returns-1 (the last unformatted input functionputback() did "extract" back into thestream). Correspondingly forunget(). Is this what isintended? If so, this should be clarified. Otherwise, a correspondingclarification should be used.
Rationale:
Section: 31.7.6.3.3[ostream.inserters]Status:DupSubmitter: Dietmar KühlOpened: 1999-07-20Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withDup status.
Duplicate of:60
Discussion:
From 31.7.6.3.1[ostream.formatted.reqmts] it appears that all the functionsdefined in 31.7.6.3.3[ostream.inserters] have to construct asentry object. Is this really intended?
This is basically the same problem as issue162(i) butfor output instead of input.
Rationale:
Section: 29.4.6[complex.ops]Status:NADSubmitter: Judy WardOpened: 1999-07-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [complex.ops].
View all issues withNAD status.
Discussion:
A user who tries to explicitly instantiate a complex non-member operator willget compilation errors. Below is a simplified example of the reason why. Theproblem is that iterator_traits cannot be instantiated on a non-pointer typelike float, yet when the compiler is trying to decide which operator+ needs tobe instantiated it must instantiate the declaration to figure out the firstargument type of a reverse_iterator operator.
namespace std {template <class Iterator> struct iterator_traits{ typedef typename Iterator::value_type value_type;};template <class T> class reverse_iterator;// reverse_iterator operator+template <class T> reverse_iterator<T> operator+(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&);template <class T> struct complex {};// complex operator +template <class T>complex<T> operator+ (const T& lhs, const complex<T>& rhs) { return complex<T>();} }// request for explicit instantiationtemplate std::complex<float> std::operator+<float>(const float&, const std::complex<float>&);See also c++-stdlib reflector messages: lib-6814, 6815, 6816.
Rationale:
Implementors can make minor changes and the example willwork. Users are not affected in any case.
According to JohnSpicer, It is possible to explicitly instantiate these operators usingdifferent syntax: change "std::operator+<float>" to"std::operator+".
The proposed resolution of issue 120 is that users will not be ableto explicitly instantiate standard library templates. If thatresolution is accepted then library implementors will be the only onesthat will be affected by this problem, and they must use the indicatedsyntax.
Section: 31.4.3[narrow.stream.objects]Status:NADSubmitter: Judy WardOpened: 1999-07-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [narrow.stream.objects].
View all issues withNAD status.
Discussion:
Section 27.3.1 says "After the object cerr is initialized,cerr.flags() & unitbuf is nonzero. Its state is otherwise the same asrequired for ios_base::init (lib.basic.ios.cons). It doesn't sayanything about the the state of clog. So this means that callingcerr.tie() and clog.tie() should return 0 (see Table 89 forios_base::init effects).
Neither of the popular standard library implementationsthat I tried does this, they both tie cerr and clogto &cout. I would think that would be what users expect.
Rationale:
The standard is clear as written.
27.3.1/5 says that "After the object cerr is initialized, cerr.flags()& unitbuf is nonzero. Its state is otherwise the same as required forios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives thepostconditions of basic_ios::init(), says that tie() is 0. (Other issues correctios_base::init to basic_ios::init().)
Section: 29.6.2.7[valarray.cassign]Status:NADSubmitter: Gabriel Dos ReisOpened: 1999-08-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.cassign].
View all issues withNAD status.
Discussion:
26.5.2.6 defines augmented assignment operatorsvalarray<T>::op=(const T&), but fails to providecorresponding versions for the helper classes. Thus making thefollowing illegal:
#include <valarray>int main(){std::valarray<double> v(3.14, 1999);v[99] *= 2.0; // Okstd::slice s(0, 50, 2);v[s] *= 2.0; // ERROR}I can't understand the intent of that omission. It makes thevalarray library less intuitive and less useful.
Rationale:
Although perhaps an unfortunatedesign decision, the omission is not a defect in the currentstandard. A future standard may wish to add the missingoperators.
Section: 26.8.9[alg.min.max]Status:NADSubmitter: Mark RintoulOpened: 1999-08-26Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withNAD status.
Discussion:
Both std::min and std::max are defined as template functions. Thisis very different than the definition of std::plus (and similarstructs) which are defined as function objects which inheritstd::binary_function.
This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which requirea function object that inherits std::binary_function.
[post Bellevue: Alisdair requested to re-Open.]
[2009-07 Frankfurt]
C++0x has lambdas to address this problem now.
Moved to NAD.
Rationale:
Although perhaps an unfortunate design decision, the omission is not a defectin the current standard. A future standard may wish to consider additionalfunction objects.
Section: 26.8.4[alg.binary.search]Status:NADSubmitter: Nico JosuttisOpened: 1999-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.binary.search].
View all issues withNAD status.
Discussion:
The complexity of binary_search() is stated as "At mostlog(last-first) + 2 comparisons", which seems to say that thealgorithm has logarithmic complexity. However, this algorithms isdefined for forward iterators. And for forward iterators, the need tostep element-by-element results into linear complexity. But such astatement is missing in the standard. The same applies tolower_bound(), upper_bound(), and equal_range().
However, strictly speaking the standard contains no bug here. So thismight considered to be a clarification or improvement.
Rationale:
The complexity is expressed in terms of comparisons, and thatcomplexity can be met even if the number of iterators accessed islinear. Paragraph 1 already says exactly what happens toiterators.
Section: 23.2.7[associative.reqmts]Status:NADSubmitter: Ed BreyOpened: 1999-06-06Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Duplicate of:233
Discussion:
As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers fromseveral problems:
| expression | return type | pre/post-condition | complexity |
a.insert(p,t) | iterator | inserts t if and only if there is no element with key equivalent to the key of t in containers with unique keys; always inserts t in containers with equivalent keys. always returns the iterator pointing to the element with key equivalent to the key of t . iterator p is a hint pointing to where the insert should start to search. | logarithmic in general, but amortized constant if t is inserted right after p . |
1. For a container with unique keys, only logarithmic complexity isguaranteed if no element is inserted, even though constant complexity is alwayspossible if p points to an element equivalent to t.
2. For a container with equivalent keys, the amortized constant complexityguarantee is only useful if no key equivalent to t exists in the container.Otherwise, the insertion could occur in one of multiple locations, at least oneof which would not be right after p.
3. By guaranteeing amortized constant complexity only when t is insertedafter p, it is impossible to guarantee constant complexity if t is inserted atthe beginning of the container. Such a problem would not exist if amortizedconstant complexity was guaranteed if t is inserted before p, since there isalways some p immediately before which an insert can take place.
4. For a container with equivalent keys, p does not allow specification ofwhere to insert the element, but rather only acts as a hint for improvingperformance. This negates the added functionality that p would provide if itspecified where within a sequence of equivalent keys the insertion should occur.Specifying the insert location provides more control to the user, whileproviding no disadvantage to the container implementation.
Proposed resolution:
In 23.2.7[associative.reqmts] paragraph 7, replace the row in table 69for a.insert(p,t) with the following two rows:
| expression | return type | pre/post-condition | complexity |
a_uniq.insert(p,t) | iterator | inserts t if and only if there is no element with key equivalent to the key of t. returns the iterator pointing to the element with key equivalent to the key of t. | logarithmic in general, but amortized constant if t is inserted right before p or p points to an element with key equivalent to t. |
a_eq.insert(p,t) | iterator | inserts t and returns the iterator pointing to the newly inserted element. t is inserted right before p if doing so preserves the container ordering. | logarithmic in general, but amortized constant if t is inserted right before p. |
Rationale:
Too big a change. Furthermore, implementors report checkingboth before p and after p, and don't want to change this behavior.
Section: 31.5.4[ios]Status:NADSubmitter: Steve ClamageOpened: 1999-09-07Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
In classic iostreams, base class ios had an rdbuf function that returned apointer to the associated streambuf. Each derived class had its own rdbuffunction that returned a pointer of a type reflecting the actual type derivedfrom streambuf. Because in ARM C++, virtual function overrides had to have thesame return type, rdbuf could not be virtual.
In standard iostreams, we retain the non-virtual rdbuf function design, andin addition have an overloaded rdbuf function that sets the buffer pointer.There is no need for the second function to be virtual nor to be implemented inderived classes.
Minor question: Was there a specific reason not to make the original rdbuffunction virtual?
Major problem: Friendly compilers warn about functions in derived classesthat hide base-class overloads. Any standard implementation of iostreams willresult in such a warning on each of the iostream classes, because of theill-considered decision to overload rdbuf only in a base class.
In addition, users of the second rdbuf function must use explicitqualification or a cast to call it from derived classes. An explicitqualification or cast to basic_ios would prevent access to any later overridingversion if there was one.
What I'd like to do in an implementation is add a using- declaration for thesecond rdbuf function in each derived class. It would eliminate warnings abouthiding functions, and would enable access without using explicit qualification.Such a change I don't think would change the behavior of any valid program, butwould allow invalid programs to compile:
filebuf mybuf; fstream f; f.rdbuf(mybuf); // should be an error, no visible rdbuf
I'd like to suggest this problem as a defect, with the proposed resolution torequire the equivalent of a using-declaration for the rdbuf function that is notreplaced in a later derived class. We could discuss whether replacing thefunction should be allowed.
Rationale:
For historical reasons, the standard is correct as written. There is a subtle difference between the baseclass rdbuf() and derived classrdbuf(). The derivedclass rdbuf() always returns the original streambuf, whereas the base class rdbuf() will return the "current streambuf" if that has been changed by the variant you mention.
Permission is not required to add such an extension. See 16.4.6.5[member.functions].
Section: 17.6.3.4[new.delete.placement]Status:DupSubmitter: Herb SutterOpened: 1998-12-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [new.delete.placement].
View all issues withDup status.
Duplicate of:114
Discussion:
The example in 17.6.3.4[new.delete.placement] paragraph 4 reads:
[Example: This can be useful for constructing an object at a known address:
char place[sizeof(Something)];end example]
Something* p = new (place) Something();
This example has potential alignment problems.
Rationale:
Section: 16.4.4.6[allocator.requirements], 23.2[container.requirements]Status:NADSubmitter: Andy SawyerOpened: 1999-10-21Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
Must the value returned by max_size() be unchanged from call to call?
Must the value returned from max_size() be meaningful?
Possible meanings identified in lib-6827:
1) The largest container the implementation can support given "bestcase" conditions - i.e. assume the run-time platform is "configured tothe max", and no overhead from the program itself. This may possiblybe determined at the point the library is written, but certainly nolater than compile time.
2) The largest container the program could create, given "best case"conditions - i.e. same platform assumptions as (1), but take intoaccount any overhead for executing the program itself. (or, roughly"storage=storage-sizeof(program)"). This does NOT include any resourceallocated by the program. This may (or may not) be determinable atcompile time.
3) The largest container the current execution of the program couldcreate, given knowledge of the actual run-time platform, but again,not taking into account any currently allocated resource. This isprobably best determined at program start-up.
4) The largest container the current execution program could create atthe point max_size() is called (or more correctly at the pointmax_size() returns :-), given it's current environment (i.e. takinginto account the actual currently available resources). This,obviously, has to be determined dynamically each time max_size() iscalled.
Proposed resolution:
Rationale:
max_size() isn't useful for very many things, and the existing wording is sufficiently clear for the few cases that max_size() can be used for. None of the attempts to change the existing wording were an improvement.
It is clear to the LWG that the value returned by max_size() can't change from call to call.
Section: 31.7.5.2.4[istream.sentry]Status:NADSubmitter: Matt McClure and Dietmar KühlOpened: 2000-01-01Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [istream.sentry].
View all issues withNAD status.
Discussion:
27.6.1.1.2 Paragraph 4 states:
To decide if the character c is a whitespace character, the constructor performs ''as if'' it executes the following code fragment:
const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc());if (ctype.is(ctype.space,c)!=0)// c is a whitespace character.
But Table 51 in 22.1.1.1.1 only requires an implementation toprovide specializations for ctype<char> andctype<wchar_t>. If sentry's constructor is implemented usingctype, it will be uninstantiable for a user-defined character typecharT, unless the implementation has provided non-working (since itwould be impossible to define a correct ctype<charT> specializationfor an arbitrary charT) definitions of ctype's virtual memberfunctions.
It seems the intent the standard is that sentry should behave, inevery respect, not just during execution, as if it were implementedusing ctype, with the burden of providing a ctype specializationfalling on the user. But as it is written, nothing requires thetranslation of sentry's constructor to behave as if it used the abovecode, and it would seem therefore, that sentry's constructor should beinstantiable for all character types.
Note: If I have misinterpreted the intent of the standard withrespect to sentry's constructor's instantiability, then a note shouldbe added to the following effect:
An implementation is forbidden from using the above code if it rendersthe constructor uninstantiable for an otherwise valid charactertype.
In any event, some clarification is needed.
Rationale:
It is possible but not easy to instantiate on types other than charor wchar_t; many things have to be done first. That is by intentionand is not a defect.
Section: 24.4.3[iterator.operations]Status:NADSubmitter: Rintala MattiOpened: 2000-01-28Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [iterator.operations].
View all otherissues in [iterator.operations].
View all issues withNAD status.
Discussion:
Section 24.3.4 describes the function distance(first, last) (where first andlast are iterators) which calculates "the number of increments ordecrements needed to get from 'first' to 'last'".
The function should work for forward, bidirectional and random accessiterators, and there is a requirement 24.3.4.5 which states that "'last'must be reachable from 'first'".
With random access iterators the function is easy to implement as "last- first".
With forward iterators it's clear that 'first' must point to a place before'last', because otherwise 'last' would not be reachable from 'first'.
But what about bidirectional iterators? There 'last' is reachable from'first' with the -- operator even if 'last' points to an earlier position than'first'. However, I cannot see how the distance() function could be implementedif the implementation does not know which of the iterators points to an earlierposition (you cannot use ++ or -- on either iterator if you don't know whichdirection is the "safe way to travel").
The paragraph 24.3.4.1 states that "for ... bidirectional iterators theyuse ++ to provide linear time implementations". However, the ++ operator isnot mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitlymentions that distance() returns the number of increments _or decrements_,suggesting that it could return a negative number also for bidirectionaliterators when 'last' points to a position before 'first'.
Is a further requirement is needed to state that for forward andbidirectional iterators "'last' must be reachable from 'first' using the ++operator". Maybe this requirement might also apply to random accessiterators so that distance() would work the same way for every iteratorcategory?
Rationale:
"Reachable" is defined in the standard in 24.3.4[iterator.concepts] paragraph 6.The definition is only in terms of operator++(). The LWG sees no defect inthe standard.
Section: 17.3.5.2[numeric.limits.members]Status:NADSubmitter: Steve ClearyOpened: 2000-01-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numeric.limits.members].
View all issues withNAD status.
Discussion:
In several places in 17.3.5.2[numeric.limits.members], a member isdescribed as "Meaningful for all floating point types."However, no clear method of determining a floating point type isprovided.
In 17.3.5.3[numeric.special], paragraph 1 states ". . . (forexample, epsilon() is only meaningful if is_integer isfalse). . ." which suggests that a type is a floating point typeif is_specialized is true and is_integer is false; however, this isunclear.
When clarifying this, please keep in mind this need of users: whatexactly is the definition of floating point? Would a fixed point orrational representation be considered one? I guess my statement hereis that there could also be types that are neither integer or(strictly) floating point.
Rationale:
It is up to the implementor of a user define type to decide if it is afloating point type.
Section: 28.3.4.2.4.3[facet.ctype.char.members]Status:DupSubmitter: Robert KlarerOpened: 1999-11-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [facet.ctype.char.members].
View all issues withDup status.
Duplicate of:153
Discussion:
Thewiden andnarrow member functions are describedin 22.2.1.3.2, paragraphs 9-11. In each case we have two overloadedsignatures followed by aReturns clause. TheReturnsclause only describes one of the overloads.
Proposed resolution:
Change the returns clause in 28.3.4.2.4.3[facet.ctype.char.members]paragraph 10 from:
Returns: do_widen(low, high, to).
to:
Returns: do_widen(c) or do_widen(low, high, to), respectively.
Change the returns clause in 28.3.4.2.4.3[facet.ctype.char.members] paragraph 11from:
Returns: do_narrow(low, high, to).
to:
Returns: do_narrow(c) or do_narrow(low, high, to), respectively.
Rationale:
Subsumed by issue153(i), which addresses the sameparagraphs.
Section: 29.7[c.math]Status:NADSubmitter: Nico JosuttisOpened: 2000-02-26Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
Due to the additional overloaded versions of numeric functions forfloat and long double according to Section 26.5, calls such as int x;std::pow (x, 4) are ambiguous now in a standard conformingimplementation. Current implementations solve this problem verydifferent (overload for all types, don't overload for float and longdouble, use preprocessor, follow the standard and getambiguities).
This behavior should be standardized or at leastidentified as implementation defined.
Rationale:
These math issues are anunderstood and accepted consequence of the design. They havebeen discussed several times in the past. Users must write castsor write floating point expressions as arguments.
Section: 23.2.7[associative.reqmts]Status:NADSubmitter: Judy WardOpened: 2000-02-29Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
A user noticed that this doesn't compile with the Rogue Wave library becausethe rb_tree class declares a key_allocator, and allocator<const int> isnot legal, I think:
map < const int, ... > // legal?
which made me wonder whether it is legal for a map's key_type to be const. Inemail from Matt Austern he said:
I'm not sure whether it's legal to declare a map with a const key type. Ihadn't thought about that question until a couple weeks ago. My intuitivefeeling is that it ought not to be allowed, and that the standard ought to sayso. It does turn out to work in SGI's library, though, and someone in thecompiler group even used it. Perhaps this deserves to be written up as an issuetoo.
Rationale:
The "key is assignable" requirement from table 69 in23.2.7[associative.reqmts] already implies the key cannot be const.
Section: 31.7.7[std.manip]Status:DupSubmitter: Hyman RosenOpened: 2000-02-29Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [std.manip].
View all otherissues in [std.manip].
View all issues withDup status.
Duplicate of:193
Discussion:
31.7.7[std.manip] paragraph 5 says:
smanip setbase(int base);Returns: An object s of unspecified type such that if out is an(instance of) basic_ostream then the expression out<<s behavesas if f(s) were called, in is an (instance of) basic_istream then theexpression in>>s behaves as if f(s) were called. Where f can bedefined as:
ios_base& f(ios_base& str, int base){ // set basefield str.setf(n == 8 ? ios_base::oct : n == 10 ? ios_base::dec : n == 16 ? ios_base::hex : ios_base::fmtflags(0), ios_base::basefield); return str;}
There are two problems here. First, f takes two parameters, so thedescription needs to say that out<<s and in>>s behave as if f(s,base)had been called. Second, f is has a parameter named base, but is written as ifthe parameter was named n.
Actually, there's a third problem. The paragraph has grammatical errors.There needs to be an "and" after the first comma, and the "Wheref" sentence fragment needs to be merged into its preceding sentence. Youmay also want to format the function a little better. The formatting above ismore-or-less what the Standard contains.
Rationale:
The resolution of this defect is subsumed by the proposed resolution forissue193(i).
[Tokyo: The LWG agrees that this is a defect and notes that itoccurs additional places in the section, all requiring fixes.]
Section: 26.8[alg.sorting]Status:NADSubmitter: Pablo HalpernOpened: 2000-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.sorting].
View all issues withNAD status.
Discussion:
Many of the algorithms take an argument, pred, of template parameter typeBinaryPredicate or an argument comp of template parameter type Compare. Thesealgorithms usually have an overloaded version that does not take the predicateargument. In these cases pred is usually replaced by the use of operator== andcomp is replaced by the use of operator<.
This use of hard-coded operators is inconsistent with other parts of thelibrary, particularly the containers library, where equality is establishedusing equal_to<> and ordering is established using less<>. Worse,the use of operator<, would cause the following innocent-looking code to haveundefined behavior:
vector<string*> vec;sort(vec.begin(), vec.end());
The use of operator< is not defined for pointers to unrelated objects. Ifstd::sort used less<> to compare elements, then the above code would bewell-defined, since less<> is explicitly specialized to produce a totalordering of pointers.
Rationale:
This use of operator== and operator< was a very deliberate, conscious, andexplicitly made design decision; these operators are often more efficient. Thepredicate forms are available for users who don't want to rely on operator== andoperator<.
find algorithm missing version that takes a binary predicate argumentSection: 26.6.6[alg.find]Status:NADSubmitter: Pablo HalpernOpened: 2000-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.find].
View all issues withNAD status.
Discussion:
The find function always searches for a value usingoperator== to compare thevalue argument to each element in the input iterator range. This is inconsistentwith other find-related functions such asfind_end andfind_first_of, whichallow the caller to specify a binary predicate object to be used for determiningequality. The fact that this can be accomplished using a combination offind_ifandbind_1st orbind_2nd does not negate the desirability of a consistent,simple, alternative interface tofind.
[Summit:]
Reopened by Alisdair.
[2009-07 Frankfurt]
The same thing can be achieved using
find_if(as noted in the issue).Moved to NAD.
Proposed resolution:
In section 26.6.6[alg.find], add a second prototype for find(between the existing prototype and the prototype for find_if), asfollows:
template<class InputIterator, class T, class BinaryPredicate> InputIterator find(InputIterator first, InputIterator last, const T& value, BinaryPredicate bin_pred);Change the description of the return from:
Returns: The first iterator
iin the range[first, last)for which the following corresponding conditions hold:*i == value,pred(*i) != false. Returnslastif no such iterator is found.to:
Returns: The first iterator
iin the range[first, last)for which the following corresponding condition holds:*i == value,bin_pred(*i,value) != false,pred(*) != false. Returnlastif no such iterator is found.
Rationale:
This is request for a pure extension, so it is not a defect in thecurrent standard. As the submitter pointed out, "this canbe accomplished using a combination offind_if andbind_1st orbind_2nd".
Section: 28.3.4.2.4.3[facet.ctype.char.members]Status:DupSubmitter: Dietmar KühlOpened: 2000-04-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [facet.ctype.char.members].
View all issues withDup status.
Duplicate of:28
Discussion:
The description of theis() member in paragraph 4 of 28.3.4.2.4.3[facet.ctype.char.members] is broken: According to this description, thesecond form of theis() method modifies the masks in thectype object. The correct semantics if, of course, to obtainan array of masks. The corresponding method in the general case,ie. thedo_is() method as described in 28.3.4.2.2.3[locale.ctype.virtuals] paragraph 1 does the right thing.
Proposed resolution:
Change paragraph 4 from
The second form, for all *p in the range [low, high), assigns vec[p-low] to table()[(unsigned char)*p].
to become
The second form, for all *p in the range [low, high), assigns table()[(unsigned char)*p] to vec[p-low].
Rationale:
find's third argument be CopyConstructible?Section: 26.6.6[alg.find]Status:NADSubmitter: Andrew KoenigOpened: 2000-05-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.find].
View all issues withNAD status.
Discussion:
Is the following implementation offind acceptable?
template<class Iter, class X> Iter find(Iter begin, Iter end, const X& x) { X x1 = x; // this is the crucial statement while (begin != end && *begin != x1) ++begin; return begin; }If the answer is yes, then it is implementation-dependent as towhether the following fragment is well formed:
vector<string> v; find(v.begin(), v.end(), "foo");
At issue is whether there is a requirement that the third argumentof find be CopyConstructible. There may be no problem here, butanalysis is necessary.
Rationale:
There is no indication in the standard that find's third argumentis required to be Copy Constructible. The LWG believes that no suchrequirement was intended. As noted above, there are times when a usermight reasonably pass an argument that is not Copy Constructible.
istream_iterator trigger input operations?Section: 24.6.2[istream.iterator]Status:NADSubmitter: Andrew KoenigOpened: 2000-05-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream.iterator].
View all issues withNAD status.
Discussion:
I do not think the standard specifies what operation(s) on istreamiterators trigger input operations. So, for example:
istream_iterator<int> i(cin); int n = *i++;
I do not think it is specified how many integers have been readfrom cin. The number must be at least 1, of course, but can it be 2?More?
Rationale:
The standard is clear as written: the stream is read every timeoperator++ is called, and it is also read either when the iterator isconstructed or when operator* is called for the first time. In theexample above, exactly two integers are read from cin.
There may be a problem with the interaction between istream_iteratorand some STL algorithms, such as find. There are no guarantees abouthow many times find may invoke operator++.
a.insert(p,t) is incorrectly specifiedSection: 23.2.7[associative.reqmts]Status:DupSubmitter: Mark RodgersOpened: 2000-05-19Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withDup status.
Duplicate of:233
Discussion:
Closed issue 192 raised several problems with the specification ofthis function, but was rejected as Not A Defect because it was too biga change with unacceptable impacts on existing implementations.However, issues remain that could be addressed with a smaller changeand with little or no consequent impact.
The specification is inconsistent with the original proposal and with several implementations.
The initial implementation by Hewlett Packard only ever looked immediatelybefore p, and I do not believe there was any intention to standardize anything other than this behavior. Consequently, current implementations by several leading implementors also look immediately before p, and will only insert after p in logarithmic time. I am only aware of one implementation that does actually look after p, and it looks before p as well. It is therefore doubtful that existing code would be relying on the behavior defined in the standard, and it would seem that fixing this defect as proposed below would standardize existing practice.
The specification is inconsistent with insertion for sequence containers.
This is difficult and confusing to teach to newcomers. All insert operations that specify an iterator as an insertion location should have a consistent meaning for the location represented by that iterator.
As specified, there is no way to hint that the insertion should occur at the beginning of the container, and the way to hint that it should occur at the end is long winded and unnatural.
For a container containing n elements, there are n+1 possible insertion locations and n+1 valid iterators. For there to be a one-to-one mapping between iterators and insertion locations, the iterator must represent an insertion location immediately before the iterator.
When appending sorted ranges using insert_iterators, insertions are guaranteed to be sub-optimal.
In such a situation, the optimum location for insertion is always immediately after the element previously inserted. The mechanics of the insert iterator guarantee that it will try and insert after the element after that, which will never be correct. However, if the container first tried to insert before the hint, all insertions would be performed in amortized constant time.
Proposed resolution:
In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, makethe following changes in the row for a.insert(p,t):
assertion/note pre/post condition:
Change the last sentence from
"iterator p is a hint pointing to where the insert should start to search."
to
"iterator p is a hint indicating that immediately before p may be a correct location where the insertion could occur."
complexity:
Change the words "right after" to "immediately before".
Rationale:
auto_ptr::operator=Section: 99 [auto.ptr]Status:NADSubmitter: Joseph GottmanOpened: 2000-06-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [auto.ptr].
View all issues withNAD status.
Discussion:
According to section 20.4.5, the functionauto_ptr::operator=() returns a reference to an auto_ptr.The reason thatoperator=() usually returns a reference is tofacilitate code like
int x,y,z; x = y = z = 1;
However, given analogous code forauto_ptrs,
auto_ptr<int> x, y, z; z.reset(new int(1)); x = y = z;
the result would be thatz andy would both be set to NULL, instead of all theauto_ptrs being set to the same value. This makes such cascading assignments useless and counterintuitive forauto_ptrs.
Proposed resolution:
Changeauto_ptr::operator=() to returnvoid insteadof anauto_ptr reference.
Rationale:
The return value has uses other than cascaded assignments: a user cancall an auto_ptr member function, pass the auto_ptr to afunction, etc. Removing the return value could break working usercode.
basic_streambuf<>::pbump() andgbump() take an int?Section: 31.6.3[streambuf]Status:NADSubmitter: Martin SeborOpened: 2000-08-12Last modified: 2017-06-06
Priority:Not Prioritized
View all otherissues in [streambuf].
View all issues withNAD status.
Discussion:
The basic_streambuf members gbump() and pbump() are specified to take anint argument. This requirement prevents the functions from effectivelymanipulating buffers larger than std::numeric_limits<int>::max()characters. It also makes the common use case for these functionssomewhat difficult as many compilers will issue a warning when anargument of type larger than int (such as ptrdiff_t on LLP64architectures) is passed to either of the function. Since it's often theresult of the subtraction of two pointers that is passed to thefunctions, a cast is necessary to silence such warnings. Finally, theusage of a native type in the functions signatures is inconsistent withother member functions (such as sgetn() and sputn()) that manipulate theunderlying character buffer. Those functions take a streamsize argument.
[2009-07 Frankfurt]
This is part of a bigger problem. If anyone cares enough, they shouldwrite a paper solving the bigger problem of offset types in iostreams.
This is related to the paper about large file sizes. Beman has alreadyagreed to drop the section of that paper that deals with this.
int is big enough for reasonable buffers.
Move to NAD Future.
[2017-02 in Kona, LEWG recommends NAD]
[2017-06-02 Issues Telecon]
Resolve as NAD
The previous rationale given suggested that LWG believes the changeis too big for now. Actually, changing the parameter type is too biga change more or less forever, because that would break everycustom streambuf type; there are too many such types in the wildto make a breaking change. The overload approach may be more plausible,but is not an entirely breakage-free solution; it can produceambiguities, and can still break streambuf hierarchies.
Proposed resolution:
Change the signatures of these functions in the synopsis of templateclass basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4and 27.5.2.3.2, p4) to take a streamsize argument.
Although this change has the potential of changing the ABI of thelibrary, the change will affect only platforms where int is differentthan the definition of streamsize. However, since both functions aretypically inline (they are on all known implementations), even on suchplatforms the change will not affect any user code unless it explicitlyrelies on the existing type of the functions (e.g., by taking theiraddress). Such a possibility is IMO quite remote.
Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
This is something of a nit, but I'm wondering if streamoff wouldn't be a better choice than streamsize. The argument to pbump and gbump MUST be signed. But the standard has this to say about streamsize (27.4.1/2/Footnote):
[Footnote: streamsize is used in most places where ISO C would use size_t. Most of the uses of streamsize could use size_t, except for the strstreambuf constructors, which require negative values. It should probably be the signed type corresponding to size_t (which is what Posix.2 calls ssize_t). — end footnote]
This seems a little weak for the argument to pbump and gbump. Should we ever really get rid of strstream, this footnote might go with it, along with the reason to make streamsize signed.
Rationale:
The LWG believes this change is too big for now. We may wish toreconsider this for a future revision of the standard. Onepossibility is overloading pbump, rather than changing thesignature.
[[2006-05-04: Reopened at the request of Chris (Krzysztof Żelechowski)]]
Section: 99 [depr.base], 99 [iterator.basic]Status:NADSubmitter: Robert DickOpened: 2000-08-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [depr.base].
View all issues withNAD status.
Discussion:
According to the November 1997 Draft Standard, the results of deleting anobject of a derived class through a pointer to an object of its base class areundefined if the base class has a non-virtual destructor. Therefore, it ispotentially dangerous to publicly inherit from such base classes.
Defect:
The STL design encourages users to publicly inherit from a number of classeswhich do nothing but specify interfaces, and which contain non-virtualdestructors.
Attribution:
Wil Evers and William E. Kempf suggested this modification for functionalobjects.
Proposed resolution:
When a base class in the standard library is useful only as an interfacespecifier, i.e., when an object of the class will never be directlyinstantiated, specify that the class contains a protected destructor. Thiswill prevent deletion through a pointer to the base class without performance,or space penalties (on any implementation I'm aware of).
As an example, replace...
template <class Arg, class Result> struct unary_function { typedef Arg argument_type; typedef Result result_type; };... with...
template <class Arg, class Result> struct unary_function { typedef Arg argument_type; typedef Result result_type; protected: ~unary_function() {} };Affected definitions:
20.3.1 [lib.function.objects] -- unary_function, binary_function
24.3.2 [lib.iterator.basic] -- iterator
Rationale:
The standard is clear as written; this is a request for change, not adefect in the strict sense. The LWG had several different objectionsto the proposed change. One is that it would prevent users fromcreating objects of typeunary_function andbinary_function. Doing so can sometimes be legitimate, if userswant to pass temporaries as traits or tag types in generic code.
Section: 99 [depr.strstreambuf.virtuals]Status:NADSubmitter: Martin SeborOpened: 2000-10-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [depr.strstreambuf.virtuals].
View all issues withNAD status.
Discussion:
It appears that the interaction of the strstreambuf members overflow()and seekoff() can lead to undefined behavior in cases where definedbehavior could reasonably be expected. The following programdemonstrates this behavior:
#include <strstream> int main () { std::strstreambuf sb; sb.sputc ('c'); sb.pubseekoff (-1, std::ios::end, std::ios::in); return !('c' == sb.sgetc ()); }D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(),which in turn sets all pointers to 0 in 27.5.2.1, p1.
27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) callsoverflow(traits::to_int_type(c)) if a write position isn't available (itisn't due to the above).
D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes atleast one write position available (i.e., it allows the function to makeany positive number of write positions available).
D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we seeseekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in thiscase. newoff is then epptr() - eback().
D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, orgptr() == epptr() + off holds.
If strstreambuf::overflow() made exactly one write position availablethen gptr() will be set to just before epptr(), and the program willreturn 0. Buf if the function made more than one write positionavailable, epptr() and gptr() will both point past pptr() and thebehavior of the program is undefined.
Proposed resolution:
Change the last sentence of 99 [depr.strstreambuf] paragraph 4 from
Otherwise, seeklow equals gbeg and seekhigh is either pend, if pend is not a null pointer, or gend.
to become
Otherwise, seeklow equals gbeg and seekhigh is either gend if 0 == pptr(), or pbase() + max where max is the maximum value of pptr() - pbase() ever reached for this stream.
[ pre-Copenhagen: Dietmar provided wording for proposed resolution.]
[ post-Copenhagen: Fixed a typo: proposed resolution said to fix 4.7.1, not D.7.1.]
Rationale:
This is related to issue65(i): it's not clear what itmeans to seek beyond the current area. Without resolving issue65(i) we can't resolve this. As with issue65(i), the library working group does not wish to invest time nailing downcorner cases in a deprecated feature.
Section: 17.9[support.exception]Status:NADSubmitter: J. Stephen AdamczykOpened: 2000-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [support.exception].
View all issues withNAD status.
Discussion:
One of our customers asks whether this is valid C++:
#include <cstdarg> void bar(const char *, va_list); void foo(const char *file, const char *, ...) { va_list ap; va_start(ap, file); bar(file, ap); va_end(ap); }The issue being whether it is valid to use cstdarg when the finalparameter before the "..." is unnamed. cstdarg is, as faras I can tell, inherited verbatim from the C standard. and thedefinition there (7.8.1.1 in the ISO C89 standard) refers to "theidentifier of the rightmost parameter". What happens when thereis no such identifier?
My personal opinion is that this should be allowed, but some tweakmight be required in the C++ standard.
Rationale:
Not a defect, the C and C++ standards are clear. It is impossible touse varargs if the parameter immediately before "..." has noname, because that is the parameter that must be passed to va_start.The example given above is broken, because va_start is being passedthe wrong parameter.
There is no support for extending varargs to provide additionalfunctionality beyond what's currently there. For reasons of C/C++compatibility, it is especially important not to make gratuitouschanges in this part of the C++ standard. The C committee has alreadybeen requested not to touch this part of the C standard unlessnecessary.
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: Matt AusternOpened: 2000-11-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
In 20.1.5, paragraph 5, the standard says that "Implementors areencouraged to supply libraries that can accept allocators thatencapsulate more general memory models and that support non-equalinstances." This is intended as normative encouragement tostandard library implementors. However, it is possible to interpretthis sentence as applying to nonstandard third-party libraries.
Proposed resolution:
In 20.1.5, paragraph 5, change "Implementors" to"Implementors of the library described in this InternationalStandard".
Rationale:
The LWG believes the normative encouragement is alreadysufficiently clear, and that there are no important consequenceseven if it is misunderstood.
Section: 23.2[container.requirements]Status:NADSubmitter: Steve ClearyOpened: 2000-11-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withNAD status.
Discussion:
This came from an email from Steve Cleary to Fergus in reference toissue179(i). The library working group briefly discussedthis in Toronto and believes it should be a separate issue.
Steve said: "We may want to state that the const/non-const iterators must havethe same difference type, size_type, and category."
(Comment from Judy)I'm not sure if the above sentence should be true for allconst and non-const iterators in a particular container, or if it means the container's iterator can't be compared with the container'sconst_iterator unless the above it true. I suspect the former.
Proposed resolution:
InSection: 23.2[container.requirements],table 65, in the assertion/note pre/post condition for X::const_iterator,add the following:
typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
typeid(X::const_iterator::category) == typeid(X::iterator::category)
Rationale:
Going through the types one by one: Iterators don't have asize_type. We already know that the difference types areidentical, because the container requirements already say that thedifference types of both X::iterator and X::const_iterator are bothX::difference_type. The standard does not require that X::iteratorand X::const_iterator have the same iterator category, but the LWGdoes not see this as a defect: it's possible to imagine cases in whichit would be useful for the categories to be different.
It may be desirable to require X::iterator and X::const_iterator tohave the same value type, but that is a new issue. (Issue322(i).)
Section: 31.5.2.3[fmtflags.state]Status:NADSubmitter: Judy WardOpened: 2000-12-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [fmtflags.state].
View all issues withNAD status.
Discussion:
The Effects clause for ios_base::setf(fmtflags fmtfl) says"Sets fmtfl in flags()". What happens if the user first callsios_base::scientific and then calls ios_base::fixed or vice-versa?This is an issue for all of the conflicting flags, i.e. ios_base::leftand ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
I see three possible solutions:
Most existing implementations that I tried seem to conform to resolution #3,except that when using the iomanip manipulator hex or oct then that always overrides dec, but calling setf(ios_base::hex) doesn't.
There is a sort of related issue, which is that although the ios_baseconstructor says that each ios_base member has an indeterminate valueafter construction, all the existing implementations I tried explicitly set ios_base::dec.
Proposed resolution:
Rationale:
adjustfield,basefield, andfloatfieldare each multi-bit fields. It is possible to set multiple bits withineach of those fields. (For example,dec andoct). These fields are used by locale facets. The LWGreviewed the way in which each of those three fields is used, andbelieves that in each case the behavior is well defined for anypossible combination of bits. See for example Table 58, in 28.3.4.3.3.3[facet.num.put.virtuals], noting the requirement in paragraph 6 of thatsection.
Users are advised to use manipulators, or else use the two-argumentversion ofsetf, to avoid unexpected behavior.
Section: 29.7[c.math]Status:NADSubmitter: Judy WardOpened: 2000-12-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
In ISO/IEC 9899:1990 Programming Languages C we find the following concerning <math.h>:
7.13.4 Mathematics <math.h>
The names of all existing functions declared in the <math.h> header, suffixed with f or l, are reserved respectively for corresponding functions with float and long double arguments are return values.
For example,float sinf(float) is reserved.
In the C99 standard, <math.h> must contain declarations for these functions.
So, is it acceptable for an implementor to add these prototypes to theC++ versions of the math headers? Are they required?
Proposed resolution:
Add these Functions to Table 80, section 26.5 and to Table 99,section C.2:
acosf asinf atanf atan2f ceilf cosf coshf expf fabsf floorf fmodf frexpf ldexpf logf log10f modff powf sinf sinhf sqrtf tanf tanhf acosl asinl atanl atan2l ceill cosl coshl expl fabsl floorl fmodl frexpl ldexpl logl log10l modfl powl sinl sinhl sqrtl tanl tanhl
There should probably be a note saying that these functionsare optional and, if supplied, should match the description inthe 1999 version of the C standard. In the next roundof C++ standardization they can then become mandatory.
Rationale:
The C90 standard, as amended, already permits (but does notrequire) these functions, and the C++ standard incorporates theC90 standard by reference. C99 is not an issue, because it isnever referred to by the C++ standard.
Section: 26.6.5[alg.foreach]Status:NADSubmitter: Angelika LangerOpened: 2001-01-03Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.foreach].
View all otherissues in [alg.foreach].
View all issues withNAD status.
Discussion:
The specification of the for_each algorithm does not have a"Requires" section, which means that there are norestrictions imposed on the function object whatsoever. In essence itmeans that I can provide any function object with arbitrary sideeffects and I can still expect a predictable result. In particular Ican expect that the function object is applied exactly last - firsttimes, which is promised in the "Complexity" section.
I don't see how any implementation can give such a guaranteewithout imposing requirements on the function object.
Just as an example: consider a function object that removeselements from the input sequence. In that case, what does thecomplexity guarantee (applies f exactly last - first times) mean?
One can argue that this is obviously a nonsensical application anda theoretical case, which unfortunately it isn't. I have seenprogrammers shooting themselves in the foot this way, and they did notunderstand that there are restrictions even if the description of thealgorithm does not say so.
[Lillehammer: This is more general than for_each. We don't want the function object in transform invalidiating iterators either. There should be a note somewhere in clause 17 (17, not 25) saying that user code operating on a range may not invalidate iterators unless otherwise specified. Bill will provide wording.]
[2009-07 Frankfurt]
Moved to NAD.
It was felt that the current description is adequate, and that there arelimits to what the standard can reasonably say to prohibit perverse usesof the library.
Proposed resolution:
Section: 26.7.4[alg.transform]Status:NADSubmitter: Angelika LangerOpened: 2001-01-04Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.transform].
View all issues withNAD status.
Discussion:
This issue is related to issue 242. In case that the resolutionproposed for issue 242 is accepted, we have have the followingsituation: The 4 numeric algorithms (accumulate and consorts) as wellas transform would allow a certain category of side effects. Thenumeric algorithms specify that they invoke the functor "forevery iterator i in the range [first, last) in order". transform,in contrast, would not give any guarantee regarding order ofinvocation of the functor, which means that the functor can be invokedin any arbitrary order.
Why would that be a problem? Consider an example: say thetransformator that is a simple enumerator ( or more generallyspeaking, "is order-sensitive" ). Since a standardcompliant implementation of transform is free to invoke the enumeratorin no definite order, the result could be a garbled enumeration.Strictly speaking this is not a problem, but it is certainly at oddswith the prevalent understanding of transform as an algorithms thatassigns "a new _corresponding_ value" to the outputelements.
All implementations that I know of invoke the transformator indefinite order, namely starting from first and proceeding to last -1. Unless there is an optimization conceivable that takes advantage ofthe indefinite order I would suggest to specify the order, because iteliminate the uncertainty that users would otherwise have regardingthe order of execution of their potentially order-sensitive functionobjects.
Proposed resolution:
In section 25.2.3 - Transform [lib.alg.transform] change:
-1- Effects: Assigns through every iterator i in the range [result,result + (last1 - first1)) a new correspondingvalue equal to op(*(first1 + (i - result)) or binary_op(*(first1 +(i - result), *(first2 + (i - result))).
to:
-1- Effects: Computes values by invoking the operation op or binary_op for every iterator in the range [first1, last1) in order. Assigns throughevery iterator i in the range [result, result + (last1 - first1)) a newcorrespondingvalue equal to op(*(first1 + (i - result)) or binary_op(*(first1 +(i - result), *(first2 + (i - result))).
Rationale:
For Input Iterators an order is already guaranteed, becauseonly one order is possible. If a user who passes a ForwardIterator to one of these algorithms really needs a specificorder of execution, it's possible to achieve that effect bywrapping it in an Input Iterator adaptor.
Section: 24.3.5.6[bidirectional.iterators], 24.3.5.7[random.access.iterators]Status:NAD EditorialSubmitter: John PotterOpened: 2001-01-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [bidirectional.iterators].
View all issues withNAD Editorial status.
Discussion:
In section 24.3.5.6[bidirectional.iterators],Table 75 gives the return type of*r-- as convertible toT. This isnot consistent with Table 74 which gives the return type of*r++ asT&.*r++ = t is valid while*r-- = t is invalid.
In section 24.3.5.7[random.access.iterators],Table 76 gives the return type ofa[n] as convertible toT. This isnot consistent with the semantics of*(a + n) which returnsT& byTable 74.*(a + n) = t is valid whilea[n] = t is invalid.
Discussion from the Copenhagen meeting: the first part isuncontroversial. The second part,operator[] for Random AccessIterators, requires more thought. There are reasonable arguments onboth sides. Return by value fromoperator[] enables some potentiallyuseful iterators, e.g. a random access "iota iterator" (a.k.a"counting iterator" or "int iterator"). There isn't any obvious wayto do this with return-by-reference, since the reference would be to atemporary. On the other hand,reverse_iterator takes anarbitrary Random Access Iterator as template argument, and itsoperator[] returns by reference. If we decided that the return typein Table 76 was correct, we would have to changereverse_iterator. This change would probably affect usercode.
History: the contradiction betweenreverse_iterator and theRandom Access Iterator requirements has been present from an earlystage. In both the STL proposal adopted by the committee(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), byStepanov and Lee), the Random Access Iterator requirements say thatoperator[]'s return value is "convertible toT". In N0527reverse_iterator'soperator[] returns by value, but in HPL-95-11(R.1), and in the STL implementation that HP released to the public,reverse_iterator'soperator[] returns by reference. In 1995, thestandard was amended to reflect the contents of HPL-95-11 (R.1). Theoriginal intent foroperator[] is unclear.
In the long term it may be desirable to add more fine-grained iterator requirements, so that access method and traversal strategycan be decoupled. (See "Improved Iterator Categories andRequirements", N1297 = 01-0011, by Jeremy Siek.) Any decisionsabout issue 299 should keep this possibility in mind.
Further discussion: I propose a compromise between John Potter'sresolution, which requiresT& as the return type ofa[n], and the current wording, which requires convertible toT. The compromise is to keep the convertible toTfor the return type of the expressiona[n], but to also adda[n] = t as a valid expression. This compromise "saves" thecommon case uses of random access iterators, while at the same timeallowing iterators such as counting iterator and caching fileiterators to remain random access iterators (iterators where thelifetime of the object returned byoperator*() is tied to thelifetime of the iterator).
Note that the compromise resolution necessitates a change toreverse_iterator. It would need to use a proxy to supporta[n] = t.
Note also there is one kind of mutable random access iterator thatwill no longer meet the new requirements. Currently, iterators thatreturn an r-value fromoperator[] meet the requirements for amutable random access iterator, even though the expressiona[n] =t will only modify a temporary that goes away. With this proposedresolution,a[n] = t will be required to have the sameoperational 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 arandom access iterator?Recommended solution:
In table Table 104 — Random access iterator requirements, replace
a[n]: convertible toconst T &T&ifXis mutable, otherwise convertible toconst T&
[2009-10 Santa Cruz:]
Leave Open. Alisdair to spearhead a paper on revivification.
[2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.]
Rationale:
Solved byN3066.
Proposed resolution:
In section 24.1.4 [lib.bidirectdional.iterators], change the returntype in table 75 from "convertible toT" toT&.
In section 24.1.5 [lib.random.access.iterators], change theoperational semantics fora[n] to " the r-value ofa[n] is equivalent to the r-value of*(a +n)". Add a new row in the table for the expressiona[n] = twith a return type of convertible toT and operational semantics of*(a + n) = t.
[Lillehammer: Real problem, but should be addressed as part of iterator redesign]
Rationale:
[San Francisco:]
Solved byN2758.
Section: 28.3.4.2.6[locale.codecvt.byname]Status:NADSubmitter: Gregory BumgardnerOpened: 2001-01-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt.byname].
View all issues withNAD status.
Discussion:
The effects ofcodecvt<>::do_length() are described in22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarifiedin issue75(i),codecvt<>::do_length() mustprocess the source data and update thestateT argument justas if the data had been processed bycodecvt<>::in().However, the standard does not specify howdo_length() wouldreport a translation failure, should the source sequence containuntranslatable or illegal character sequences.
The other conversion methods return an "error" result valueto indicate that an untranslatable character has been encountered, butdo_length() already has a return value (the number of sourcecharacters that have been processed by the method).
Proposed resolution:
This issue cannot be resolved without modifying the interface. An exceptioncannot be used, as there would be no way to determine how many charactershave been processed and the state object would be left in an indeterminatestate.
A source compatible solution involves adding a fifth argument to length()and do_length() that could be used to return position of the offendingcharacter sequence. This argument would have a default value that wouldallow it to be ignored:
int length(stateT& state, const externT* from, const externT* from_end, size_t max, const externT** from_next = 0); virtual int do_length(stateT& state, const externT* from, const externT* from_end, size_t max, const externT** from_next);
Then an exception could be used to report any translation errors andthe from_next argument, if used, could then be used to retrieve thelocation of the offending character sequence.
Rationale:
The standard is already clear: the return value is the number of"valid complete characters". If it encounters an invalid sequence ofexternal characters, it stops.
*a return an lvalue whena is an input iterator?Section: 24.3.4[iterator.concepts]Status:NADSubmitter: Dave AbrahamsOpened: 2001-02-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.concepts].
View all issues withNAD status.
Discussion:
We all "know" that input iterators are allowed to producevalues when dereferenced of which there is no other in-memory copy.
But: Table 72, with a careful reading, seems to imply that this can only bethe case if the value_type has no members (e.g. is a built-in type).
The problem occurs in the following entry:
a->m pre: (*a).m is well-defined Equivalent to (*a).m
*a.m can be well-defined if*a is not a referencetype, but sinceoperator->() must return a pointer fora->m to be well-formed, it needs something to return apointerto. This seems to indicate that*a must bebuffered somewhere to make a legal input iterator.
I don't think this was intentional.
Rationale:
The current standard is clear and consistent. Input iterators that return rvalues are in fact implementable. They may in some cases require extra work, but it is still possible to define an operator-> in such cases: it doesn't have to return a T*, but may return a proxy type. No change to the standard is justified.
Section: 31.7[iostream.format]Status:NADSubmitter: Martin SeborOpened: 2001-03-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iostream.format].
View all issues withNAD status.
Discussion:
The descriptions of the constructors of basic_istream<>::sentry( [istream::sentry]) and basic_ostream<>::sentry( [ostream::sentry]) do not explain what the functions do incase an exception is thrown while they execute. Some currentimplementations allow all exceptions to propagate, others catch themand set ios_base::badbit instead, still others catch some but letothers propagate.
The text also mentions that the functions may call setstate(failbit)(without actually saying on what object, but presumably the streamargument is meant). That may have been fine forbasic_istream<>::sentry prior to issue195(i), sincethe function performs an input operation which may fail. However,issue195(i) amends [istream::sentry], p2 toclarify that the function should actually call setstate(failbit |eofbit), so the sentence in p3 is redundant or even somewhatcontradictory.
The same sentence that appears in [ostream::sentry], p3doesn't seem to be very meaningful for basic_istream<>::sentrywhich performs no input. It is actually rather misleading since itwould appear to guide library implementers to callingsetstate(failbit) when os.tie()->flush(), the only called function,throws an exception (typically, it's badbit that's set in response tosuch an event).
Additional comments from Martin, who isn't comfortable with the current proposed resolution (see c++std-lib-11530)
The istream::sentry ctor says nothing about how the functiondeals with exemptions (27.6.1.1.2, p1 says that the class isresponsible for doing "exception safe"(*) prefix and suffixoperations but it doesn't explain what level of exceptionsafety the class promises to provide). The mockup exampleof a "typical implementation of the sentry ctor" given in27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't showexception handling, either. Since the ctor is not classifiedas a formatted or unformatted input function, the text in27.6.1.1, p1 through p4 does not apply. All this would seemto suggest that the sentry ctor should not catch or in anyway handle exceptions thrown from any functions it may call.Thus, the typical implementation of an istream extractor maylook something like [1].
The problem with [1] is that while it correctly sets ios::badbitif an exception is thrown from one of the functions called fromthe sentry ctor, if the sentry ctor reaches EOF while extractingwhitespace from a stream that has eofbit or failbit set inexceptions(), it will cause an ios::failure to be thrown, whichwill in turn cause the extractor to set ios::badbit.
The only straightforward way to prevent this behavior is tomove the definition of the sentry object in the extractorabove the try block (as suggested by the example in 22.2.8,p9 and also indirectly supported by 27.6.1.3, p1). See [2].But such an implementation will allow exceptions thrown fromfunctions called from the ctor to freely propagate to thecaller regardless of the setting of ios::badbit in the streamobject's exceptions().
So since neither [1] nor [2] behaves as expected, the onlypossible solution is to have the sentry ctor catch exceptionsthrown from called functions, set badbit, and propagate thoseexceptions if badbit is also set in exceptions(). (Anothersolution exists that deals with both kinds of sentries, butthe code is non-obvious and cumbersome -- see [3].)
Please note that, as the issue points out, current librariesdo not behave consistently, suggesting that implementors arenot quite clear on the exception handling in istream::sentry,despite the fact that some LWG members might feel otherwise.(As documented by the parenthetical comment here:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
Also please note that those LWG members who in Copenhagenfelt that "a sentry's constructor should not catch exceptions,because sentries should only be used within (un)formatted inputfunctions and that exception handling is the responsibility ofthose functions, not of the sentries," as noted herehttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309would in effect be either arguing for the behavior describedin [1] or for extractors implemented along the lines of [3].
The original proposed resolution (Revision 25 of the issueslist) clarifies the role of the sentry ctor WRT exceptionhandling by making it clear that extractors (both libraryor user-defined) should be implemented along the lines of[2] (as opposed to [1]) and that no exception thrown fromthe callees should propagate out of either function unlessbadbit is also set in exceptions().
[1] Extractor that catches exceptions thrown from sentry:
struct S { long i; };istream& operator>> (istream &strm, S &s){ ios::iostate err = ios::goodbit; try { const istream::sentry guard (strm, false); if (guard) { use_facet<num_get<char> >(strm.getloc ()) .get (istreambuf_iterator<char>(strm), istreambuf_iterator<char>(), strm, err, s.i); } } catch (...) { bool rethrow; try { strm.setstate (ios::badbit); rethrow = false; } catch (...) { rethrow = true; } if (rethrow) throw; } if (err) strm.setstate (err); return strm;}[2] Extractor that propagates exceptions thrown from sentry:
istream& operator>> (istream &strm, S &s){ istream::sentry guard (strm, false); if (guard) { ios::iostate err = ios::goodbit; try { use_facet<num_get<char> >(strm.getloc ()) .get (istreambuf_iterator<char>(strm), istreambuf_iterator<char>(), strm, err, s.i); } catch (...) { bool rethrow; try { strm.setstate (ios::badbit); rethrow = false; } catch (...) { rethrow = true; } if (rethrow) throw; } if (err) strm.setstate (err); } return strm;}[3] Extractor that catches exceptions thrown from sentrybut doesn't set badbit if the exception was thrown as aresult of a call to strm.clear().
istream& operator>> (istream &strm, S &s){ const ios::iostate state = strm.rdstate (); const ios::iostate except = strm.exceptions (); ios::iostate err = std::ios::goodbit; bool thrown = true; try { const istream::sentry guard (strm, false); thrown = false; if (guard) { use_facet<num_get<char> >(strm.getloc ()) .get (istreambuf_iterator<char>(strm), istreambuf_iterator<char>(), strm, err, s.i); } } catch (...) { if (thrown && state & except) throw; try { strm.setstate (ios::badbit); thrown = false; } catch (...) { thrown = true; } if (thrown) throw; } if (err) strm.setstate (err); return strm;}[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
[Pre-Portland] A relevant newsgroup post:
The current proposed resolution of issue #309 isunacceptable. I write commerical software and coding around thismakes my code ugly, non-intuitive, and requires comments referringpeople to this very issue. Following is the full explanation of myexperience.
In the course of writing software for commercial use, I constructedstd::ifstream's based on user-supplied pathnames on typical POSIXsystems.
It was expected that some files that opened successfully might not readsuccessfully -- such as a pathname which actually refered to adirectory. Intuitively, I expected the streambuffer underflow() codeto throw an exception in this situation, and recent implementations oflibstdc++'s basic_filebuf do just that (as well as many of my owncustom streambufs).
I also intuitively expected that the istream code would convert theseexceptions to the "badbit' set on the stream object, because I had notrequested exceptions. I refer to 27.6.1.1. P4.
However, this was not the case on at least two implementations -- ifthe first thing I did with an istream was call operator>>( T& ) for Tamong the basic arithmetic types and std::string. Looking further Ifound that the sentry's constructor was invoking the exception when itpre-scanned for whitespace, and the extractor function (operator>>())was not catching exceptions in this situation.
So, I was in a situation where setting 'noskipws' would change theistream's behavior even though no characters (whitespace or not) couldever be successfully read.
Also, calling .peek() on the istream before calling the extractor()changed the behavior (.peek() had the effect of setting the badbitahead of time).
I found this all to be so inconsistent and inconvenient for me and mycode design, that I filed a bugzilla entry for libstdc++. I was thentold that the bug cannot be fixed until issue #309 is resolved by thecommittee.
[2009-07 Frankfurt]
Moved to NAD.
See the rationale in the issue. Paolo, who requested that the issue bereopened, agreed with the rationale.
Proposed resolution:
Rationale:
The LWG agrees there is minor variation between implementations, but believes that it doesn't matter. This is a rarely used corner case. There is no evidence that this has any commercial importance or that it causes actual portability problems for customers trying to write code that runs on multiple implementations.
Section: 17.9.5.4[terminate]Status:NADSubmitter: Judy WardOpened: 2001-04-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [terminate].
View all issues withNAD status.
Discussion:
According to section 18.7.3.3 of the standard, std::terminate() issupposed to call the terminate_handler in effect immediately afterevaluating the throw expression.
Question: what if the terminate_handler in effect is itselfstd::terminate?
For example:
#include <exception> int main () { std::set_terminate(std::terminate); throw 5; return 0; }Is the implementation allowed to go into an infinite loop?
I think the same issue applies to std::set_unexpected.
Proposed resolution:
Rationale:
Infinite recursion is to be expected: users who set the terminatehandler toterminate are explicitly asking forterminateto call itself.
Section: 17.9.5.4[terminate]Status:NADSubmitter: Detlef VollmannOpened: 2001-04-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [terminate].
View all issues withNAD status.
Discussion:
The standard appears to contradict itself about whether the stack isunwound when the implementation calls terminate().
From 18.7.3.3p2:
Calls the terminate_handler function in effect immediately after evaluating the throw-expression (lib.terminate.handler), if called by the implementation [...]
So the stack is guaranteed not to be unwound.
But from 15.3p9:
[...]whether or not the stack is unwound before this call to terminate() is implementation-defined (except.terminate).
And 15.5.1 actually defines that in most cases the stack is unwound.
Proposed resolution:
Rationale:
There is definitely no contradiction between the core and libraryclauses; nothing in the core clauses says that stack unwinding happensafterterminate is called. 18.7.3.3p2 does not say anythingabout when terminate() is called; it merely specifies whichterminate_handler is used.
abs() overloads in different headersSection: 29.7[c.math]Status:NADSubmitter: Dave AbrahamsOpened: 2001-06-04Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
Currently the standard mandates the following overloads ofabs():
abs(long), abs(int) in <cstdlib> abs(float), abs(double), abs(long double) in <cmath> template<class T> T abs(const complex<T>&) in <complex> template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
The problem is that having only some overloads visible of a functionthat works on "implicitly inter-convertible" types is dangerous inpractice. The headers that get included at any point in a translationunit can change unpredictably during programdevelopment/maintenance. The wrong overload might be unintentionallyselected.
Currently, there is nothing that mandates the simultaneous visibilityof these overloads. Indeed, some vendors have begun fastidiouslyreducing dependencies among their (public) headers as a QOI issue: ithelps people to write portable code by refusing to compile unless allthe correct headers are #included.
The same issue may exist for other functions in the library.
Redmond: PJP reports that C99 adds two new kinds ofabs:complex,andint_max_abs.
[Bellevue:]
The situation is not sufficiently severe to warrant a change.
Rationale:
The programs that could potentially be broken by this situation are already fragile, and somewhat contrived: For example, a user-defined class that has conversion overloads both tolong and tofloat. Ifx is a value of such a class, thenabs(x) would give thelong version if the user included <cstdlib>, thefloat version if the user included <cmath>, and would be diagnosed as ambiguous at compile time if the user included both headers. The LWG couldn't find an example of a program whose meaning would be changed (as opposed to changing it from well-formed to ill-formed) simply by adding another standard header.
Since the harm seems minimal, and there don't seem to be any simple and noninvasive solutions, this is being closed as NAD. It is marked as "Future" for two reasons. First, it might be useful to define an<all> header that would include all Standard Library headers. Second, we should at least make sure that future library extensions don't make this problem worse.
Section: 28.3.4.7.5[locale.moneypunct.byname]Status:NADSubmitter: Martin SeborOpened: 2001-07-05Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
The definition of the moneypunct facet contains the typedefs char_typeand string_type. Only one of these names, string_type, is defined inthe derived facet, moneypunct_byname.
Proposed resolution:
For consistency with the numpunct facet, add a typedef forchar_type to the definition of the moneypunct_byname facet in28.3.4.7.5[locale.moneypunct.byname].
Rationale:
The absence of the typedef is irrelevant. Users can still accessthe typedef, because it is inherited from the base class.
Section: 28.3.3.1[locale]Status:NADSubmitter: Martin SeborOpened: 2001-07-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale].
View all issues withNAD status.
Discussion:
The "exposition only" value of the std::locale::none constant shown inthe definition of class locale is misleading in that it on manysystems conflicts with the value assigned to one if the LC_XXXconstants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPEon Linux and SunOS). This causes incorrect behavior when such aconstant is passed to one of the locale member functions that accept alocale::category argument and interpret it as either the C LC_XXXconstant or a bitmap of locale::category values. At least three majorimplementations adopt the suggested value without a change andconsequently suffer from this problem.
For instance, the following code will (presumably) incorrectly copy facetsbelonging to the collate category from the German locale on AIX:
std::locale l (std::locale ("C"), "de_DE", std::locale::none);Rationale:
The LWG agrees that it may be difficult to implement locale memberfunctions in such a way that they can take eithercategoryarguments or the LC_ constants defined in <cctype>. In light ofthis requirement (28.3.3.1.2.1[locale.category], paragraph 2), and in lightof the requirement in the preceding paragraph that it is possible tocombinecategory bitmask elements with bitwise operations,defining thecategory elements is delicate,particularly if an implementor is constrained to work with apreexisting C library. (Just using the existing LC_ constants wouldnot work in general.) There's no set of "exposition only" values thatcould give library implementors proper guidance in such a delicatematter. The non-normative example we're giving is no worse thanany other choice would be.
Section: 31.5.3[fpos]Status:NADSubmitter: PremAnand M. RaoOpened: 2001-08-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [fpos].
View all issues withNAD status.
Discussion:
Increment and decrement operators are missing from Table 88 -- Position type requirements in 31.5.3[fpos].
Proposed resolution:
Table 88 (section 27.4.3) -- Position type requirementsbe updated to include increment and decrement operators.
expression return type operational note++p fpos& p += O(1)p++ fpos { P tmp = p; ++p; return tmp; }--p fpos& p -= O(1)p-- fpos { P tmp = p; --p; return tmp; }Rationale:
The LWG believes this is a request for extension, not a defectreport. Additionally, nobody saw a clear need for this extension;fpos is used only in very limited ways.
Section: 31.7.5.4[istream.unformatted]Status:NADSubmitter: Howard HinnantOpened: 2001-10-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream.unformatted].
View all issues withNAD status.
Discussion:
I think we have a defect.
According to lwg issue60(i) which is now a dr, thedescription of seekg in 31.7.5.4[istream.unformatted] paragraph 38 now lookslike:
Behaves as an unformatted input function (as described in 27.6.1.3, paragraph 1), except that it does not count the number of characters extracted and does not affect the value returned by subsequent calls to gcount(). After constructing a sentry object, if fail() != true, executes rdbuf()->pubseekpos( pos).
And according to lwg issue243(i) which is also now a dr,27.6.1.3, paragraph 1 looks like:
Each unformatted input function begins execution by constructing an object of class sentry with the default argument noskipws (second) argument true. If the sentry object returns true, when converted to a value of type bool, the function endeavors to obtain the requested input. Otherwise, if the sentry constructor exits by throwing an exception or if the sentry object returns false, when converted to a value of type bool, the function returns without attempting to obtain any input. In either case the number of extracted characters is set to 0; unformatted input functions taking a character array of non-zero size as an argument shall also store a null character (using charT()) in the first location of the array. If an exception is thrown during input then ios::badbit is turned on in *this'ss error state. If (exception()&badbit)!= 0 then the exception is rethrown. It also counts the number of characters extracted. If no exception has been thrown it ends by storing the count in a member object and returning the value specified. In any event the sentry object is destroyed before leaving the unformatted input function.
And finally 27.6.1.1.2/5 says this about sentry:
If, after any preparation is completed, is.good() is true, ok_ != false otherwise, ok_ == false.
So although the seekg paragraph says that the operation proceeds if !fail(), the behavior of unformatted functions says the operation proceeds only if good(). The two statements are contradictory when only eofbit is set. I don't think the current text is clear which condition should be respected.
Further discussion from Redmond:
PJP: It doesn't seem quite right to say thatseekg is"unformatted". That makes specific claims about sentry thataren't quite appropriate for seeking, which has less fragile failuremodes than actual input. If we do really mean that it's unformattedinput, it should behave the same way as other unformatted input. Onthe other hand, "principle of least surprise" is that seeking from EOFought to be OK.
Pre-Berlin: Paolo points out several problems with the proposed resolution inReady state:
failbit when it findseofbit already set, thenyou can never seek away from the end of stream.[2009-07 Frankfurt]
Moved to NAD. Will reopen if proposed resolution is supplied.
Proposed resolution:
Change 31.7.5.4[istream.unformatted] to:
Behaves as an unformatted input function (as described in 27.6.1.3,paragraph 1), except that it does not count the number of charactersextracted, does not affect the value returned by subsequent calls togcount(), and does not examine the value returned by the sentryobject. After constructing a sentry object, if
fail() !=true, executesrdbuf()->pubseekpos(pos). Incase of success, the function calls clear().In case of failure, the function callssetstate(failbit)(which may throwios_base::failure).
[Lillehammer: Matt provided wording.]
Rationale:
In C, fseek does clear EOF. This is probably what most users would expect. We agree that having eofbit set should not deter a seek, and that a successful seek should clear eofbit. Note thatfail() is true only iffailbit orbadbit is set, so using!fail(), rather thangood(), satisfies this goal.
Section: 28.3.4.3[category.numeric]Status:NADSubmitter: Howard HinnantOpened: 2001-10-13Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
When both grouping and showbase are active and the basefield is octal, does the leading 0 participate in the grouping or not? For example, should one format as: 0,123,456 or 0123,456?
An analogy can be drawn with hexadecimal. It appears that 0x123,456 is preferred over 0x,123,456. However, this analogy is not universally accepted to apply to the octal base. The standard is not clear on how to format (or parse) in this manner.
Proposed resolution:
Insert into 28.3.4.4.1.3[facet.numpunct.virtuals] paragraph 3, just before the lastsentence:
The leading hexadecimal base specifier "0x" does not participate in grouping. The leading '0' octal base specifier may participate in grouping. It is unspecified if the leading '0' participates in formatting octal numbers. In parsing octal numbers, the implementation is encouraged to accept both the leading '0' participating in the grouping, and not participating (e.g. 0123,456 or 0,123,456).
Rationale:
The current behavior may be unspecified, but it's not clear that itmatters. This is an obscure corner case, since grouping is usuallyintended for the benefit of humans and oct/hex prefixes are usuallyintended for the benefit of machines. There is not a strong enoughconsensus in the LWG for action.
Section: 22.3[pairs]Status:DupSubmitter: Andy SawyerOpened: 2001-10-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [pairs].
View all issues withDup status.
Duplicate of:532
Discussion:
The current wording of 20.2.2 [lib.pairs] p6 precludes the use ofoperator< on any pair type which contains a pointer.
Proposed resolution:
In 22.3[pairs] paragraph 6, replace:
Returns: x.first < y.first || (!(y.first < x.first) && x.second < y.second).
With:
Returns: std::less<T1>()( x.first, y.first ) || (!std::less<T1>()( y.first, x.first) && std::less<T2>()( x.second, y.second ) )
Rationale:
This is an instance of a much more general problem. If we want operator< to translate to std::less for pairs of pointers, where do we draw the line? The same issue applies to individual pointers, smart pointer wrappers, std::vector<T*>, and so on.
Andy Koenig suggests that the real issue here is that we aren't distinguishing adequately between two different orderings, a "useful ordering" and a "canonical ordering" that's used just because we sometimes needsome ordering without caring much which ordering it is. Another example of the later is typeinfo'sbefore.
Section: 20.2.10.2[allocator.members], 16.4.4.6[allocator.requirements], 16.4.2.2[contents]Status:DupSubmitter: Nathan MyersOpened: 2001-10-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [allocator.members].
View all issues withDup status.
Duplicate of:634
Discussion:
See c++std-lib-9006 and c++std-lib-9007. This issue is takenverbatim from -9007.
The core language feature allowing definition of operator&() applied to any non-builtin type makes that operator often unsafe to use in implementing libraries, including the Standard Library. The resultis that many library facilities fail for legal user code, such asthe fragment
class A { private: A* operator&(); }; std::vector<A> aa; class B { }; B* operator&(B&) { return 0; } std::vector<B> ba;In particular, the requirements table for Allocator (Table 32) specifiesno semantics at all for member address(), and allocator<>::address is defined in terms of unadorned operator &.
Proposed resolution:
In 20.6.1.1, Change the definition of allocator<>::address from:
Returns: &x
to:
Returns: The value that the built in operator&(x) would return if not overloaded.
In 20.1.6, Table 32, add to the Notes column of the a.address(r) anda.address(s) lines, respectively:
allocator<T>::address(r) allocator<T>::address(s)
In addition, in clause 17.4.1.1, add a statement:
The Standard Library does not apply operator& to any type for which operator& may be overloaded.
Rationale:
The LWG believes both examples are ill-formed. The contained typeis required to be CopyConstructible (16.4.4.2[utility.arg.requirements]), and thatincludes the requirement that &t return the usual types andvalues. Since allocators are intended to be used in conjunction withcontainers, and since the CopyConstructible requirements appear tohave been written to deal with the concerns of this issue, the LWGfeels it is NAD unless someone can come up with a well-formed exampleexhibiting a problem.
It may well be that the CopyConstructible requirements are too restrictive and that either the container requirements or the CopyConstructive requirements should be relaxed, but that's a far larger issue. Marking this issue as "future" as a pointer to that larger issue.
Section: 22.10[function.objects]Status:NAD EditorialSubmitter: Dale RileyOpened: 2001-11-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [function.objects].
View all issues withNAD Editorial status.
Discussion:
In 22.10[function.objects] the header <functional> synopsis declaresthe unary_negate and binary_negate function objects as struct.However in [negators] the unary_negate and binary_negatefunction objects are defined as class. Given the context, they arenot "basic function objects" like negate, so this is either a typo oran editorial oversight.
[Taken from comp.std.c++]
Proposed resolution:
Change the synopsis to reflect the useage in [negators]
[Curaçao: Since the language permits "struct", the LWGviews this as NAD. They suggest, however, that the Project Editormight wish to make the change as editorial.]
Section: 28.3.4.2[category.ctype]Status:NADSubmitter: Matt AusternOpened: 2002-01-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [category.ctype].
View all issues withNAD status.
Discussion:
What should the following program print?
#include <locale> #include <iostream> class my_ctype : public std::ctype<char> { typedef std::ctype<char> base; public: my_ctype(std::size_t refs = 0) : base(my_table, false, refs) { std::copy(base::classic_table(), base::classic_table() + base::table_size, my_table); my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space); } private: mask my_table[base::table_size]; }; int main() { my_ctype ct; std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " " << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl; }The goal is to create a facet where '_' is treated as whitespace.
On gcc 3.0, this program prints "isspace: 1 isalpha: 0". OnMicrosoft C++ it prints "isspace: 1 isalpha: 1".
I believe that both implementations are legal, and the standard does notgive enough guidance for users to be able to use std::ctype'sprotected interface portably.
The above program assumes that ctype_base::mask enumerators likespace andprint are disjoint, and that the way tosay that a character is both a space and a printing character is to orthose two enumerators together. This is suggested by the "expositiononly" values in 28.3.4.2[category.ctype], but it is nowhere specified innormative text. An alternative interpretation is that the morespecific categories subsume the less specific. The above programgives the results it does on the Microsoft compiler because, on thatcompiler,print has all the bits set for each specificprinting character class.
From the point of view of std::ctype's public interface, there's noimportant difference between these two techniques. From the point ofview of the protected interface, there is. If I'm defining a facetthat inherits from std::ctype<char>, I'm the one who defines thevalue that table()['a'] returns. I need to know what combination ofmask values I should use. This isn't so very esoteric: it's exactlywhy std::ctype has a protected interface. If we care about usersbeing able to write their own ctype facets, we have to give them aportable way to do it.
Related reflector messages:lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,lib-9277, lib-9279.
Issue339(i) is related, but not identical. Theproposed resolution if issue339(i) says thatctype_base::mask must be a bitmask type. It does not say that thectype_base::mask elements are bitmask elements, so it doesn'tdirectly affect this issue.
More comments from Benjamin Kosnik, who believes that that C99 compatibility essentially requires what we'recalling option 1 below.
I think the C99 standard is clear, that isspace -> !isalpha.--------#include <locale>#include <iostream>class my_ctype : public std::ctype<char>{private: typedef std::ctype<char> base; mask my_table[base::table_size];public: my_ctype(std::size_t refs = 0) : base(my_table, false, refs) { std::copy(base::classic_table(), base::classic_table() + base::table_size, my_table); mask both = base::print | base::space; my_table[static_cast<mask>('_')] = both; }};int main(){ using namespace std; my_ctype ct; cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; // ISO C99, isalpha iff upper | lower set, and !space. // 7.5, p 193 // -> looks like g++ behavior is correct. // 356 -> bitmask elements are required for ctype_base // 339 -> bitmask type required for mask cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl;}Proposed resolution:
Informally, we have three choices:
Either of the first two options is just as good from the standpointof portability. Either one will require some implementations tochange.
Rationale:
The LWG agrees that this is a real ambiguity, and that bothinterpretations are conforming under the existing standard. However,there's no evidence that it's causing problems for real users. Userswho want to define ctype facets portably can test the ctype_base masksto see which interpretation is being used.
Section: 29.7[c.math]Status:NAD EditorialSubmitter: Ray LischnerOpened: 2002-02-26Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD Editorial status.
Discussion:
The float versions of the math functions have no meaningful value to return for a range error. The long double versions have a value they can return, but it isn't necessarily the most reasonable value.
Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long double overloaded versions of these functions, with the same semantics," referring to the math functions from the C90 standard.
The C90 standard, in section 7.5.1, paragraph 3, says that functions return "the value of the macro HUGE_VAL" when they encounter a range error. Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a positive double expression, not necessarily representable as a float."
Therefore, the float versions of the math functions have no way tosignal a range error.[Curaçao: The LWG notes that this isn'tstrictly correct, since errno is set.] The semantics require that theyreturn HUGE_VAL, but they cannot because HUGE_VAL might not berepresentable as a float.
The problem with long double functions is less severe because HUGE_VAL is representable as a long double. On the other hand, it might not be a "huge" long double value, and might fall well within the range of normal return values for a long double function. Therefore, it does not make sense for a long double function to return a double (HUGE_VAL) for a range error.
Proposed resolution:
Curaçao: C99 was faced with a similar problem, which they fixed byadding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.
C++ must also fix, but it should be done in the context of thegeneral C99 based changes to C++, not via DR. Thus the LWG in Curaçaofelt the resolution should be NAD, FUTURE, but the issue is being heldopen for one more meeting to ensure LWG members not present during thediscussion concur.
Rationale:
Will be fixed as part of more general work in the TR.
Section: 28.3.4.3.3.3[facet.num.put.virtuals]Status:NADSubmitter: Martin SeborOpened: 2002-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [facet.num.put.virtuals].
View all otherissues in [facet.num.put.virtuals].
View all issues withNAD status.
Discussion:
22.2.2.2.2, p12 specifies thatthousands_sep is to be inserted onlyfor integral types (issue 282 suggests that this should be done forall arithmetic types).
22.2.2.1.2, p12 requires that grouping be checked for all extractorsincluding that forvoid*.
I don't think that's right.void* values should not be checked forgrouping, should they? (Although if they should, thennum_put needsto write them out, otherwise their extraction will fail.)
Proposed resolution:
Change the first sentence of 22.2.2.2.2, p12 from
Digit grouping is checked. That is, the positions of discarded separators is examined for consistency with use_facet<numpunct<charT> >(loc).grouping(). If they are not consistent then ios_base::failbit is assigned to err.
to
Except for conversions to void*, digit grouping is checked...
Rationale:
This would be a change: as it stands, the standard clearly specifies that grouping applies to void*. A survey of existing practice shows that most existing implementations do that, as they should.
Section: 31[input.output]Status:NADSubmitter: Walter Brown, Marc PaternoOpened: 2002-05-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [input.output].
View all issues withNAD status.
Discussion:
The following member functions are declared const, yet return non-constpointers. We believe they are should be changed, because they allow codethat may surprise the user. See document N1360 for details andrationale.
[Santa Cruz: the real issue is that we've got const memberfunctions that return pointers to non-const, and N1360 proposesreplacing them by overloaded pairs. There isn't a consensus aboutwhether this is a real issue, since we've never said what ourconstness policy is for iostreams. N1360 relies on a distinctionbetween physical constness and logical constness; that distinction, orthose terms, does not appear in the standard.]
Proposed resolution:
In 27.4.4 and 27.4.4.2
Replace
basic_ostream<charT,traits>* tie() const;
with
basic_ostream<charT,traits>* tie(); const basic_ostream<charT,traits>* tie() const;
and replace
basic_streambuf<charT,traits>* rdbuf() const;
with
basic_streambuf<charT,traits>* rdbuf(); const basic_streambuf<charT,traits>* rdbuf() const;
In 27.5.2 and 27.5.2.3.1
Replace
char_type* eback() const;
with
char_type* eback(); const char_type* eback() const;
Replace
char_type gptr() const;
with
char_type* gptr(); const char_type* gptr() const;
Replace
char_type* egptr() const;
with
char_type* egptr(); const char_type* egptr() const;
In 27.5.2 and 27.5.2.3.2
Replace
char_type* pbase() const;
with
char_type* pbase(); const char_type* pbase() const;
Replace
char_type* pptr() const;
with
char_type* pptr(); const char_type* pptr() const;
Replace
char_type* epptr() const;
with
char_type* epptr(); const char_type* epptr() const;
In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6
Replace
basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
with
basic_stringbuf<charT,traits,Allocator>* rdbuf(); const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13
Replace
basic_filebuf<charT,traits>* rdbuf() const;
with
basic_filebuf<charT,traits>* rdbuf(); const basic_filebuf<charT,traits>* rdbuf() const;
Rationale:
The existing specification is a bit sloppy, but there's no particular reason to change this other than tidiness, and there are a number of ways in which streams might have been designed differently if we were starting today. There's no evidence that the existing constness policy is harming users. We might consider a different constness policy as part of a full stream redesign.
Section: 26.7.8[alg.remove]Status:NADSubmitter: Anthony WilliamsOpened: 2002-05-13Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.remove].
View all issues withNAD status.
Discussion:
remove_copy and remove_copy_if (26.7.8[alg.remove]) permit theirinput range to be marked with Input Iterators. However, since twooperations are required against the elements to copy (comparison andassigment), when the input range uses Input Iterators, a temporarycopy must be taken to avoid dereferencing the iterator twice. Thistherefore requires the value type of the InputIterator to beCopyConstructible. If the iterators are at least Forward Iterators,then the iterator can be dereferenced twice, or a reference to theresult maintained, so the temporary is not required.
Proposed resolution:
Add "If InputIterator does not meet the requirements of forwarditerator, then the value type of InputIterator must be copyconstructible. Otherwise copy constructible is not required." to26.7.8[alg.remove] paragraph 6.
Rationale:
The assumption is that an input iterator can't be dereferenced twice. There's no basis for that assumption in the Standard.
Section: 27.4.3.7.6[string.replace]Status:NAD EditorialSubmitter: Beman DawesOpened: 2002-06-03Last modified: 2016-11-12
Priority:Not Prioritized
View all otherissues in [string.replace].
View all issues withNAD Editorial status.
Discussion:
27.4.3.7.6[string.replace] basic_string::replace, secondsignature, given in paragraph 1, has two "Throws" paragraphs (3 and5).
In addition, the second "Throws" paragraph (5) includes specification(beginning with "Otherwise, the function replaces ...") that should bepart of the "Effects" paragraph.
Proposed resolution:
Rationale:
This is editorial. Both "throws" statements are true. The bug is just that the second one should be a sentence, part of the "Effects" clause, not a separate "Throws". The project editor has been notified.
Section: 16.4.6.14[res.on.exception.handling], 17.7.3[type.info]Status:NADSubmitter: Randy MaddoxOpened: 2002-07-22Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [res.on.exception.handling].
View all otherissues in [res.on.exception.handling].
View all issues withNAD status.
Discussion:
Paragraph 3 under clause 16.4.6.14[res.on.exception.handling], Restrictions onException Handling, states that "Any other functions defined in theC++ Standard Library that do not have an exception-specification maythrow implementation-defined exceptions unless otherwise specified."This statement is followed by a reference to footnote 178 at thebottom of that page which states, apparently in reference to the C++Standard Library, that "Library implementations are encouraged (butnot required) to report errors by throwing exceptions from (or derivedfrom) the standard exceptions."
These statements appear to be in direct contradiction to clause17.7.3[type.info], which states "The class exception defines thebase class for the types of objects thrown as exceptions by the C++Standard library components ...".
Is this inconsistent?
Proposed resolution:
Rationale:
Clause 17 is setting the overall library requirements, and it's clear and consistent. This sentence from Clause 18 is descriptive, not setting a requirement on any other class.
Section: 28.3.4.7.4.2[locale.moneypunct.members], 28.3.4.7.4.3[locale.moneypunct.virtuals]Status:NADSubmitter: Ray LischnerOpened: 2002-08-08Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
In section 28.3.4.7.4.2[locale.moneypunct.members], frac_digits() returns type"int". This implies that frac_digits() might return a negative value,but a negative value is nonsensical. It should return "unsigned".
Similarly, in section 28.3.4.7.4.3[locale.moneypunct.virtuals], do_frac_digits()should return "unsigned".
Proposed resolution:
Rationale:
Regardless of whether the return value is int or unsigned, it'salways conceivable that frac_digits might return a nonsensicalvalue. (Is 4294967295 really any better than -1?) The clients ofmoneypunct, the get and put facets, can and do perform rangechecks.
Section: 27.4.3.7.4[string.insert]Status:NADSubmitter: Ray LischnerOpened: 2002-08-16Last modified: 2016-11-12
Priority:Not Prioritized
View all otherissues in [string.insert].
View all issues withNAD status.
Discussion:
Section 27.4.3.7.4[string.insert], paragraph 4, contains the following,"Then throwslength_error ifsize() >= npos - rlen."
Related to DR 83, this sentence should probably be removed.
Proposed resolution:
Rationale:
This requirement is redundant but correct. No change isneeded.
Section: 28.3.3.1[locale]Status:DupSubmitter: Martin SeborOpened: 2002-09-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale].
View all issues withDup status.
Duplicate of:31
Discussion:
I think there is a problem with 22.1.1, p6 which says that
-6- An instance of locale is immutable; once a facet reference is obtained from it, that reference remains usable as long as the locale value itself exists.
and 22.1.1.2, p4:
const locale& operator=(const locale& other) throw(); -4- Effects: Creates a copy of other, replacing the current value.
How can a reference to a facet obtained from a locale object remainvalid after an assignment that clearly must replace all the facetsin the locale object? Imagine a program such as this
std::locale loc ("de_DE"); const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc); loc = std::locale ("en_US"); const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);Is r0 really supposed to be preserved and destroyed only when loc goesout of scope?
Proposed resolution:
[Summer '04 mid-meeting mailing: Martin and Dietmar believe this is a duplicate of issue31(i) and recommend that it be closed.]
Section: 28.3.4.2.5[locale.codecvt]Status:NADSubmitter: Martin SeborOpened: 2002-08-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt].
View all issues withNAD status.
Discussion:
It seems that the descriptions of codecvt do_in() and do_out() leavesufficient room for interpretation so that two implementations ofcodecvt may not work correctly with the same filebuf. Specifically,the following seems less than adequately specified:
Finally, the conditions described at the end of 28.3.4.2.5.3[locale.codecvt.virtuals], p4 don't seem to be possible:
"A return value of partial, if (from_next == from_end), indicates that either the destination sequence has not absorbed all the available destination elements, or that additional source elements are needed before another destination element can be produced."
If the value is partial, it's not clear to me that (from_next==from_end) could ever hold if there isn't enough roomin the destination buffer. In order for (from_next==from_end) tohold, all characters in that range must have been successfullyconverted (according to 28.3.4.2.5.3[locale.codecvt.virtuals], p2) and since there are nofurther source characters to convert, no more room in thedestination buffer can be needed.
It's also not clear to me that (from_next==from_end) could everhold if additional source elements are needed to produce anotherdestination character (not element as incorrectly stated in thetext). partial is returned if "not all source characters havebeen converted" according to Table 53, which also implies that(from_next==from) does NOT hold.
Could it be that the intended qualifying condition was actually(from_next != from_end), i.e., that the sentence was supposedto read
"A return value of partial, if (from_next != from_end),..."
which would make perfect sense, since, as far as I understand it,partial can only occur if (from_next != from_end)?
[Lillehammer: Defer for the moment, but this really needs to be fixed. Right now, the description of codecvt is too vague for it to be a useful contract between providers and clients of codecvt facets. (Note that both vendors and users can be both providers and clients of codecvt facets.) The major philosophical issue is whether the standard should only describe mappings that take a single wide character to multiple narrow characters (and vice versa), or whether it should describe fully general N-to-M conversions. When the original standard was written only the former was contemplated, but today, in light of the popularity of utf8 and utf16, that doesn't seem sufficient for C++0x. Bill supports general N-to-M conversions; we need to make sure Martin and Howard agree.]
[2009-07 Frankfurt]
codecvt is meant to be a 1-to-N to N-to-1 conversion. It does not workwell for N-to-M conversions. wbuffer_convert now exists, and handlesN-to-M cases. Also, there is a new specialization of codecvt thatpermits UTF-16 <-> UTF-8 conversions.
NAD without prejudice. Will reopen if proposed resolution is supplied.
Proposed resolution:
Section: 16[library]Status:NADSubmitter: Matt AusternOpened: 2002-10-23Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Many function templates have parameters that are passed by value;a typical example isfind_if'spred parameter in26.6.6[alg.find]. Are the corresponding template parameters(Predicate in this case) implicitly required to beCopyConstructible, or does that need to be spelled out explicitly?
This isn't quite as silly a question as it might seem to be at firstsight. If you callfind_if in such a way that templateargument deduction applies, then of course you'll get call by valueand you need to provide a copy constructor. If you explicitly providethe template arguments, however, you can force call by reference bywriting something likefind_if<my_iterator,my_predicate&>. The question is whether implementationare required to accept this, or whether this is ill-formed becausemy_predicate& is not CopyConstructible.
The scope of this problem, if it is a problem, is unknown. Functionobject arguments to generic algorithms in clauses 26[algorithms]and 29[numerics] are obvious examples. A review of the wholelibrary is necessary.
[This is really two issues. First, predicates are typically passed byvalue but we don't say they must be Copy Constructible. They shouldbe. Second: is specialization allowed to transform value argumentsinto references? References aren't copy constructible, so this shouldnot be allowed.]
[2007-01-12, Howard: First, despite the note above, referencesarecopy constructible. They just aren't assignable. Second, this is veryclosely related to92(i) and should be consistent with that.That issue already says that implementations are allowed to copyfunction objects. If one passes in a reference, it is copyable, butsusceptible to slicing if one passes in a reference to a base. Third,with rvalue reference in the language one only needs to satisfyMoveConstructible to pass an rvalue "by value". Though the functionmight still copy the function object internally (requiringCopyConstructible). Finally (and fwiw), if we wanted to, it is easy tocode all of the std::algorithms such that they do not copy functionobjects internally. One merely passes them by reference internally ifdesired (this has been fully implemented and shipped for several years). If this were mandated, it would reverse92(i), allowingfunction objects to reliably maintain state. E.g. the example in92(i) would reliably remove only the third element.]
Proposed resolution:
Recommend NAD.
Rationale:
Generic algorithms will be marked with concepts and these will imply a requirementof MoveConstructible (not CopyConstructible). The signature of the function willthen precisely describe and enforce the precise requirements.
complex as a key in associative containersSection: 29.4[complex.numbers]Status:NADSubmitter: Gabriel Dos ReisOpened: 2002-11-08Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [complex.numbers].
View all issues withNAD status.
Discussion:
Practice withstd::complex<> and the associative containersoccasionally reveals artificial and distracting issues with constructsresembling:std::set<std::complex<double> > s;
The main reason for the above to fail is the absence of an appropriatedefinition forstd::less<std::complex<T> >. That in turn comes fromthe definition of the primary templatestd::less<> in terms ofoperator<.
The usual argument goes as follows: Since there is no ordering overthe complex field compatible with field operations it makes littlesense to define a functionoperator< operating on the datatypestd::complex<T>. That is fine. However, that reasoning does not carryover tostd::less<T> which is used, among other things, by associativecontainers as an ordering useful to meet complexity requirements.
[Pre Bellevue: Reopened at the request of Alisdair.]
[Bellevue:]
This is a request for a design change, and not a defect in the standard.It is in scope to consider, but the group feels that it is not a changethat we need to do. Is there a total ordering for floating point values,including NaN? There is not a clear enough solution or big enoughproblem for us to solve. Solving this problem would require solving theproblem for floating point, which is equally unclear. The LWG noted thatusers who want to put objects into an associative container for which
operator<isn't defined can simply provide their own comparison function object. NAD
Proposed resolution:
Informally: Add a specialization ofstd::less forstd::complex.
Rationale:
Discussed in Santa Cruz. An overwhelming majority of the LWGbelieves this should not be treated a DR: it's a request for a designchange, not a defect in the existing standard. Most people (10-3)believed that we probably don't want this change, period: as withissue348(i), it's hard to know where to draw the line.The LWG noted that users who want to put objects into an associativecontainer for whichoperator< isn't defined can simplyprovide their own comparison function object.
Section: 16.4.4.2[utility.arg.requirements]Status:NAD EditorialSubmitter: Doug GregorOpened: 2002-10-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility.arg.requirements].
View all issues withNAD Editorial status.
Discussion:
The CopyConstructible requirements in Table 30 state that for anobject t of type T (where T is CopyConstructible), the expression &treturns the address of t (with type T*). This requirement is overlystrict, in that it disallows types that overload operator& to notreturn a value of type T*. This occurs, for instance, in theBoost.Lambda library, whereoperator& is overloaded for a Boost.Lambda function object to returnanother function object.
Example:
std::vector<int> u, v; int x; // ... std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
_1 * x returns an unnamed function object with operator& overloaded tonot return T* , therefore rendering the std::transform call ill-formed.However, most standard library implementations will compile this codeproperly, and the viability of such binder libraries is severely hinderedby the unnecessary restriction in the CopyConstructible requirements.
For reference, the address of an object can be retrieved without usingthe address-of operator with the following function template:
template <typename T> T* addressof(T& v) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); }Note: this relates directly to library issue350(i), whichwill need to be reexamined if the CopyConstructible requirementschange.
Proposed resolution:
Remove the last two rows of Table 30, eliminating the requirementsthat &t and &u return the address of t and u, respectively.
Rationale:
This was a deliberate design decision. Perhaps it should be reconsidered for C++0x.
Section: 24.3.5.3[input.iterators]Status:NADSubmitter: Corwin JoyOpened: 2002-12-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [input.iterators].
View all otherissues in [input.iterators].
View all issues withNAD status.
Discussion:
In section 24.3.5.3[input.iterators] table 72 -'Input Iterator Requirements' we have as a postcondition of *a:"If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
In section [istreambuf.iterator::equal] it states that"istreambuf_iterator::equal returns true if and only if both iteratorsare at end-of-stream, or neither is at end-of-stream,regardless ofwhat streambuf object they use." (My emphasis).
The defect is that either 'equivalent' needs to be more preciselydefined or the conditions for equality in [istreambuf.iterator::equal]are incorrect. (Or both).
Consider the following example:
#include <iostream> #include <fstream> #include <iterator> using namespace std; int main() { ifstream file1("file1.txt"), file2("file2.txt"); istreambuf_iterator<char> f1(file1), f2(file2); cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl; cout << "f1 = " << *f1 << endl; cout << "f2 = " << *f2 << endl; return 0; }Now assuming that neither f1 or f2 are at the end-of-stream thenf1 == f2 by [istreambuf.iterator::equal].
However, it is unlikely that *f1 will give the same value as *f2 exceptby accident.
So what does *f1 'equivalent' to *f2 mean? I think the standard shouldbe clearer on this point, or at least be explicit that this does notmean that *f1 and *f2 are required to have the same value in the caseof input iterators.
Proposed resolution:
Rationale:
The two iterators aer not in the domain of ==
Section: 28.3.4.2.5.3[locale.codecvt.virtuals]Status:NAD EditorialSubmitter: Alberto BarbatiOpened: 2002-12-24Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [locale.codecvt.virtuals].
View all otherissues in [locale.codecvt.virtuals].
View all issues withNAD Editorial status.
Discussion:
this DR follows the discussion on the previous thread "codecvt::do_innot consuming external characters". It's just a clarification issueand not a request for a change.
Can do_in()/do_out() produce output characters without consuming input characters as a result of operation on state?
Proposed resolution:
Add a note at the end of 28.3.4.2.5.3[locale.codecvt.virtuals], paragraph 3:
[Note: As a result of operations on state, it can return ok or partial and set from_next == from and to_next != to. --end note]
Rationale:
The submitter believes that standard already provides an affirmativeanswer to the question. However, the current wording has induced a fewlibrary implementors to make the incorrect assumption thatdo_in()/do_out() always consume at least one internal character whenthey succeed.
The submitter also believes that the proposed resolution is not inconflict with the related issue 76. Moreover, by explicitly allowingoperations on state to produce characters, a codecvt implementationmay effectively implement N-to-M translations without violating the"one character at a time" principle described in such issue. On a sidenote, the footnote in the proposed resolution of issue 76 thatinformally rules out N-to-M translations for basic_filebuf should beremoved if this issue is accepted as valid.
[Kona (2007): The proposed resolution is to add a note. Since this isnon-normative, the issue is editorial, but we believe that the note iscorrect. Proposed Disposition: NAD, Editorial]
Section: 31.7.6.3.1[ostream.formatted.reqmts]Status:NADSubmitter: Martin SeborOpened: 2002-12-27Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
There is a contradiction in Formatted output about what bit issupposed to be set if the formatting fails. On sentence says it'sbadbit and another that it's failbit.
27.6.2.5.1, p1 says in the Common Requirements on Formatted outputfunctions:
... If the generation fails, then the formatted output function does setstate(ios::failbit), which might throw an exception.
27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
... The formatting conversion occurs as if it performed the following code fragment:
bool failed = use_facet<num_put<charT,ostreambuf_iterator<charT,traits> > > (getloc()).put(*this, *this, fill(), val). failed(); ... If failed is true then does setstate(badbit) ...
The original intent of the text, according to Jerry Schwarz (seec++std-lib-10500), is captured in the following paragraph:
In general "badbit" should mean that the stream is unusable becauseof some underlying failure, such as disk full or socket closure;"failbit" should mean that the requested formatting wasn't possiblebecause of some inconsistency such as negative widths. So typicallyif you clear badbit and try to output something else you'll failagain, but if you clear failbit and try to output something elseyou'll succeed.
In the case of the arithmetic inserters, since num_put cannotreport failure by any means other than exceptions (in responseto which the stream must set badbit, which prevents the kind ofrecoverable error reporting mentioned above), the only otherdetectable failure is if the iterator returned from num_putreturns true from failed().
Since that can only happen (at least with the required iostreamspecializations) under such conditions as the underlying failurereferred to above (e.g., disk full), setting badbit would seemto be the appropriate response (indeed, it is required in27.6.2.5.2, p1). It follows that failbit can never be directlyset by the arithmetic (it can only be set by the sentry objectunder some unspecified conditions).
The situation is different for other formatted output functionswhich can fail as a result of the streambuf functions failing(they may do so by means other than exceptions), and which arethen required to set failbit.
The contradiction, then, is that ostream::operator<<(int) willset badbit if the disk is full, while operator<<(ostream&,char) will set failbit under the same conditions. To make the behaviorconsistent, the Common requirements sections for the Formatted outputfunctions should be changed as proposed below.
[Kona: There's agreement that this is a real issue. What we decided at Kona: 1. An error from the buffer (which can be detected either directly from streambuf's member functions or by examining a streambuf_iterator) should always result in badbit getting set. 2. There should never be a circumstance where failbit gets set. That represents a formatting error, and there are no circumstances under which the output facets are specified as signaling a formatting error. (Even more so for string output that for numeric because there's nothing to format.) If we ever decide to make it possible for formatting errors to exist then the facets can signal the error directly, and that should go in clause 22, not clause 27. 3. The phrase "if generation fails" is unclear and should be eliminated. It's not clear whether it's intended to mean a buffer error (e.g. a full disk), a formatting error, or something else. Most people thought it was supposed to refer to buffer errors; if so, we should say so. Martin will provide wording.]
[2009-07 Frankfurt]
NAD. This issue is already fixed.
Proposed resolution:
Rationale:
ostream::sentry dtor throws exceptionsSection: 31.7.6.2.4[ostream.sentry]Status:NAD EditorialSubmitter: Martin SeborOpened: 2003-01-05Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [ostream.sentry].
View all issues withNAD Editorial 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() canthrow an exception.
[The contradiction is real. Clause 17 says destructors may neverthrow exceptions, and clause 27 specifies a destructor that doesthrow. In principle we might change either one. We're leaningtoward changing clause 17: putting in an "unless otherwise specified"clause, and then putting in a footnote saying the sentry destructoris the only one that can throw. PJP suggests specifying thatsentry::~sentry() should internally catch any exceptions it might cause.]
[See418(i) and622(i) 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 of835(i) is written to match the outcomeof this issue.
[2009 Santa Cruz:]
[2010-03-06 Martin updates wording.]
[2010 Pittsburgh:]
Moved to NAD Editorial.
Rationale:
Proposed resolution:
Add after [ostream::sentry] p17:
~sentry();-17- If
(os.flags() & ios_base::unitbuf)istrue, callsos.flush().Throws: Nothing.
Section: 31.7.6.2.4[ostream.sentry]Status:NADSubmitter: Martin SeborOpened: 2003-01-05Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [ostream.sentry].
View all issues withNAD status.
Discussion:
While reviewing unformatted input member functions of istreamfor their behavior when they encounter end-of-file during inputI found that the requirements vary, sometimes unexpectedly, andin more than one case even contradict established practice (GNUlibstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
The following unformatted input member functions set eofbit if theyencounter an end-of-file (this is the expected behavior, and alsothe behavior of all major implementations):
basic_istream<charT, traits>& get (char_type*, streamsize, char_type);
Also sets failbit if it fails to extract any characters.
basic_istream<charT, traits>& get (char_type*, streamsize);
Also sets failbit if it fails to extract any characters.
basic_istream<charT, traits>& getline (char_type*, streamsize, char_type);
Also sets failbit if it fails to extract any characters.
basic_istream<charT, traits>& getline (char_type*, streamsize);
Also sets failbit if it fails to extract any characters.
basic_istream<charT, traits>& ignore (int, int_type);
basic_istream<charT, traits>& read (char_type*, streamsize);
Also sets failbit if it encounters end-of-file.
streamsize readsome (char_type*, streamsize);
The following unformated input member functions set failbit butnot eofbit if they encounter an end-of-file (I find this oddsince the functions make it impossible to distinguish a generalfailure from a failure due to end-of-file; the requirement isalso in conflict with all major implementation which set botheofbit and failbit):
int_type get();
basic_istream<charT, traits>& get (char_type&);
These functions only set failbit of they extract no characters,otherwise they don't set any bits, even on failure (I find thisinconsistency quite unexpected; the requirement is also inconflict with all major implementations which set eofbitwhenever they encounter end-of-file):
basic_istream<charT, traits>& get (basic_streambuf<charT, traits>&, char_type);
basic_istream<charT, traits>& get (basic_streambuf<charT, traits>&);
This function sets no bits (all implementations except forSTLport and Classic Iostreams set eofbit when they encounterend-of-file):
int_type peek ();
Informally, what we want is a global statement of intent saying that eofbit gets set if we trip across EOF, and then we can take away the specific wording for individual functions. A full review is necessary. The wording currently in the standard is a mishmash, and changing it on an individual basis wouldn't make things better. Dietmar will do this work.
[2009-07 Frankfurt]
Moved to NAD. See 31.7.5.2[istream] p3.
Proposed resolution:
Section: 31.7.5.4[istream.unformatted]Status:NADSubmitter: Martin SeborOpened: 2003-01-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream.unformatted].
View all issues withNAD status.
Discussion:
The Effects clauses for the two functions below violate thegeneral requirements on unformatted input functions outlinedin 27.6.1.3: they do not begin by constructing a sentry object.Instead, they begin by calling widen ('\n'), which may throwan exception. The exception is then allowed to propagate fromthe unformatted input function irrespective of the setting ofexceptions().
Note that in light of 27.6.1.1, p3 and p4, the fact that thefunctions allow exceptions thrown from widen() to propagatemay not strictly speaking be a defect (but the fact that thefunctions do not start by constructing a sentry object stillis). However, since an exception thrown from ctype<charT>::widen() during any other input operation (say, from withina call to num_get<charT>::get()) will be caught and causebadbit to be set, these two functions should not be treateddifferently for the sake of consistency.
Proposed resolution:
Rationale:
Not a defect. The standard is consistent, and the behavior requiredby the standard is unambiguous. Yes, it's theoretically possible forwiden to throw. (Not that this will happen for the default ctypefacet or for most real-world replacement ctype facets.) Users whodefine ctype facets that can throw, and who care about this behavior,can use alternative signatures that don't call widen.
vector<reverse_iterator<char*> > forbidden?Section: 24.3[iterator.requirements]Status:NAD EditorialSubmitter: Nathan MyersOpened: 2003-06-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.requirements].
View all issues withNAD Editorial 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.
24.3.4[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 areverse_iterator<> in the defaultconstructor. As a result, code like
std::vector<std::reverse_iterator<char*> > v(7); v.reserve(1000);
invokes undefined behavior, because it must default-initialize thevector 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 asiterators. However, this is not clear in the text, others have come to the opposite conclusion.
One question is whether the standard iterator adaptors have definedcopy semantics. Another is whether they have defined destructorsemantics: is
{ std::vector<std::reverse_iterator<char*> > v(7); }undefined too?
Note this is not a question of whether algorithms are allowed torely on copy semantics for arbitrary iterators, just whether thetypes 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., thereverse_iterator<T> constructor is actually required to executeT(), and so copying is defined if the result ofT() is copyable.
Issue235(i), which definesreverse_iterator's defaultconstructor 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 whenT ischar*, where the first leaves the memberuninitialized, 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 tosatisfy DR235(i), at least for non-class Iterator argumenttypes.
But that only takes care ofreverse_iterator, and doesn't establisha policy for all iterators. (The reverse iterator adapter was justan 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, becausevector<> will destroy those singulariterator 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, itshould allow copying of that subset of singular iterator values thatare default-initialized, and it should explicitly allow destroying anyiterator 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, defaultconstruction may be a special case. Issue: is it really defaultconstruction we want to talk about, or is it something like valueinitialization? We need to check with core to see whether defaultconstructed pointers are required to be copyable; if not, it would bewrong to impose so strict a requirement for iterators.]
[2009-05-10 Alisdair provided wording.]
The comments regarding destroying singular iterators have already beenresolved. That just leaves copying (with moving implied).
[2009-07 Frankfurt]
This is related to LWG1012(i).
Note that there is a bug in the proposed resolution to LWG1012(i). Thechange 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 LWG1012(i) (now corrected) issufficient to solve the problem for reverse_iterator. However, Alisdairpointed out that LWG1012(i) does not solve the general problem for authorsof iterator adaptors.
There are some problems with the proposed resolution. The phrase "safelycopyable" is not a term of art. Also, it mentions aDefaultConstructible? 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 upon724(i)]
[2009-10-14 Daniel adds:]
There is a clear dependency on1213(i), 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 makethis have "value semantics" and otherwise behave like a valid iterator.
[2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.]
Rationale:
Solved byN3066.
Proposed resolution:
Add a new paragrpah to Iterator concepts 24.3[iterator.requirements] after para 5 (the one describingsingular iterators)
Just as a regular pointer to an array guarantees that there is a pointervalue pointing past the last element of the array, so for any iteratortype there is an iterator value that points past the last element of acorresponding container. These values are calledpast-the-end values.Values of an iterator
ifor which the expression*iis defined are calleddereferenceable. The library never assumes that past-the-end values aredereferenceable. Iterators can also have singular values that are notassociated with any container. [Example: After the declaration of anuninitialized pointerx(as withint* x;),xmust always be assumed tohave a singular value of a pointer. —end example] Results of mostexpressions are undefined for singular values; the only exceptions aredestroying an iterator that holds a singular value and the assignment ofa non-singular value to an iterator that holds a singular value. In thiscase 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
DefaultConstructiblerequirements ([defaultconstructible]) shall not introduce undefined behaviourwhen usedas thesource of a copy or move operation, even if it wouldotherwise be singular. [Note: This guarantee is not offered fordefault-initialization (9.5[dcl.init]), although the distinction onlymatters for types with trivial default constructors such as pointers. —end note]
ctype::do_widen() return on failureSection: 28.3.4.2.2.3[locale.ctype.virtuals]Status:NADSubmitter: Martin SeborOpened: 2003-09-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.ctype.virtuals].
View all issues withNAD status.
Discussion:
The Effects and Returns clauses of thedo_widen() member function ofthectype facet fail to specify the behavior of the function on failure.That the function may not be able to simply cast the narrow characterargument to the type of the result since doing so may yield the wrong valuefor somewchar_t encodings. Popular implementations ofctype<wchar_t> thatusembtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will failwhen the argument's MSB is set. There is no way for the the rest of localeand iostream to reliably detect this failure.
[Kona: This is a real problem. Widening can fail. It's unclear what the solution should be. ReturningWEOF works for thewchar_t specialization, but not in general. One option might be to add a default, likenarrow. But that's an incompatible change. Usingtraits::eof might seem like a good idea, but facets don't have access to traits (a recurring problem). We could havewiden throw an exception, but that's a scary option; existing library components aren't written with the assumption thatwiden can throw.]
[2009-07 Frankfurt]
NAD. The behavior is specified for all of the facets that animplementation is required to provide, for the basic character set.
Proposed resolution:
Section: 31.5.2.2.6[ios.init]Status:NADSubmitter: Martin SeborOpened: 2003-09-18Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [ios.init].
View all issues withNAD status.
Discussion:
The dtor of theios_base::Init object is supposed to callflush() on the6 standard iostream objectscout,cerr,clog,wcout,wcerr, andwclog.This call may cause an exception to be thrown.
17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
The question is: What should this dtor do if one or more of these callstoflush() ends up throwing an exception? This can happen quite easilyif one of the facets installed in the locale imbued in the iostreamobject throws.
[Kona: We probably can't do much better than what we've got, so the LWG is leaning toward NAD. At the point where the standard stream objects are being cleaned up, the usual error reporting mechanism are all unavailable. And exception fromflush at this point will definitely cause problems. A quality implementation might reasonably swallow the exception, or callabort, or do something even more drastic.]
[See397(i) and622(i) for related issues.]
[2009-07 Frankfurt]
Moved to NAD, no consensus for change.
Proposed resolution:
basic_streambuf copy-constructible?Section: 31.6.3.2[streambuf.cons]Status:NADSubmitter: Martin SeborOpened: 2003-09-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [streambuf.cons].
View all issues withNAD status.
Discussion:
The reflector thread starting with c++std-lib-11346 notes that the classtemplatebasic_streambuf, along withbasic_stringbuf andbasic_filebuf,is copy-constructible but that the semantics of the copy constructorsare not defined anywhere. Further, different implementations behavedifferently in this respect: some prevent copy construction of objectsof these types by declaring their copy ctors and assignment operatorsprivate, others exhibit undefined behavior, while others still givethese operations well-defined semantics.
Note that this problem doesn't seem to be isolated to just the threetypes mentioned above. A number of other types in the library sectionof the standard provide a compiler-generated copy ctor and assignmentoperator yet fail to specify their semantics. It's believed that theonly types for which this is actually a problem (i.e. types where thecompiler-generated default may be inappropriate and may not have beenintended) are locale facets. See issue439(i).
[2009-07 Frankfurt]
NAD. Option B is already in the Working Draft.
Proposed resolution:
27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
basic_streambuf(const basic_streambuf& sb);basic_streambuf& operator=(const basic_streambuf& sb);
Insert after 27.5.2.1, paragraph 2:
basic_streambuf(const basic_streambuf& sb);Constructs a copy of
sb.Postcondtions:
eback() == sb.eback() gptr() == sb.gptr() egptr() == sb.egptr() pbase() == sb.pbase() pptr() == sb.pptr() epptr() == sb.epptr() getloc() == sb.getloc()basic_streambuf& operator=(const basic_streambuf& sb);Assigns the data members of
sbto this.Postcondtions:
eback() == sb.eback() gptr() == sb.gptr() egptr() == sb.egptr() pbase() == sb.pbase() pptr() == sb.pptr() epptr() == sb.epptr() getloc() == sb.getloc()Returns: *this.
27.7.1 [lib.stringbuf]:
Option A:
Insert into the
basic_stringbufsynopsis in the private section:basic_stringbuf(const basic_stringbuf&); // not definedbasic_stringbuf& operator=(const basic_stringbuf&); // not defined
Option B:
Insert into the
basic_stringbufsynopsis in the public section:basic_stringbuf(const basic_stringbuf& sb);basic_stringbuf& operator=(const basic_stringbuf& sb);27.7.1.1, insert after paragraph 4:
basic_stringbuf(const basic_stringbuf& sb);Constructs an independent copy of
sbas if withsb.str(), and with the openmode thatsbwas constructed with.Postcondtions:
str() == sb.str() gptr() - eback() == sb.gptr() - sb.eback() egptr() - eback() == sb.egptr() - sb.eback() pptr() - pbase() == sb.pptr() - sb.pbase() getloc() == sb.getloc()Note: The only requirement on
epptr()is that it point beyond the initialized range if an output sequence exists. There is no requirement thatepptr() - pbase() == sb.epptr() - sb.pbase().basic_stringbuf& operator=(const basic_stringbuf& sb);After assignment the
basic_stringbufhas the same state as if it were initially copy constructed fromsb, except that thebasic_stringbufis allowed to retain any excess capacity it might have, which may in turn effect the value ofepptr().
27.8.1.1 [lib.filebuf]
Insert at the bottom of thebasic_filebuf synopsis:
private: basic_filebuf(const basic_filebuf&); // not defined basic_filebuf& operator=(const basic_filebuf&); // not defined
[Kona: this is an issue forbasic_streambuf itself and for its derived classes. We are leaning toward allowingbasic_streambuf to be copyable, and specifying its precise semantics. (Probably the obvious: copying the buffer pointers.) We are less sure whether thestreambuf derived classes should be copyable. Howard will write up a proposal.]
[Sydney: Dietmar presented a new argument againstbasic_streambuf being copyable: it can lead to an encapsulation violation.filebuf inherits fromstreambuf. Now suppose you inherit amy_hijacking_buf fromstreambuf. You can copy thestreambuf portion of afilebuf to amy_hijacking_buf, giving you access to the pointers into thefilebuf's internal buffer. Perhaps not a very strong argument, but it was strong enough to make people nervous. There was weak preference for havingstreambuf not be copyable. There was weak preference for havingstringbuf not be copyable even ifstreambuf is. Move this issue to open for now.]
[2007-01-12, Howard:Rvalue Reference Recommendations for Chapter 27recommends protected copy constructor and assignment forbasic_streambuf with the same semanticsas would be generated by the compiler. These members aid in derived classes implementing move semantics.A protected copy constructor and copy assignment operator do not expose encapsulation more so than it istoday as each data member of abasic_streambuf is already both readable and writable by derivedclasses via various get/set protected member functions (eback(),setp(), etc.). Rathera protected copy constructor and copy assignment operator simply make the job of derived classes implementingmove semantics less tedious and error prone.]
Rationale:
27.5.2 [lib.streambuf]: The proposedbasic_streambuf copy constructorand assignment operator are the same as currently implied by the lackof declarations: public and simply copies the data members. Thisresolution is not a change but a clarification of the currentstandard.
27.7.1 [lib.stringbuf]: There are two reasonable options: A) Makebasic_stringbuf not copyable. This is likely the status-quo ofcurrent implementations. B) Reasonable copy semantics ofbasic_stringbuf can be defined and implemented. A copyablebasic_streambuf is arguably more useful than a non-copyable one. Thisshould be considered as new functionality and not the fixing of adefect. If option B is chosen, ramifications from issue 432 are takeninto account.
27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics forbasic_filebuf.
Section: 16.3.2.2[structure.summary]Status:NAD EditorialSubmitter: Martin SeborOpened: 2003-09-18Last modified: 2016-11-12
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
The text in 17.3.1.1, p1 says:
"Paragraphs labelled "Note(s):" or "Example(s):" are informative, otherparagraphs are normative."
The library section makes heavy use of paragraphs labeled "Notes(s),"some of which are clearly intended to be normative (see list 1), whilesome others are not (see list 2). There are also those where the intentis not so clear (see list 3).
List 1 -- Examples of (presumably) normative Notes:
20.2.10.2[allocator.members], p3,
20.2.10.2[allocator.members], p10,
27.4.3.3[string.cons], p11,
28.3.3.1.3[locale.cons], p11,
23.3.5.4[deque.modifiers], p2,
26.8.9[alg.min.max], p3,
29.4.6[complex.ops], p15,
31.6.3.5.3[streambuf.virt.get], p7.
List 2 -- Examples of (presumably) informative Notes:
17.6.3.4[new.delete.placement], p3,
27.4.3.7.6[string.replace], p14,
28.3.4.2.5.3[locale.codecvt.virtuals], p3,
26.6.5[alg.foreach], p4,
29.4.5[complex.member.ops], p1,
31.5.2.6[ios.base.storage], p6.
List 3 -- Examples of Notes that are not clearly either normativeor informative:
28.3.3.1.3[locale.cons], p8,
28.3.3.1.6[locale.statics], p6,
31.6.3.5.5[streambuf.virt.put], p4.
None of these lists is meant to be exhaustive.
[Definitely a real problem. The big problem is there's material that doesn't quite fit any of the named paragraph categories (e.g.Effects). Either we need a new kind of named paragraph, or we need to put more material in unnamed paragraphs jsut after the signature. We need to talk to the Project Editor about how to do this.]
[Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Petewill handle editorially.]
[post San Francisco: Howard: reopened, needs attention.]
[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004.Recommend NAD.]
[Batavia: We feel that the references in List 2 above should be changed fromRemarkstoNotes. We also feel that those items in List 3 need to be double checked forthe same change. Alan and Pete to review.]
[Batavia (2009-05):]
A spot-check of List 2 suggests the issue is still relevant,and a review of List 3 still seems called-for.
Move to NAD Editorial.
Proposed resolution:
Section: 31.5.4.4[iostate.flags]Status:DupSubmitter: Martin SeborOpened: 2003-09-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iostate.flags].
View all issues withDup status.
Duplicate of:412
Discussion:
The Effects clause in 27.4.4.3, p5 describing the effects of a call tothe ios_base member function clear(iostate state) says that the functiononly throws if the respective bits are already set prior to the functioncall. That's obviously not the intent. If it was, a call to clear(badbit)on an object for which (rdstate() == goodbit && exceptions() == badbit)holds would not result in an exception being thrown.
Proposed resolution:
The text ought to be changed from
"If (rdstate() & exceptions()) == 0, returns. ..."
to
"If (state & exceptions()) == 0, returns. ..."
Rationale:
Section: 99 [unexpected]Status:NADSubmitter: Vyatcheslav SysoltsevOpened: 2003-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Clause [except.unexpected] paragraph 1 says that "void unexpected();is called (18.7.2) immediately after completing the stack unwindingfor the former function", but 18.7.2.4 (Effects) says that "voidunexpected(); . . . Calls the unexpected_handler function in effectimmediately after evaluating the throwexpression (18.7.2.2),". Isn'there a contradiction: 15.5.2 requires stack have been unwound when invoid unexpected() and therefore in unexpected_handler but 18.7.2.4claims that unexpected_handler is called "in effect immediately" afterevaluation of throw expression is finished, so there is no space leftfor stack to be unwound therefore? I think the phrase "in effectimmediately" should be removed from the standard because it bringsambiguity in understanding.
Proposed resolution:
Rationale:
There is no contradiction. The phrase "in effect immediately" is just to clarify which handler is to be called.
Section: 31.7.6.3.2[ostream.inserters.arithmetic]Status:NADSubmitter: Ivan GodardOpened: 2003-10-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ostream.inserters.arithmetic].
View all issues withNAD status.
Discussion:
Given:
void f(int) {}void(*g)(int) = f;cout << g;(with the expected #include and usings), the value printed is a rathersurprising "true". Rather useless too.
The standard defines:
ostream& operator<<(ostream&, void*);
which picks up all data pointers and prints their hex value, but doesnot pick up function pointers because there is no default conversionfrom function pointer to void*. Absent that, we fall back to legacyconversions from C and the function pointer is converted to bool.
There should be an analogous inserter that prints the address of a function pointer.
Proposed resolution:
Rationale:
This is indeed a wart, but there is no good way to solve it. C doesn't provide a portable way of outputting the address of a function point either.
Section: 28.3.4[locale.categories]Status:NADSubmitter: Matt AusternOpened: 2003-11-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.categories].
View all issues withNAD status.
Discussion:
The following facets classes have no copy constructors described in the standard, which, according to the standard, means that they are supposed to use the compiler-generated defaults. Default copy behavior is probably inappropriate. We should either make these classes uncopyable or else specify exactly what their constructors do.
ctype_base ctype ctype_byname ctype<char> ctype_byname<char> codecvt_base codecvt codecvt_byname num_get num_put numpunct numpunct_byname collate collate_byname time_base time_get time_get_byname time_put time_put_byname money_get money_put money_base moneypunct moneypunct_byname messages_base messages messages_byname
Proposed resolution:
Rationale:
The copy constructor in the base class is private.
Section: 29.4.8[complex.transcendentals]Status:NADSubmitter: Matt AusternOpened: 2003-11-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [complex.transcendentals].
View all issues withNAD status.
Discussion:
Operations likepow andexp oncomplex<T> are typically implemented in terms ofoperations likesin andcos onT. Should implementations write this asstd::sin, or as plainunqualifiedsin?
The issue, of course, is whether we want to useargument-dependent lookup in the case whereT is auser-defined type. This is similar to the issue of valarraytranscendentals, as discussed in issue226(i).
This issue differs from valarray transcendentals in two importantways. First, "the effect of instantiating the templatecomplex for types other than float, double or long double isunspecified." (29.4.2[complex.syn]) Second, the standard does notdictate implementation, so there is no guarantee that a particularreal math function is used in the implementation of a particularcomplex function.
Proposed resolution:
Rationale:
If you instantiate std::complex for user-defined types, all betsare off.
Section: 24.3[iterator.requirements], 23.2[container.requirements]Status:NAD EditorialSubmitter: Andy KoenigOpened: 2003-12-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.requirements].
View all issues withNAD Editorial status.
Discussion:
What requirements does the standard place on equality comparisons betweeniterators that refer to elements of different containers. For example, ifv1 andv2 are empty vectors, isv1.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 fromdifferent 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 inclause 24. Intuitively we might want to say that equality is definedonly if one iterator is reachable from another, but figuring out howto say it in any sensible way is a bit tricky: reachability is definedin terms of equality, so we can't also define equality in terms ofreachability.]
[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.
[2010 Pittsburgh: Moved to NAD Editorial. Rationale added below.]
Rationale:
Solved byN3066.
Proposed resolution:
Insert a new paragraph between 24.3[iterator.requirements]/7+8:
[..] The result of the application of functions in the library to invalidranges is undefined.
The result of directly or indirectly evaluating any comparison functionor the binary - operator with two iterator values as arguments thatwere obtainedfrom two different ranges
r1andr2(including their past-the-end values) whichare not subranges of one common range is undefined, unless explicitlydescribed otherwise.
Section: 28.3.3.1.2.1[locale.category]Status:DupSubmitter: Pete BeckerOpened: 2003-12-26Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.category].
View all issues withDup status.
Duplicate of:327
Discussion:
22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
time_get<char,InputIterator> time_get_byname<char,InputIterator> time_get<wchar_t,OutputIterator> time_get_byname<wchar_t,OutputIterator>
The second argument to the last two should be InputIterator, notOutputIterator.
Proposed resolution:
Change the second template argument to InputIterator.
Rationale:
Section: 23.4.6[set]Status:DupSubmitter: Bill PlaugerOpened: 2004-01-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [set].
View all issues withDup status.
Duplicate of:214
Discussion:
map/multimap have:
iterator find(const key_type& x) const; const_iterator find(const key_type& x) const;
which is consistent with the table of associative container requirements.But set/multiset have:
iterator find(const key_type&) const;
set/multiset should look like map/multimap, and honor the requirementstable, in this regard.
Proposed resolution:
Rationale:
Section: 23.2.7[associative.reqmts], 23.4[associative]Status:DupSubmitter: Bill PlaugerOpened: 2004-01-30Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withDup status.
Duplicate of:130
Discussion:
map/multimap/set/multiset have:
void erase(iterator); void erase(iterator, iterator);
But there's no good reason why these can't return an iterator, as forvector/deque/list:
iterator erase(iterator); iterator erase(iterator, iterator);
Proposed resolution:
Informally: The table of associative container requirements, and therelevant template classes, should return an iterator designating thefirst element beyond the erased subrange.
Rationale:
Section: 28.3.3.1.4[locale.members]Status:NADSubmitter: Bill PlaugerOpened: 2004-01-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.members].
View all issues withNAD status.
Discussion:
template<class Facet> locale::combine(const locale&) const;
is obliged to create a locale that has no name. This is overspecificationand overkill. The resulting locale should follow the usual rules -- ithas a name if the locale argument has a name and Facet is one of thestandard facets.
[ Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, c++std-lib-13443): agreed that it's overkill to say that the locale is obligated to be nameless. However, we also can't require it to have a name. At the moment, locale names are based on categories and not on individual facets. If a locale contains two different facets of different names from the same category, then this would not fit into existing naming schemes. We need to give implementations more freedom. Bill will provide wording.]
Rationale:
After further discussion the LWG decided to close this as NAD. The fundamental problem is that names right now are per-category, not per-facet. Thecombine member function works at the wrong level of granularity.
basic_filebuf::open should acceptwchar_t namesSection: 31.10.3.4[filebuf.members]Status:NADSubmitter: Bill PlaugerOpened: 2004-01-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [filebuf.members].
View all issues withNAD status.
Duplicate of:105
Discussion:
basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
should be supplemented with the overload:
basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
Depending on the operating system, one of these forms is fundamental andthe other requires an implementation-defined mapping to determine theactual filename.
[Sydney: Yes, we want to allowwchar_t filenames. Bill will provide wording.]
[In Toronto we noted that this is issue 5 fromN1569.]
How does this interact with the newly-defined character types, and howdo we avoid interface explosion consideringstd::string overloads thatwere added? Propose another solution that is different than thesuggestion proposed by PJP.
Suggestion is to make a member template function forbasic_string (forchar,wchar_t,u16char,u32char instantiations), and then just keep aconst char* member.
Goal is to do implicit conversion between character string literals toappropriatebasic_string type. Not quite sure if this is possible.
Implementors are free to add specific overloads for non-char charactertypes.
[Martin adds pre-Sophia Antipolis:]
Please seeissue 454: problems and solutions.
[Sophia Antipolis:]
Beman is concerned that making these changes to
basic_filebufis notusefully changed unlessfstreamis also changed; this also only handleswchar_tand not other character types.The TR2 filesystem library is a more complete solution, but is not available soon.
[Martin adds: please referenceN2683 forproblems and solutions.]
Proposed resolution:
Change from:
basic_filebuf<charT,traits>* open( const char* s, ios_base::openmode mode );Effects: If is_open() != false, returns a null pointer.Otherwise, initializes the filebuf as required. It thenopens a file, if possible, whose name is the NTBS s ("as if"by calling std::fopen(s,modstr)).
to:
basic_filebuf<charT,traits>* open( const char* s, ios_base::openmode mode );basic_filebuf<charT,traits>* open( const wchar_t* ws, ios_base::openmode mode );Effects: If
is_open() != false, returns a null pointer.Otherwise, initializes thefilebufas required. It thenopens a file, if possible, whose name is the NTBSs("as if"by callingstd::fopen(s,modstr)).For the second signature, the NTBSsis determined from theWCBSwsin an implementation-defined manner.(NOTE: For a system that "naturally" represents a filenameas a WCBS, the NTBS s in the first signature may insteadbe mapped to a WCBS; if so, it follows the same mappingrules as the first argument to open.)
Rationale:
Slightly controversial, but by a 7-1 straw poll the LWG agreed to movethis to Ready. The controversy was because the mapping between widenames and files in a filesystem is implementation defined. Thecounterargument, which most but not all LWG members accepted, is thatthe mapping between narrow files names and files is alsoimplemenation defined.
[Lillehammer: Moved back to "open" status, at Beman's urging.(1) Why just basic_filebuf, instead of also basic_fstream (andpossibly other things too). (2) Why not also constructors that takestd::basic_string? (3) We might want to wait until we see Beman'sfilesystem library; we might decide that it obviates this.]
[post Bellevue:]
Move again to Ready.
There is a timing issue here. Since the filesystem library will not bein C++0x, this should be brought forward. This solution would remainvalid in the context of the proposed filesystem.
This issue has been kicking around for a while, and the wchar_t additionalone would help many users. Thus, we suggest putting this on thereflector list with an invitation for someone to produce proposedwording that covers basic_fstream. In the meantime, we suggest that theproposed wording be adopted as-is.
If more of the Lillehammer questions come back, they should beintroduced as separate issues.
[San Francisco:]
Some existing implementations provide overload already. Expectedfilesystem "path" object overloads neatly, without surprises; implyingNAD.
operator-Section: 24.3.5.7[random.access.iterators]Status:NADSubmitter: Daniel FreyOpened: 2004-02-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [random.access.iterators].
View all issues withNAD status.
Discussion:
In 24.1.5 [lib.random.access.iterators], table 76 the operationalsemantics for the expression "r -= n" are defined as "return r += -n".This means, that the expression-n must be valid, which is not the casefor unsigned types.
[Sydney: Possibly not a real problem, since difference type is requiredto be a signed integer type. However, the wording in the standard maybe less clear than we would like.]
[Post Summit Alisdair adds:]
This issue refers to a requirements table we have removed.
The issue might now relate to 24.3.5.7[random.access.iterators] p5.However, the rationale in the issue already recognises that the
difference_typemust be signed, so this really looks NAD.
[Batavia (2009-05):]
We agree with Alisdair's observations.
Move to NAD.
[2009-07 Frankfurt:]
Need to look at again without concepts.
There was a question about this phrase in the discussion: "theexpression
-nmust be valid, which is not the case for unsigned types."Ifnis an object of the iteratordifference_type(egptrdiff_t), then it is never unsigned.
[2009-10 Santa Cruz:]
The group reviewed the wording in the draft and agreed that
nis ofdifference type, the difference type is signed, and the current wordingis correct. Moved to NAD.
Proposed resolution:
To remove this limitation, I suggest to change theoperational semantics for this column to:
{ Distance m = n; if (m >= 0) while (m--) --r; else while (m++) ++r; return r; }Section: 28.3.4.3.2.3[facet.num.get.virtuals]Status:NADSubmitter: Martin SeborOpened: 2004-03-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [facet.num.get.virtuals].
View all otherissues in [facet.num.get.virtuals].
View all issues withNAD status.
Discussion:
When parsing strings of wide-character digits, the standard requires the library to widen narrow-character "atoms" and compare the widened atoms against the characters that are being parsed. Simply narrowing the wide characters would be far simpler, and probably more efficient. The two choices are equivalent except in convoluted test cases, and many implementations already ignore the standard and use narrow instead of widen.
First, I disagree that using narrow() instead of widen() wouldnecessarily have unfortunate performance implications. A possibleimplementation of narrow() that allows num_get to be implementedin a much simpler and arguably comparably efficient way as callingwiden() allows, i.e. without making a virtual call to do_narrow everytime, is as follows:
inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const { const unsigned wi = unsigned (wc); if (wi > UCHAR_MAX) return typeid (*this) == typeid (ctype<wchar_t>) ? dflt : do_narrow (wc, dflt); if (narrow_ [wi] < 0) { const char nc = do_narrow (wc, dflt); if (nc == dflt) return dflt; narrow_ [wi] = nc; } return char (narrow_ [wi]); }Second, I don't think the change proposed in the issue (i.e., to usenarrow() instead of widen() during Stage 2) would be at alldrastic. Existing implementations with the exception of libstdc++currently already use narrow() so the impact of the change on programswould presumably be isolated to just a single implementation. Further,since narrow() is not required to translate alternate wide digitrepresentations such as those mentioned in issue303(i) totheir narrow equivalents (i.e., the portable source characters '0'through '9'), the change does not necessarily imply that thesealternate digits would be treated as ordinary digits and accepted aspart of numbers during parsing. In fact, the requirement in 28.3.4.2.2.3[locale.ctype.virtuals], p13 forbids narrow() to translate an alternatedigit character, wc, to an ordinary digit in the basic sourcecharacter set unless the expression(ctype<charT>::is(ctype_base::digit, wc) == true) holds. This inturn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and5.2.1, respectively) for charT of either char or wchar_t.
[Sydney: To a large extent this is a nonproblem. As long asyou're only trafficking in char and wchar_t we're only dealing with astable character set, so you don't really need either 'widen' or'narrow': can just use literals. Finally, it's not even clear whetherwiden-vs-narrow is the right question; arguably we should be usingcodecvt instead.]
[2009-07 Frankfurt]
NAD. The standard is clear enough as written.
Proposed resolution:
Change stage 2 so that implementations are permitted to use eithertechnique to perform the comparison:
Section: 6.10.3.4[basic.start.term], 17.2.2[cstdlib.syn]Status:NADSubmitter: Bill PlaugerOpened: 2004-03-23Last modified: 2023-02-07
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
3.6.3 Termination spells out in detail the interleaving of staticdestructor calls and calls to functions registered with atexit. Tomatch this behavior requires intimate cooperation between the codethat calls destructors and the exit/atexit machinery. The formeris tied tightly to the compiler; the latter is a primitive mechanisminherited from C that traditionally has nothing to do with staticconstruction and destruction. The benefits of intermixing destructorcalls with atexit handler calls is questionable at best, andverydifficult to get right, particularly when mixing third-party C++libraries with different third-party C++ compilers and C librariessupplied by still other parties.
I believe the right thing to do is defer all static destructionuntil after all atexit handlers are called. This is a change inbehavior, but one that is likely visible only to perverse testsuites. At the very least, we shouldpermit deferred destructioneven if we don't require it.
[If this is to be changed, it should probably be changed by CWG. At this point, however, the LWG is leaning toward NAD. Implementing what the standard says is hard work, but it's not impossible and most vendors went through that pain years ago. Changing this behavior would be a user-visible change, and would break at least one real application.]
[Batavia: Send to core with our recommendation that we should permit deferreddestruction but not require it.]
[Howard: The course of action recommended in Batavia would undo LWGissue3(i) and break current code implementing the "phoenixsingleton". Search the net for "phoenix singleton atexit" to get a feelfor the size of the adverse impact this change would have. Below issample code which implements the phoenix singleton and would break ifatexit is changed in this way:]
#include <cstdlib>#include <iostream>#include <type_traits>#include <new>class A{ bool alive_; A(const A&); A& operator=(const A&);public: A() : alive_(true) {std::cout << "A()\n";} ~A() {alive_ = false; std::cout << "~A()\n";} void use() { if (alive_) std::cout << "A is alive\n"; else std::cout << "A is dead\n"; }};void deallocate_resource();// This is the phoenix singleton patternA& get_resource(bool create = true){ static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf; static A* a; if (create) { if (a != (A*)&buf) { a = ::new (&buf) A; std::atexit(deallocate_resource); } } else { a->~A(); a = (A*)&buf + 1; } return *a;}void deallocate_resource(){ get_resource(false);}void use_A(const char* message){ A& a = get_resource(); std::cout << "Using A " << message << "\n"; a.use();}struct B{ ~B() {use_A("from ~B()");}};B b;int main(){ use_A("from main()");}The correct output is:
A()Using A from main()A is alive~A()A()Using A from ~B()A is alive~A()
[Bellevue: Confirmed no interaction withquick_exit.Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.Bill agrees issue is no longer serious, and accepts NAD.]
Proposed resolution:
auto_ptr usability issuesSection: 99 [auto.ptr]Status:NADSubmitter: Rani SharoniOpened: 2003-12-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [auto.ptr].
View all issues withNAD status.
Discussion:
TC1 CWG DR #84 effectively made thetemplate<class Y> operator auto_ptr<Y>()member ofauto_ptr (20.4.5.3/4) obsolete.
The sole purpose of this obsolete conversion member is to enable copyinitialization base from r-value derived (or any convertible types likecv-types) case:
#include <memory>using std::auto_ptr;struct B {};struct D : B {};auto_ptr<D> source();int sink(auto_ptr<B>);int x1 = sink( source() ); // #1 EDG - no suitable copy constructorThe excellent analysis of conversion operations that was given in the finalauto_ptr proposal(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)explicitly specifies this case analysis (case 4). DR #84 makes the analysiswrong and actually comes to forbid the loophole that was exploited by theauto_ptr designers.
I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) thatever allowed this case. This is probably because it requires 3 user definedconversions and in fact current compilers conform to DR #84.
I was surprised to discover that the obsolete conversion member actually hasnegative impact of the copy initialization base from l-value derivedcase:
auto_ptr<D> dp;int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
I'm sure that the original intention was allowing this initialization usingthetemplate<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) butsince in this copy initialization it's merely user defined conversion (UDC)and the obsolete conversion member is UDC with the same rank (for the earlyoverloading stage) there is an ambiguity between them.
Removing the obsolete member will have impact on code that explicitlyinvokes it:
int y = sink(source().operator auto_ptr<B>());
IMHO no one ever wrote such awkward code and the reasonable workaround for#1 is:
int y = sink( auto_ptr<B>(source()) );
I was even more surprised to find out that after removing the obsoleteconversion member the initialization was still ill-formed:int x3 = sink(dp); // #3 EDG - no suitable copy constructor
This copy initialization semantically requires copy constructor which meansthat both template conversion constructor and theauto_ptr_ref conversionmember (20.4.5.3/3) are required which is what was explicitly forbidden inDR #84. This is a bit amusing case in which removing ambiguity results withno candidates.
I also found exception safety issue withauto_ptr related toauto_ptr_ref:
int f(auto_ptr<B>, std::string);auto_ptr<B> source2();// string constructor throws while auto_ptr_ref// "holds" the pointerint x4 = f(source2(), "xyz"); // #4
The theoretic execution sequence that will cause a leak:
According to 20.4.5.3/3 and 20.4.5/2 theauto_ptr_ref conversion memberreturnsauto_ptr_ref<Y> that holds*this and this is another defect sincethe type of*this isauto_ptr<X> whereX might be different fromY. Several library vendors (e.g. SGI) implementauto_ptr_ref<Y> withY* as member whichis much more reasonable. Other vendor implementedauto_ptr_ref asdefectively required and it results with awkward and catastrophic code:int oops = sink(auto_ptr<B>(source())); // warning recursive on all control paths
Dave Abrahams noticed that there is no specification saying thatauto_ptr_ref copy constructor can't throw.
My proposal comes to solve all the above issues and significantly simplifyauto_ptr implementation. One of the fundamental requirements fromauto_ptr is that it can be constructed in an intuitive manner (i.e. like ordinary pointers) but with strict ownership semantics which yield that sourceauto_ptr in initialization must be non-const. My idea is to add additionalconstructor template with sole propose to generate ill-formed, diagnosticrequired, instance for const auto_ptr arguments during instantiation ofdeclaration. This special constructor will not be instantiated for othertypes which is achievable using 14.8.2/2 (SFINAE). Having this constructorin hand makes the constructortemplate<class Y> auto_ptr(auto_ptr<Y> const&)legitimate since the actual argument can't be const yet non const r-valueare acceptable.
This implementation technique makes the "private auxiliary class"auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,GCC and VC) consume the new implementation as expected and allow allintuitive initialization and assignment cases while rejecting illegal casesthat involve constauto_ptr arguments.
The proposed auto_ptr interface:
namespace std { template<class X> class auto_ptr { public: typedef X element_type; // 20.4.5.1 construct/copy/destroy: explicit auto_ptr(X* p=0) throw(); auto_ptr(auto_ptr&) throw(); template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); auto_ptr& operator=(auto_ptr&) throw(); template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); ~auto_ptr() throw(); // 20.4.5.2 members: X& operator*() const throw(); X* operator->() const throw(); X* get() const throw(); X* release() throw(); void reset(X* p=0) throw(); private: template<class U> auto_ptr(U& rhs, typenameunspecified_error_on_const_auto_ptr<U>::type = 0); };}One compliant technique to implement theunspecified_error_on_const_auto_ptrhelper class is using additional privateauto_ptr member class template likethe following:
template<typename T> struct unspecified_error_on_const_auto_ptr;template<typename T>struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };There are other techniques to implement this helper class that might workbetter for different compliers (i.e. better diagnostics) and therefore Isuggest defining its semantic behavior without mandating any specificimplementation. IMO, and I didn't found any compiler that thinks otherwise,14.7.1/5 doesn't theoretically defeat the suggested technique but I suggestverifying this with core language experts.
Further changes in standard text:
Remove section 20.4.5.3
Change 20.4.5/2 to read something like:Initializingauto_ptr<X> fromconst auto_ptr<Y> will result with unspecifiedill-formed declaration that will require unspecified diagnostic.
Change 20.4.5.1/4,5,6 to read:
template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
4Requires:Y* can be implicitly converted toX*.
5Effects: Callsconst_cast<auto_ptr<Y>&>(a).release().
6Postconditions:*this holds the pointer returned froma.release().
Change 20.4.5.1/10
template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
10Requires:Y* can be implicitly converted toX*. The expressiondeleteget() is well formed.
LWG TC DR #127 is obsolete.
Notice that the copy constructor and copy assignment operator should remainas before and accept non-const auto_ptr& since they have effect on the formof the implicitly declared copy constructor and copy assignment operator ofclass that contains auto_ptr as member per 12.8/5,10:
struct X { // implicit X(X&) // implicit X& operator=(X&) auto_ptr<D> aptr_;};In most cases this indicates about sloppy programming but preserves thecurrentauto_ptr behavior.
Dave Abrahams encouraged me to suggest fallback implementation in case thatmy suggestion that involves removing ofauto_ptr_ref will not be accepted.In this case removing the obsolete conversion member toauto_ptr<Y> and20.4.5.3/4,5 is still required in order to eliminate ambiguity in legalcases. The two constructors that I suggested will co exist with the currentmembers but will makeauto_ptr_ref obsolete in initialization contexts.auto_ptr_ref will be effective in assignment contexts as suggested in DR#127 and I can't see any serious exception safety issues in those cases(although it's possible to synthesize such).auto_ptr_ref<X> semantics willhave to be revised to say that it strictly holds pointer of typeX and notreference to anauto_ptr for the favor of cases in whichauto_ptr_ref<Y> isconstructed fromauto_ptr<X> in whichX is different fromY (i.e. assignment from r-value derived to base).
[Redmond: punt for the moment. We haven't decided yet whether we want to fix auto_ptr for C++-0x, or remove it and replace it with move_ptr and unique_ptr.]
[Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use casesand people know how to deal with it. Going forwardunique_ptr is the recommendedtool.]
[2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.]
[2009-07 Frankfurt]
This is a complicated issue, so we agreed to defer discussion untillater in the week so that interested parties can read up on it.
[2009-10-04 Daniel adds:]
I suggest to close this issue as NAD. The reasons are two-fold: First, thesuggested proposed resolution uses no longer appropriate language meansto solve this issue, which has the effect that the recommended resolution isanother - but better - form of hack. Second, either following the suggestedresolution or the now more natural alternative via the added member set
template<class Y> auto_ptr(auto_ptr<Y>&&) throw();template<class Y> auto_ptr& operator=(auto_ptr<Y>&&) throw();would still have a non-zero probability to break user-code that activelyreferences
auto_ptr_ref. This risk seems to indicate that adecision which would not touch the current spec ofauto_ptratall (but deprecating it) and instead recommending to useunique_ptrfor new code instead might have the bestcost-benefit ratio. IMO the current solution of1100(i) canbe considered as an active user-support for this transition.
[2009-10 Santa Cruz:]
Mark as NAD. Alisdair will open a new issue (1247(i)) withproposed wording to handle
auto_ptr_ref.
Proposed resolution:
Change the synopsis in 99 [auto.ptr]:
namespace std {template <class Y> struct auto_ptr_ref {};// exposition onlytemplate <class T> struct constant_object;// exposition onlytemplate <class T>struct cannot_transfer_ownership_from: constant_object<T> {}; template <class X> class auto_ptr { public: typedef X element_type; // D.9.1.1 construct/copy/destroy: explicit auto_ptr(X* p =0) throw(); auto_ptr(auto_ptr&) throw(); template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); auto_ptr& operator=(auto_ptr&) throw(); template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw();auto_ptr& operator=(auto_ptr_ref<X> r) throw(); ~auto_ptr() throw(); // D.9.1.2 members: X& operator*() const throw(); X* operator->() const throw(); X* get() const throw(); X* release() throw(); void reset(X* p =0) throw();// D.9.1.3 conversions:auto_ptr(auto_ptr_ref<X>) throw();template<class Y> operator auto_ptr_ref<Y>() throw();template<class Y> operator auto_ptr<Y>() throw();// exposition onlytemplate<class U>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0); }; template <> class auto_ptr<void> { public: typedef void element_type; }; }Remove 99 [auto.ptr.conv].
Change 99 [auto.ptr], p3:
The
auto_ptrprovides a semantics of strict ownership. Anauto_ptrowns the object it holds a pointer to. Copying anauto_ptrcopies the pointer and transfers ownership to thedestination. If more than oneauto_ptrowns the same object atthe same time the behavior of the program is undefined.Templatesconstant_objectandcannot_transfer_ownership_from,and the final constructor ofauto_ptrare for exposition only.For any typesXandY, initializingauto_ptr<X>fromconst auto_ptr<Y>isill-formed, diagnostic required. [Note: The uses ofauto_ptrinclude providing temporary exception-safety fordynamically allocated memory, passing ownership of dynamically allocatedmemory to a function, and returning dynamically allocated memory from afunction.auto_ptrdoes not meet theCopyConstructibleandAssignablerequirements for Standard Library containerelements and thus instantiating a Standard Library container with anauto_ptrresults in undefined behavior.-- end note]
Change [auto.ptr.cons], p5:
template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();Requires:
Y*can be implicitly converted toX*.Effects: Calls
const_cast<auto_ptr<Y>&>(a).release().Postconditions:
*thisholds the pointer returned froma.release().
Change [auto.ptr.cons], p10:
template<class Y> auto_ptr& operator=(auto_ptr<Y>&a) throw();Requires:
Y*can be implicitly converted toX*.The expressiondelete get()is well formed.Effects: Calls
reset(a.release()).Returns:
*this.
basic_string ctor should prevent null pointer errorSection: 27.4.3.2[string.require]Status:NADSubmitter: Daniel FreyOpened: 2004-06-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.require].
View all issues withNAD status.
Discussion:
Today, my colleagues and me wasted a lot of time. After some time, Ifound the problem. It could be reduced to the following short example:
#include <string> int main() { std::string( 0 ); }The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 andComeau online) compile the above without errors or warnings! Theprograms (at least for the GCC) resulted in a SEGV.
I know that the standard explicitly states that the ctor of stringrequires achar* which is not zero. STLs could easily detect the abovecase with a private ctor forbasic_string which takes a single 'int'argument. This would catch the above code at compile time and would notambiguate any other legal ctors.
[Redmond: No great enthusiasm for doing this. If we do, however, we want to do it for all places that takecharT* pointers, not just the single-argument constructor. The other question is whether we want to catch this at compile time (in which case we catch the error of a literal 0, but not an expression whose value is a null pointer), at run time, or both. Recommend NAD. Relegate this functionality to debugging implementations.]
[Post Summit: Alisdair requests this be re-opened as several new language facilities aredesigned to solve exactly this kind of problem.]
[Batavia (2009-05):]
We are unable to achieve consensus on an approach to a resolution.There is some sentiment for treating this as a QOI matter.It is also possiblethat when
stringis brought into the concepts world,this issue might be addressed in that context.
[2009-07 Frankfurt]
We considered three options:
- The proposed resolution.
- NAD
- Interpret a null pointer as the empty string.
The consensus was NAD.
Proposed resolution:
Add to the synopsis in 27.4.3[basic.string]
basic_string( nullptr_t ) = delete;
Section: 23[containers]Status:NADSubmitter: Martin SeborOpened: 2004-06-28Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [containers].
View all otherissues in [containers].
View all issues withNAD status.
Discussion:
The standard doesn't prohibit the destructors (or any other specialfunctions) of containers' elements invoked from a member functionof the container from "recursively" calling the same (or any other)member function on the same container object, potentially while thecontainer is in an intermediate state, or even changing the stateof the container object while it is being modified. This may resultin some surprising (i.e., undefined) behavior.
Read email thread starting with c++std-lib-13637 for more.
Proposed resolution:
Add to Container Requirements the following new paragraph:
Unless otherwise specified, the behavior of a program that invokes a container member function f from a member function g of the container's value_type on a container object c that called g from its mutating member function h, is undefined. I.e., if v is an element of c, directly or indirectly calling c.h() from v.g() called from c.f(), is undefined.
[Redmond: This is a real issue, but it's probably a clause 17 issue, not clause 23. We get the same issue, for example, if we try to destroy a stream from one of the stream's callback functions.]
Rationale:
Recommend NAD. We agree this is an issue, but not a defect.We believe that there is no wording we can put in the standardthat will cover all cases without introducing unfortunatecorner cases.
Section: 26.8.4.4[equal.range]Status:DupSubmitter: Prateek R KarandikarOpened: 2004-06-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [equal.range].
View all issues withDup status.
Duplicate of:270
Discussion:
There is no "Returns:" clause for std::equal_range, which returns non-void.
Proposed resolution:
Rationale:
Section: 24.3.5.5[forward.iterators]Status:NADSubmitter: Dave AbrahamsOpened: 2004-07-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [forward.iterators].
View all issues withNAD status.
Discussion:
24.1/3 says:
Forward iterators satisfy all the requirements of the input and output iterators and can be used whenever either kind is specified
The problem is that satisfying the requirements of output iteratormeans that you can always assign *something* into the result ofdereferencing it. That makes almost all non-mutable forwarditerators non-conforming. I think we need to sever the refinementrelationship between forward iterator and output iterator.
Related issue:200(i). But this is not a dup.
Proposed resolution:
Rationale:
Yes, 24.1/3 does say that. But it's introductory material. Theprecise specification is in 24.1.3, and the requrements table there isright. We don't need to fine-tune introductory wording. (Especiallysince this wording is likely to be changed as part of the iteratoroverhaul.)
Section: 24.3.5.5[forward.iterators]Status:DupSubmitter: Dave AbrahamsOpened: 2004-07-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [forward.iterators].
View all issues withDup status.
Duplicate of:478
Discussion:
The Forward Iterator requirements table contains the following:
expression return type operational precondition semantics ========== ================== =========== ========================== a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. otherwise const U& r->m U& (*r).m pre: (*r).m is well-defined.
The first line is exactly right. The second line is wrong. Basicallyit implies that the const-ness of the iterator affects the const-nessof referenced members. But Paragraph 11 of [lib.iterator.requirements] says:
In the following sections, a and b denote values of type const X, n denotes a value of the difference type Distance, u, tmp, and m denote identifiers, r denotes a value of X&, t denotes a value of value type T, o denotes a value of some type that is writable to the output iterator.
AFAICT if we need the second line at all, it should read the sameas the first line.
Proposed resolution:
Rationale:
The LWG agrees that this is a real problem. Marked as a DUP because the LWG chose to adopt the solution proposed in478(i).
Section: 23.2[container.requirements]Status:DupSubmitter: Herb SutterOpened: 2004-08-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withDup status.
Duplicate of:580
Discussion:
Nothing in the standard appears to make this program ill-formed:
struct C { void* operator new( size_t s ) { return ::operator new( s ); } // NOTE: this hides in-place and nothrow new }; int main() { vector<C> v; v.push_back( C() ); }Is that intentional? We should clarify whether or not we intended to require containers to support types that define their own special versions ofoperator new.
[Lillehammer: A container will definitely never use this overriddenoperator new, but whether it will fail to compile is unclear from thestandard. Are containers supposed to use qualified or unqualifiedplacement new? 20.4.1.1 is somewhat relevant, but the standarddoesn't make it completely clear whether containers have to useAllocator::construct(). If containers don't use it, the details of howcontainers use placement new are unspecified. That is the real bug,but it needs to be fixed as part of the allocator overhaul. Weaksupport that the eventual solution should make this code well formed.]
Proposed resolution:
Section: 99 [depr.base]Status:NADSubmitter: Joe GottmanOpened: 2004-08-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [depr.base].
View all issues withNAD status.
Discussion:
The classes std::unary_function and std::binary_function are bothdesigned to be inherited from but contain no virtual functions. Thismakes it too easy for a novice programmer to write code likebinary_function<int, int, int> *p = new plus<int>; delete p;
There are two common ways to prevent this source of undefinedbehavior: give the base class a public virtual destructor, or give ita protected nonvirtual destructor. Since unary_function andbinary_function have no other virtual functions, (note in particularthe absence of an operator()() ), it would cost too much to give thempublic virtual destructors. Therefore, they should be given protectednonvirtual destructors.
Proposed resolution:
Change Paragraph 20.3.1 of the Standard from
template <class Arg, class Result> struct unary_function { typedef Arg argument_type; typedef Result result_type; }; template <class Arg1, class Arg2, class Result> struct binary_function { typedef Arg1 first_argument_type; typedef Arg2 second_argument_type; typedef Result result_type; };to
template <class Arg, class Result> struct unary_function { typedef Arg argument_type; typedef Result result_type; protected: ~unary_function() {} }; template <class Arg1, class Arg2, class Result> struct binary_function { typedef Arg1 first_argument_type; typedef Arg2 second_argument_type; typedef Result result_type; protected: ~binary_function() {} };Rationale:
The LWG doesn't believe the existing definition causes anybody any concrete harm.
Section: 26.7.9[alg.unique]Status:NADSubmitter: Andrew KoenigOpened: 2004-08-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.unique].
View all issues withNAD status.
Discussion:
The standard says that unique(first, last) "eliminates all but thefirst element from every consecutive group of equal elements" in[first, last) and returns "the end of the resulting range". So apostcondition is that [first, result) is the same as the old [first,last) except that duplicates have been eliminated.
What postconditions are there on the range [result, last)? One might argue that the standard says nothing about those values, so they can be anything. One might also argue that the standard doesn't permit those values to be changed, so they must not be. Should the standard say something explicit one way or the other?
Proposed resolution:
Rationale:
We don't want to make many guarantees about what's in [result,end). Maybe we aren't being quite explicit enough about not beingexplicit, but it's hard to think that's a major problem.
Section: 26.6[alg.nonmodifying], 26.7[alg.modifying.operations]Status:DupSubmitter: Peter DimovOpened: 2004-09-20Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withDup status.
Duplicate of:283
Discussion:
c++std-lib-14262
[lib.alg.find] requires T to be EqualityComparable:
template <class InputIterator, class T> InputIterator find(InputIterator first, InputIterator last, const T& value);
However the condition being tested, as specified in the Effectsclause, is actually *i == value, where i is an InputIterator.
The two clauses are in agreement only if the type of *i is T, but thisisn't necessarily the case. *i may have a heterogeneous comparisonoperator that takes a T, or a T may be convertible to the type of *i.
Further discussion (c++std-lib-14264): this problem affects a number of algorithsm in clause 25, not justfind. We should try to resolve this problem everywhere it appears.
Proposed resolution:
[lib.alg.find]:
Remove [lib.alg.find]/1.
[lib.alg.count]:
Remove [lib.alg.count]/1.
[lib.alg.search]:
Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
[lib.alg.replace]:
Remove [lib.alg.replace]/1. Replace [lb.alg.replace]/2 with:
For every iterator i in the range [first, last) for which *i == value or pred(*i) holds perform *i = new_value.
Remove the first sentence of /4. Replace the beginning of /5 with:
For every iterator i in the range [result, result + (last - first)), assign to *i either...
(Note the defect here, current text says assign to i, not *i).
[lib.alg.fill]:
Remove "Type T is Assignable (23.1), " from /1. Replace /2 with:
For every iterator i in the range [first, last) or [first, first + n), perform *i = value.
[lib.alg.remove]:
Remove /1. Remove the first sentence of /6.
Rationale:
Duplicate of (a subset of) issue283(i).
Section: 26.8.9[alg.min.max]Status:DupSubmitter: Dave AbrahamsOpened: 2004-10-13Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withDup status.
Duplicate of:281
Discussion:
A straightforward implementation of these algorithms does not need tocopy T.
Proposed resolution:
drop the the words "and CopyConstructible" from paragraphs 1 and 4
Rationale:
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: Dhruv MataniOpened: 2004-10-17Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
The standard's version of allocator::construct(pointer,const_reference) severely limits what you can construct using thisfunction. Say you can construct a socket from a file descriptor. Now,using this syntax, I first have to manually construct a socket fromthe fd, and then pass the constructed socket to the construct()function so it will just to an uninitialized copy of the socket Imanually constructed. Now it may not always be possible to copyconstruct a socket eh! So, I feel that the changes should go in theallocator::construct(), making it:
template<typename T> struct allocator{ template<typename T1> void construct(pointer T1 const& rt1); };Now, the ctor of the class T which matches the one that takes a T1 canbe called! Doesn't that sound great?
Proposed resolution:
Rationale:
NAD. STL uses copying all the time, and making it possible for allocators to construct noncopyable objects is useless in the absence of corresponding container changes. We might consider this as part of a larger redesign of STL.
Section: 26.7.8[alg.remove]Status:NADSubmitter: Thomas MangOpened: 2004-12-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.remove].
View all issues withNAD status.
Discussion:
In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe thebehavior of the mutating sequence operations std::remove andstd::remove_if. However, the wording does not reflect the intendedbehavior [Note: See definition of intended behavior below] of thesealgorithms, as it is known to the C++ community [1].
1) Analysis of current wording:
25.2.7 [lib.alg.remove], paragraph 2:
Current wording says:"Effects: Eliminates all the elements referred to by iterator i in therange [first, last) for which the following corresponding conditionshold: *i == value, pred(*i) != false."
This sentences expresses specifically that all elements denoted by the(original) range [first, last) for which the corresponding conditionhold will be eliminated. Since there is no formal definition of the term"eliminate" provided, the meaning of "eliminate" in everyday languageimplies that as postcondition, no element in the range denoted by[first, last) will hold the corresponding condition on reiteration overthe range [first, last).
However, this is neither the intent [Note: See definition of intendedbehavior below] nor a general possible approach. It can be easily proventhat if all elements of the original range[first, last) will hold thecondition, it is not possible to substitute them by an element for whichthe condition will not hold.
25.2.7 [lib.alg.remove], paragraph 3:
Current wording says:"Returns: The end of the resulting range."
The resulting range is not specified. In combination with 25.2.7[lib.alg.remove], paragraph 2, the only reasonable interpretation ofthis so-called resulting range is the range [first,last) - thusreturning always the ForwardIterator 'last' parameter.
25.2.7 [lib.alg.remove], paragraph 4:
Current wording says:"Notes: Stable: the relative order of the elements that are not removedis the same as their relative order in the original range"
This sentences makes use of the term "removed", which is neitherspecified, nor used in a previous paragraph (which uses the term"eliminate"), nor unamgiuously separated from the name of the algorithm.
2) Description of intended behavior:
For the rest of this Defect Report, it is assumed that the intendedbehavior was that all elements of the range [first, last) which do nothold the condition *i == value (std::remove) or pred(*i) != false(std::remove_if)], call them s-elements [Note: s...stay], will be placedinto a contiguous subrange of [first, last), denoted by the iterators[first, return value). The number of elements in the resulting range[first, return value) shall be equal to the number of s-elements in theoriginal range [first, last). The relative order of the elements in theresulting subrange[first, return value) shall be the same as therelative order of the corresponding elements in the original range. Itis undefined whether any elements in the resulting subrange [returnvalue, last) will hold the corresponding condition, or not.
All implementations known to the author of this Defect Report complywith this intent. Since the intent of the behavior (contrary to thecurrent wording) is also described in various utility references servingthe C++ community [1], it is not expected that fixing the paragraphswill influence current code - unless the code relies on the behavior asit is described by current wording and the implementation indeedreflects the current wording, and not the intent.
3) Proposed fixes:
Change 25.2.7 [lib.alg.remove], paragraph 2 to:
"Effect: Places all the elements referred to by iterator i in the range[first, last) for which the following corresponding conditions hold :!(*i == value), pred(*i) == false into the subrange [first, k) of theoriginal range, where k shall denote a value of type ForwardIterator. Itis undefined whether any elements in the resulting subrange [k, last)will hold the corresponding condition, or not."
Comments to the new wording:
a) "Places" has no special meaning, and the everyday language meaningshould fit.b) The corresponding conditions were negated compared to the currentwording, becaue the new wording requires it.c) The wording "of the original range" might be redundant, since anysubrange starting at 'first' and containing no more elements than theoriginal range is implicitly a subrange of the original range [first,last).d) The iterator k was introduced instead of "return value" in order toavoid a cyclic dependency on 25.2.7/3. The wording ", where k shalldenote a value of type ForwardIterator" might be redundant, because itfollows implicitly by 25.2.7/3.e) "Places" does, in the author's opinion, explicitly forbid duplicatingany element holding the corresponding condition in the original range[first, last) within the resulting range [first, k). If there is doubtthis term might be not unambiguous regarding this, it is suggested thatk is specified more closely by the following wording: "k shall denote avalue of type ForwardIterator [Note: see d)] so that k - first is equalto the number of elements in the original range [first, last) for whichthe corresponding condition did hold". This could also be expressed as aseparate paragraph "Postcondition:"f) The senctence "It is undefined whether any elements in the resultingsubrange [k, last) will hold the corresponding condition, or not." wasadded consciously so the term "Places" does not imply if the originalrange [first, last) contains n elements holding the correspondingcondition, the identical range[first, last) will also contain exactly nelements holding the corresponding condition after application of thealgorithm.
Change 25.2.7 [lib.alg.remove], paragraph 3 to:"Returns: The iterator k."
Change 25.2.7 [lib.alg.remove], paragraph 4 to:"Notes: Stable: the relative order of the elements that are placed intothe subrange [first, return value) shall be the same as their relativeorder was in the original range [first, last) prior to application ofthe algorithm."
Comments to the new wording:
a) the wording "was ... prior to application of the algorithm" is usedto explicitly distinguish the original range not only by means ofiterators, but also by a 'chronological' factor from the resulting range[first, return value). It might be redundant.
[1]:The wording of these references is not always unambiguous, and providedexamples partially contradict verbal description of the algorithms,because the verbal description resembles the problematic wording ofISO/IEC 14882:2003.
Proposed resolution:
Rationale:
The LWG believes that the standard is sufficiently clear, and that there is no evidence of any real-world confusion about this point.
Section: 26.7.9[alg.unique]Status:NADSubmitter: Thomas MangOpened: 2004-12-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.unique].
View all issues withNAD status.
Discussion:
In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe thebehavior of the mutating sequence operation std::unique. However, thewording does not reflect the intended behavior [Note: See definition ofintended behavior below] of these algorithms, as it is known to the C++community [1].
1) Analysis of current wording:
25.2.8 [lib.alg.unique], paragraph 1:
Current wording says:"Effects: Eliminates all but the first element from every consecutivegroup of equal elements referred to by the iterator i in the range[first, last) for which the following corresponding conditions hold: *i== *(i - 1) or pred(*i, *(i -1)) != false"
This sentences expresses specifically that all elements denoted by the(original) range [first, last) which are not but the first element froma consecutive group of equal elements (where equality is defined as *i== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], callthem r-elements [Note: r...remove], will be eliminated. Since there isno formal definition of the term "eliminate" provided, it is undefinedhow this "elimination" takes place. But the meaning of "eliminate" ineveryday language seems to disallow explicitly that after application ofthe algorithm, any r-element will remain at any position of the range[first, last) [2].
Another defect in the current wording concerns the iterators used tocompare two elements for equality: The current wording contains theexpression "(i - 1)", which is not covered by 25/9 [Note: See DRsubmitted by Thomas Mang regarding invalid iterator arithmeticexpressions].
25.2.8 [lib.alg.unique], paragraph 2:
Current wording says:"Returns: The end of the resulting range."
The resulting range is not specified. In combination with 25.2.8[lib.alg.unique], paragraph 1, one reasonable interpretation (in theauthor's opinion even the only possible interpretation) of thisso-called resulting range is the range [first, last) - thus returningalways the ForwardIterator 'last' parameter.
2) Description of intended behavior:
For the rest of this Defect Report, it is assumed that the intendedbehavior was that all elements denoted by the original range [first,last) which are the first element from a consecutive group of elementsfor which the corresponding conditions: *(i-1) == *i (for the version ofunique without a predicate argument) or pred(*(i-1), *i) ! = false (forthe version of unique with a predicate argument) [Note: If such a groupof elements consists of only a single element, this is also consideredthe first element] [Note: See resolutions of DR 202], call thems-elements [Note: s...stay], will be placed into a contiguous subrangeof [first, last), denoted by the iterators [first, return value). Thenumber of elements in the resulting range [first, return value) shall beequal to the number of s-elements in the original range [first, last).Invalid iterator arithmetic expressions are expected to be resolved asproposed in DR submitted by Thomas Mang regarding invalid iteratorarithmetic expressions. It is also assumed by the author that therelative order of the elements in the resulting subrange [first, returnvalue) shall be the same as the relative order of the correspondingelements (the s-elements) in the original range [Note: If this was notintended behavior, the additional proposed paragraph about stable orderwill certainly become obsolete].Furthermore, the resolutions of DR 202 are partially considered.
All implementations known to the author of this Defect Report complywith this intent [Note: Except possible effects of DR 202]. Since thisintent of the behavior (contrary to the current wording) is alsodescribed in various utility references serving the C++ community [1],it is not expected that fixing the paragraphs will influence currentcode [Note: Except possible effects of DR 202] - unless the code relieson the behavior as it is described by current wording and theimplementation indeed reflects the current wording, and not the intent.
3) Proposed fixes:
Change 25.2.8 [lib.alg.unique], paragraph 1 to:
"Effect: Places the first element from every consecutive group ofelements, referred to by the iterator i in the range [first, last), forwhich the following conditions hold: *(i-1) == *i (for the version ofunique without a predicate argument) or pred(*(i -1), *i) != false (forthe version of unique with a predicate argument), into the subrange[first, k) of the original range, where k shall denote a value of typeForwardIterator."
Comments to the new wording:
a) The new wording was influenced by the resolutions of DR 202. If DR202 is resolved in another way, the proposed wording need alsoadditional review.b) "Places" has no special meaning, and the everyday language meaningshould fit.c) The expression "(i - 1)" was left, but is expected that DR submittedby Thomas Mang regarding invalid iterator arithmetic expressions willtake this into account.d) The wording "(for the version of unique without a predicateargument)" and "(for the version of unique with a predicate argument)"was added consciously for clarity and is in resemblence with current23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.e) The wording "of the original range" might be redundant, since anysubrange starting at first and containing no more elements than theoriginal range is implicitly a subrange of the original range [first,last).f) The iterator k was introduced instead of "return value" in order toavoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. Thewording ", where k shall denote a value of type ForwardIterator" mightbe redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],paragraph 2.g) "Places" does, in the author's opinion, explicitly forbid duplicatingany s-element in the original range [first, last) within the resultingrange [first, k). If there is doubt this term might be not unambiguousregarding this, it is suggested that k is specified more closely by thefollowing wording: "k shall denote a value of type ForwardIterator[Note: See f)] so that k - first is equal to the number of elements inthe original range [first, last) being the first element from everyconsecutive group of elements for which the corresponding condition didhold". This could also be expressed as a separate paragraph"Postcondition:".h) If it is considered that the wording is unclear whether it declaresthe element of a group which consists of only a single elementimplicitly to be the first element of this group [Note: Such aninterpretation could eventually arise especially in case last - first ==1] , the following additional sentence is proposed: "If such a group ofelements consists of only a single element, this element is alsoconsidered the first element."
Change 25.2.8 [lib.alg.unique], paragraph 2 to:"Returns: The iterator k."
Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated ifthe preceding expressions are used, or the preceding expressions shallbe eliminated if wording inside {} is used):
"Notes:{Postcondition:} Stable: the relative order of the elements thatare placed into the subrange [first, return value {k}) shall be the sameas their relative order was in the original range [first, last) prior toapplication of the algorithm."
Comments to the new wording:
a) It is assumed by the author that the algorithm was intended to bestable.In case this was not the intent, this paragraph becomes certainlyobsolete.b) The wording "was ... prior to application of the algorithm" is usedto explicitly distinguish the original range not only by means ofiterators, but also by a 'chronological' factor from the resulting range[first, return value). It might be redundant.
25.2.8 [lib.alg.unique], paragraph 3:
See DR 239.
4) References to other DRs:
See DR 202, but which does not address any of the problems described inthis Defect Report [Note: This DR is supposed to complement DR 202].See DR 239.See DR submitted by Thomas Mang regarding invalid iterator arithmeticexpressions.
[1]:The wording of these references is not always unambiguous, and providedexamples partially contradict verbal description of the algorithms,because the verbal description resembles the problematic wording ofISO/IEC 14882:2003.
[2]:Illustration of conforming implementations according to current wording:
One way the author of this DR considers how this "elimination" could beachieved by a conforming implementation according to current wording isby substituting each r-element by _any_ s-element [Note: s...stay; anynon-r-element], since all r-elements are "eliminated".
In case of a sequence consisting of elements being all 'equal' [Note:See DR 202], substituting each r-element by the single s-element is theonly possible solution according to current wording.
Proposed resolution:
Rationale:
The LWG believes the standard is sufficiently clear. Noimplementers get it wrong, and changing it wouldn't cause any code tochange, so there is no real-world harm here.
Section: 23.3.11.5[list.ops]Status:NADSubmitter: Thomas MangOpened: 2004-12-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [list.ops].
View all issues withNAD status.
Discussion:
In Section 23.3.11.5[list.ops], paragraphs 19 to 21 describe thebehavior of the std::list<T, Allocator>::unique operation. However, thecurrent wording is defective for various reasons.
1) Analysis of current wording:
23.3.11.5[list.ops], paragraph 19:
Current wording says:"Effects: Eliminates all but the first element from every consecutivegroup of equal elements referred to by the iterator i in the range[first + 1, last) for which *i == *(i - 1) (for the version of uniquewith no argument) or pred(*i, *(i -1)) (for the version of unique with apredicate argument) holds."
This sentences makes use of the undefined term "Eliminates". Although itis, to a certain degree, reasonable to consider the term "eliminate"synonymous with "erase", using "Erase" in the first place, as thewording of 23.3.11.5[list.ops], paragraph 15 does, would be clearer.
The range of the elements referred to by iterator i is "[first + 1,last)". However, neither "first" nor "last" is defined.
The sentence makes three times use of iterator arithmetic expressions ("first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is notdefined for bidirectional iterator [see DR submitted by Thomas Mangregarding invalid iterator arithmetic expressions].
The same problems as pointed out in DR 202 (equivalence relation / orderof arguments for pred()) apply to this paragraph.
23.3.11.5[list.ops], paragraph 20:
Current wording says:"Throws: Nothing unless an exception in thrown by *i == *(i-1) orpred(*i, *(i - 1))"
The sentence makes two times use of invalid iterator arithmeticexpressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
[Note: Minor typos: "in" / missing dot at end of sentence.]
23.3.11.5[list.ops], paragraph 21:
Current wording says:"Complexity: If the range (last - first) is not empty, exactly (last -first) - 1 applications of the corresponding predicate, otherwise noapplication of the predicate.
See DR 315 regarding "(last - first)" not yielding a range.
Invalid iterator arithmetic expression "(last - first) - 1" left .
2) Description of intended behavior:
For the rest of this Defect Report, it is assumed that "eliminate" issupposed to be synonymous to "erase", that "first" is equivalent to aniterator obtained by a call to begin(), "last" is equivalent to aniterator obtained by a call to end(), and that all invalid iteratorarithmetic expressions are resolved as described in DR submitted byThomas Mang regarding invalid iterator arithmetic expressions.
Furthermore, the resolutions of DR 202 are considered regardingequivalence relation and order of arguments for a call to pred.
All implementations known to the author of this Defect Report complywith these assumptions, apart from the impact of the alternativeresolution of DR 202. Except for the changes implied by the resolutionsof DR 202, no impact on current code is expected.
3) Proposed fixes:
Change 23.3.11.5[list.ops], paragraph 19 to:
"Effect: Erases all but the first element from every consecutive groupof elements, referred to by the iterator i in the range [begin(),end()), for which the following conditions hold: *(i-1) == *i (for theversion of unique with no argument) or pred(*(i-1), *i) != false (forthe version of unique with a predicate argument)."
Comments to the new wording:
a) The new wording was influenced by DR 202 and the resolutionspresented there. If DR 202 is resolved in another way, the proposedwording need also additional review.b) "Erases" refers in the author's opinion unambiguously to the memberfunction "erase". In case there is doubt this might not be unamgibuous,a direct reference to the member function "erase" is suggested [Note:This would also imply a change of 23.3.11.5[list.ops], paragraph15.].c) The expression "(i - 1)" was left, but is expected that DR submittedby Thomas Mang regarding invalid iterator arithmetic expressions willtake this into account.d) The wording "(for the version of unique with no argument)" and "(forthe version of unique with a predicate argument)" was kept consciouslyfor clarity.e) "begin()" substitutes "first", and "end()" substitutes "last". Therange need adjustment from "[first + 1, last)" to "[begin(), end())" toensure a valid range in case of an empty list.f) If it is considered that the wording is unclear whether it declaresthe element of a group which consists of only a single elementimplicitly to be the first element of this group [Note: Such aninterpretation could eventually arise especially in case size() == 1] ,the following additional sentence is proposed: "If such a group ofelements consists of only a single element, this element is alsoconsidered the first element."
Change 23.3.11.5[list.ops], paragraph 20 to:
"Throws: Nothing unless an exception is thrown by *(i-1) == *i orpred(*(i-1), *i)."
Comments to the new wording:
a) The wording regarding the conditions is identical to proposed23.3.11.5[list.ops], paragraph 19. If 23.3.11.5[list.ops],paragraph 19 is resolved in another way, the proposed wording need alsoadditional review.b) The expression "(i - 1)" was left, but is expected that DR submittedby Thomas Mang regarding invalid iterator arithmetic expressions willtake this into account.c) Typos fixed.
Change 23.3.11.5[list.ops], paragraph 21 to:
"Complexity: If empty() == false, exactly size() - 1 applications of thecorresponding predicate, otherwise no applications of the correspondingpredicate."
Comments to the new wording:
a) The new wording is supposed to also replace the proposed resolutionof DR 315, which suffers from the problem of undefined "first" / "last".
5) References to other DRs:
See DR 202.See DR 239.See DR 315.See DR submitted by Thomas Mang regarding invalid iterator arithmeticexpressions.
Proposed resolution:
Rationale:
"All implementations known to the author of this Defect Reportcomply with these assumption", and "no impact on current code isexpected", i.e. there is no evidence of real-world confusion orharm.
Section: 16.3.2.4[structure.specifications]Status:NADSubmitter: Thomas MangOpened: 2004-12-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [structure.specifications].
View all otherissues in [structure.specifications].
View all issues withNAD status.
Discussion:
Various clauses other than clause 25 make use of iterator arithmetic notsupported by the iterator category in question.Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],paragraph 9, but this paragraph does not provide semantics to theexpression "iterator - n", where n denotes a value of a distance typebetween iterators.
1) Examples of current wording:
Current wording outside clause 25:
23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)","(last - first)"23.3.1.1 [lib.map.cons], paragraph 4: "last - first"23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"23.3.3.1 [lib.set.cons], paragraph 4: "last - first"23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
[Important note: The list is not complete, just an illustration. Thesame issue might well apply to other paragraphs not listed here.]
None of these expressions is valid for the corresponding iteratorcategory.
Current wording in clause 25:
25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -(last2-first2))"25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
However, current wording of 25 [lib.algorithms], paragraph 9 coversneither of these four cases:
Current wording of 25 [lib.algorithms], paragraph 9:
"In the description of the algorithms operator + and - are used for someof the iterator categories for which they do not have to be defined. Inthese cases the semantics of a+n is the same as that of
{X tmp = a;advance(tmp, n);return tmp;}and that of b-a is the same as of return distance(a, b)"
This paragrpah does not take the expression "iterator - n" into account,where n denotes a value of a distance type between two iterators [Note:According to current wording, the expression "iterator - n" would beresolved as equivalent to "return distance(n, iterator)"]. Even if theexpression "iterator - n" were to be reinterpreted as equivalent to"iterator + -n" [Note: This would imply that "a" and "b" wereinterpreted implicitly as values of iterator types, and "n" as value ofa distance type], then 24.3.4/2 interfers because it says: "Requires: nmay be negative only for random access and bidirectional iterators.",and none of the paragraphs quoted above requires the iterators on whichthe algorithms operate to be of random access or bidirectional category.
2) Description of intended behavior:
For the rest of this Defect Report, it is assumed that the expression"iterator1 + n" and "iterator1 - iterator2" has the semantics asdescribed in current 25 [lib.algorithms], paragraph 9, but applying toall clauses. The expression "iterator1 - n" is equivalent to anresult-iterator for which the expression "result-iterator + n" yields aniterator denoting the same position as iterator1 does. The terms"iterator1", "iterator2" and "result-iterator" shall denote the value ofan iterator type, and the term "n" shall denote a value of a distancetype between two iterators.
All implementations known to the author of this Defect Report complywith these assumptions.No impact on current code is expected.
3) Proposed fixes:
Change 25 [lib.algorithms], paragraph 9 to:
"In the description of the algorithms operator + and - are used for someof the iterator categories for which they do not have to be defined. Inthis paragraph, a and b denote values of an iterator type, and n denotesa value of a distance type between two iterators. In these cases thesemantics of a+n is the same as that of
{X tmp = a;advance(tmp, n);return tmp;},the semantics of a-n denotes the value of an iterator i for which thefollowing condition holds:advance(i, n) == a,and that of b-a is the same as ofreturn distance(a, b)".
Comments to the new wording:
a) The wording " In this paragraph, a and b denote values of an iteratortype, and n denotes a value of a distance type between two iterators."was added so the expressions "b-a" and "a-n" are distinguished regardingthe types of the values on which they operate.b) The wording ",the semantics of a-n denotes the value of an iterator ifor which the following condition holds: advance(i, n) == a" was addedto cover the expression 'iterator - n'. The wording "advance(i, n) == a"was used to avoid a dependency on the semantics of a+n, as the wording"i + n == a" would have implied. However, such a dependency might wellbe deserved.c) DR 225 is not considered in the new wording.
Proposed fixes regarding invalid iterator arithmetic expressions outsideclause 25:
Eithera) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)before any current invalid iterator arithmetic expression. In that case,the first sentence of 25 [lib.algorithms], paragraph 9, need also to bemodified and could read: "For the rest of this International Standard,...." / "In the description of the following clauses including this...." / "In the description of the text below ..." etc. - anywayssubstituting the wording "algorithms", which is a straight reference toclause 25.In that case, 25 [lib.algorithms] paragraph 9 will certainly becomeobsolete.Alternatively,b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],paragraph 9, to the beginning of each clause containing invalid iteratorarithmetic expressions.Alternatively,c) Fix each paragraph (both current wording and possible resolutions ofDRs) containing invalid iterator arithmetic expressions separately.
5) References to other DRs:
See DR 225.See DR 237. The resolution could then also read "Linear in last -first".
[Bellevue:]
Keep open and ask Bill to provide wording.
[2009-05-09 Alisdair adds:]
[2009-07 Frankfurt]
Hinnant: this isn't going to change any user's code or any vendor's implementation.
No objection to "NAD without prejudice." If anyone proposes aresolution, the LWG will consider it.
Move to NAD.
Proposed resolution:
[Lillehammer: Minor issue, but real. We have a blanket statementabout this in 25/11. But (a) it should be in 17, not 25; and (b) it'snot quite broad enough, because there are some arithmetic expressionsit doesn't cover. Bill will provide wording.]
Section: 24.3.5.3[input.iterators]Status:NADSubmitter: Chris JeffersonOpened: 2004-12-13Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [input.iterators].
View all otherissues in [input.iterators].
View all issues withNAD status.
Discussion:
1) In 24.1.1/3, the following text is currently present.
"Note: For input iterators, a==b does not imply ++a=++b (Equality doesnot guarantee the substitution property or referential transparency)."
However, when in Table 72, part of the definition of ++r is given as:
"pre: r is dereferenceable.post: any copies of the previous value of r are no longer requiredeither to be dereferenceable ..."
While a==b does not imply that b is a copy of a, this statement shouldperhaps still be made more clear.
2) There are no changes to intended behaviour
3) This Note should be altered to say "Note: For input iterators a==b,when its behaviour is defined ++a==++b may still be false (Equality doesnot guarantee the substitution property or referential transparency).
Proposed resolution:
Rationale:
This is descriptive text, not normative, and the meaning is clear.
Section: 23.2.7[associative.reqmts]Status:NADSubmitter: Hans B osOpened: 2004-12-19Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
According to [lib.associative.reqmts] table 69, the runtime comlexityof insert(p, t) and erase(q) can be done in amortized constant time.
It was my understanding that an associative container could beimplemented as a balanced binary tree.
For inser(p, t), you 'll have to iterate to p's next node to see if tcan be placed next to p. Furthermore, the insertion usually takesplace at leaf nodes. An insert next to the root node will be done atthe left of the root next node
So when p is the root node you 'll have to iterate from the root toits next node, which takes O(log(size)) time in a balanced tree.
If you insert all values with insert(root, t) (where root is theroot of the tree before insertion) then each insert takes O(log(size))time. The amortized complexity per insertion will be O(log(size))also.
For erase(q), the normal algorithm for deleting a node that has noempty left or right subtree, is to iterate to the next (or previous),which is a leaf node. Then exchange the node with the next and deletethe leaf node. Furthermore according to DR 130, erase should returnthe next node of the node erased. Thus erasing the root node,requires iterating to the next node.
Now if you empty a map by deleting the root node until the map isempty, each operation will take O(log(size)), and the amortizedcomplexity is still O(log(size)).
The operations can be done in amortized constant time if iteratingto the next node can be done in (non amortized) constant time. Thiscan be done by putting all nodes in a double linked list. Thisrequires two extra links per node. To me this is a bit overkill sinceyou can already efficiently insert or erase ranges with erase(first,last) and insert(first, last).
Proposed resolution:
Rationale:
Only "amortized constant" in special circumstances, and we believe that's implementable. That is: doing this N times will be O(N), not O(log N).
Section: 26.8.2.2[stable.sort]Status:NAD EditorialSubmitter: Prateek KarandikarOpened: 2005-04-12Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
17.3.1.1 Summary
1 The Summary provides a synopsis of the category, and introduces the first-level subclauses. Each subclause also provides a summary, listing the headers specified in the subclause and the library entities provided in each header.
2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, other paragraphs are normative.
So this means that a "Notes" paragraph wouldn't be normative.
25.3.1.2 stable_sort
template<class RandomAccessIterator> void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); template<class RandomAccessIterator, class Compare> void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);1 Effects: Sorts the elements in the range [first, last).
2 Complexity: It does at most N(log N)^2 (where N == last - first) comparisons; if enough extra memory is available, it is N log N.
3 Notes: Stable: the relative order of the equivalent elements is preserved.
The Notes para is informative, and nowhere else is stability mentioned above.
Also, I just searched for the word "stable" in my copy of the Standard. and the phrase "Notes: Stable: the relative order of the elements..." is repeated several times in the Standard library clauses for describing various functions. How is it that stability is talked about in the informative paragraph? Or am I missing something obvious?
Proposed resolution:
Rationale:
This change has already been made.
Section: 28.3.4.2.6[locale.codecvt.byname]Status:NADSubmitter: Krzysztof ŻelechowskiOpened: 2005-05-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.codecvt.byname].
View all issues withNAD status.
Discussion:
Contradiction.
Proposed resolution:
Section: 99 [depr.base]Status:NADSubmitter: Me <anti_spam_email2003@yahoo.com>Opened: 2005-06-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [depr.base].
View all issues withNAD status.
Discussion:
"For templates greater, less, greater_equal, and less_equal,the specializations for any pointer type yield a total order, even ifthe built-in operators <, >, <=, >= do not."
The standard should do much better than guarantee that these provide atotal order, it should guarantee that it can be used to test if memoryoverlaps, i.e. write a portable memmove. You can imagine a platformwhere the built-in operators use a uint32_t comparison (this tests foroverlap on this platform) but the less<T*> functor is allowed to bedefined to use a int32_t comparison. On this platform, if you usestd::less with the intent of making a portable memmove, comparison onan array that straddles the 0x7FFFFFFF/0x8000000 boundary can giveincorrect results.
Proposed resolution:
Add a footnote to 20.5.3/8 saying:
Given a p1 and p2 such that p1 points to N objects of type T and p2points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),less returns the same value when comparing all pointers in [p1,p1+N) toall pointers in [p2,p2+M). Otherwise, there is a value Q and a value Rsuch that less returns the same value when comparing all pointers in[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value whencomparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).For the sake of completeness, the null pointer value (4.10) for T isconsidered to be an array of 1 object that doesn't overlap with anynon-null pointer to T. less_equal, greater, greater_equal, equal_to,and not_equal_to give the expected results based on the total orderingsemantics of less. For T of void, treat it as having similar semanticsas T of char i.e. less<cv T*>(a, b) gives the same results as less<cvvoid*>(a, b) which gives the same results as less<cv char*>((cvchar*)(cv void*)a, (cv char*)(cv void*)b).
I'm also thinking there should be a footnote to 20.5.3/1 saying that ifA and B are similar types (4.4/4), comp<A>(a,b) returns the same valueas comp<B>(a,b) (where comp is less, less_equal, etc.). But this mightbe problematic if there is some really funky operator overloading goingon that does different things based on cv (that should be undefinedbehavior if somebody does that though). This at least should beguaranteed for all POD types (especially pointers) that use thebuilt-in comparison operators.
Rationale:
less is already required to provide a strict weak ordering which is good enoughto detect overlapping memory situations.
Section: 28.3.3.1.2.1[locale.category]Status:NADSubmitter: Christopher Conrade ZseleghovskiOpened: 2005-06-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.category].
View all issues withNAD status.
Discussion:
Motivation:
This requirement seems obvious to me, it is the essence of code modularity. I have complained to Mr. Plauger that the Dinkumware library does not observe this principle but he objected that this behaviour is not covered in the standard.
[2009-07 Frankfurt]
No objection to NAD, Fixed.
Move to NAD.
Proposed resolution:
Append the following point to 22.1.1.1.1:
6. The implementation of a facet of Table 52 parametrized with an InputIterator/OutputIterator should use that iterator only as character source/sink respectively.For a *_get facet, it means that the value received depends only on the sequence of input characters and not on how they are accessed.For a *_put facet, it means that the sequence of characters output depends only on the value to be formatted and not of how the characters are stored.
[Berlin: Moved to Open, Need to clean up this area to make it clearlocales don't have to contain open ended sets of facets. Jack, Howard,Bill.]
Section: 28.3.4[locale.categories]Status:NADSubmitter: P.J. PlaugerOpened: 2005-06-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.categories].
View all issues withNAD status.
Discussion:
a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table51" to refer to the facet *objects* associated with a locale. And wealmost certainly mean just those associated with the default or "C"locale. Otherwise, you can't switch to a locale that enforces a differentmapping between narrow and wide characters, or that defines additionaluppercase characters.
b) 22.2.1.5 para. 3 (codecvt) has the same issues.
c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation ofa homing sequence for the basic character set, which might very well needone.
d) 22.2.1.5.2 (do_length) likewise dictates that the default mappingbetween wide and narrow characters be taken as one-for-one.
e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far asI can tell. The muddle is, as before, calling Table 51 a list ofinstantiations. But the constraint it applies seems to me to cover*all* defined uses of num_get/put, so why bother to say so?
f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiationsreturn '.' or L'.'.) Presumably this means "as appropriate for thecharacter type. But given the vague definition of "required" earlier,this overrules *any* change of decimal point for non "C" locales.Surely we don't want to do that.
g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiationsreturn ',' or L','.) As above, this probably means "as appropriate for thecharacter type. But this overrules the "C" locale, which requires *no*character ('\0') for the thousands separator. Even if we agree that wedon't mean to block changes in decimal point or thousands separator,we should also eliminate this clear incompatibility with C.
h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiationsreturn the empty string, indicating no grouping." Same considerationsas for do_decimal_point.
i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table51". Same bad jargon.
j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations requiredin Table 51". Same bad jargon.
k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuousas num_get/put.
l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuousas num_get/put.
m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations requiredin Table 51 ... return an object of type pattern initialized to{symbol, sign, none, value}." This once again *overrides* the "C"locale, as well as any other locale."
3) We constrain the use_facet calls that can be made by num_get/put,so why don't we do the same for money_get/put? Or for any of theother facets, for that matter?
4) As an almost aside, we spell out when a facet needs to use the ctypefacet, but several also need to use a codecvt facet and we don't say so.
[Berlin: Bill to provide wording.]
[2009-07 Frankfurt]
No objection to NAD.
Move to NAD.
Proposed resolution:
Section: 29.5.3[rand.req], 99 [tr.rand.req]Status:NAD EditorialSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req].
View all issues withNAD Editorial status.
Discussion:
In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,g is an ... object returning values of unsigned integral type ..."
Proposed resolution:
In 5.1.1 [tr.rand.req], Paragraph 2 replace
... s is a value of integral type, g is an lvalue of a type other than X thatdefines a zero-argument function object returning values of
unsigned integraltypeunsigned long int,...
In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
creates an engine with the initial internal statedetermined by
static_cast<unsigned long>(s)
[Mont Tremblant: Both s and g should be unsigned long.This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.]
[Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Movedto Ready.]
Rationale:
Jens: Just requiring X(unsigned long) still makes it possiblefor an evil library writer to also supply a X(int) that does somethingunexpected. The wording above requires that X(s) always performsas if X(unsigned long) would have been called. I believe that issufficient and implements our intentions from Mont Tremblant. Isee no additional use in actually requiring a X(unsigned long)signature. u.seed(s) is covered by its reference to X(s), samearguments.
[Portland: Subsumed by N2111.]
Section: 29.5[rand], 99 [tr.rand.var]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand].
View all issues withNAD status.
Discussion:
Paragraph 3 requires that template argument U (which corresponds to templateparameter Engine) satisfy all uniform random number generator requirements.However, there is no analogous requirement regarding the template argumentthat corresponds to template parameter Distribution. We believe there shouldbe, and that it should require that this template argument satisfy all randomdistribution requirements.
Proposed resolution:
Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
Consequence 2: Add max() and min() functions to those distributions thatdo not already have them.
[Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.Marc supports having min and max to satisfy generic programming interface.]
Rationale:
Berlin: N1932 makes this moot: variate_generator has been eliminated.
Section: 29.5.9.2[rand.dist.uni], 99 [tr.rand.dist.iunif]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.uni].
View all issues withNAD status.
Discussion:
In [tr.rand.dist.iunif] the uniform_int distribution currently has a singletemplate parameter, IntType, used as the input_type and as the result_typeof the distribution. We believe there is no reason to conflate these typesin this way.
Proposed resolution:
We recommend that there be a second template parameter toreflect the distribution's input_type, and that the existing first templateparameter continue to reflect (solely) the result_type:
template< class IntType = int, UIntType = unsigned int >class uniform_int{public: // types typedef UIntType input_type; typedef IntType result_type;[Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has beeneliminated.]
Section: 29.5.9.3[rand.dist.bern], 99 [tr.rand.dist.bern]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
In [tr.rand.dist.bern] the distribution currently requires;
typedef int input_type;
Proposed resolution:
We believe this is an unfortunate choice, and recommend instead:
typedef unsigned int input_type;
[Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has beeneliminated.]
Section: 29.5.9[rand.dist], 99 [tr.rand.dist.bin]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist].
View all issues withNAD status.
Discussion:
Unlike all other distributions in TR1, this binomial_distribution has animplementation-defined input_type. We believe this is an unfortunate choice,because it hinders users from writing portable code. It also hinders thewriting of compliance tests. We recommend instead:
typedef RealType input_type;
While this choice is somewhat arbitrary (as it was for some of the otherdistributions), we make this particular choice because (unlike all otherdistributions) otherwise this template would not publish its RealTypeargument and so users could not write generic code that accessed thissecond template parameter. In this respect, the choice is consistent withthe other distributions in TR1.
We have two reasons for recommending that a real type be specified instead.One reason is based specifically on characteristics of binomial distributionimplementations, while the other is based on mathematical characteristics ofprobability distribution functions in general.
Implementations of binomial distributions commonly use Stirling approximationsfor values in certain ranges. It is far more natural to use real values torepresent these approximations than it would be to use integral values to doso. In other ranges, implementations reply on the Bernoulli distribution toobtain values. While TR1's bernoulli_distribution::input_type is specified asint, we believe this would be better specified as double.
This brings us to our main point: The notion of a random distribution restson the notion of a cumulative distribution function, which in turn mathematicallydepends on a continuous dependent variable. Indeed, such a distribution functionwould be meaningless if it depended on discrete values such as integers - and thisremains true even if the distribution function were to take discrete steps.
Although this note is specifically about binomial_distribution::input_type,we intend to recommend that all of the random distributions input_types bespecified as a real type (either a RealType template parameter, or double,as appropriate).
Of the nine distributions in TR1, four already have this characteristic(uniform_real, exponential_distribution, normal_distribution, andgamma_distribution). We have already argued the case for the binomial theremaining four distributions.
In the case of uniform_int, we believe that the calculations to produce aninteger result in a specified range from an integer in a different specifiedrange is best done using real arithmetic. This is because it involves aproduct, one of whose terms is the ratio of the extents of the two ranges.Without real arithmetic, the results become less uniform: some numbers becomemore (or less) probable that they should be. This is, of course, undesireablebehavior in a uniform distribution.
Finally, we believe that in the case of the bernoulli_distribution (brieflymentioned earlier), as well as the cases of the geometric_distribution and thepoisson_distribution, it would be far more natural to have a real input_type.This is because the most natural computation involves the random numberdelivered and the distribution's parameter p (in the case of bernoulli_distribution,for example, the computation is a comparison against p), and p is already specifiedin each case as having some real type.
Proposed resolution:
typedef RealType input_type;
[Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has beeneliminated.]
subtract_with_carry_01 from a single unsigned longSection: 29.5.4[rand.eng], 99 [tr.rand.eng.sub1]Status:NAD EditorialSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.eng].
View all issues withNAD Editorial status.
Discussion:
Paragraph 8 specifies the algorithm by which asubtract_with_carry_01 engineis to be seeded given a single unsigned long. This algorithm is seriouslyflawed in the case where the engine parameter w (also known as word_size)exceeds 31 [bits]. The key part of the paragraph reads:
sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
and so forth.
Since the specified linear congruential engine, lcg, delivers numbers witha maximum of 2147483563 (just a shade under 31 bits), then when w is, forexample, 48, each of the x(i) will be less than 2**-17. The consequenceis that roughly the first 400 numbers delivered will be conspicuouslyclose to either zero or one.
Unfortunately, this is not an innocuous flaw: One of the predefined enginesin [tr.rand.predef], namelyranlux64_base_01, has w = 48 and would exhibitthis poor behavior, while the original N1378 proposal states that thesepre-defined engines are intended to be of "known good properties."
Proposed resolution:
In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause forvoid seed(unsigned long value = 19780503) by
Effects: If
value == 0, sets value to19780503. In anycase,with a linear congruential generatorsetscarrylcg(i) having parametersmlcg = 2147483563,alcg = 40014,clcg = 0, andlcg(0) = value,(-1)andx(-r) … x(-1)as if executinglinear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);seed(lcg);
to(lcg(1) · 2-w) mod 1… (lcg(r) · 2-w) mod 1,respectively. Ifx(-1) == 0, sets carry(-1) = 2-w,else sets carry(-1) = 0.
[Jens provided revised wording post Mont Tremblant.]
[Berlin: N1932 adopts the originally-proposed resolution of the issue.Jens's supplied wording is a clearer description of what isintended. Moved to Ready.]
Rationale:
Jens: I'm using an explicit type here, because fixing theprose would probably not qualify for the (with issue504(i) evenstricter) requirements we have for seed(Gen&).
[Portland: Subsumed by N2111.]
Section: 29.5.4[rand.eng], 99 [tr.rand.eng.sub1]Status:NAD EditorialSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.eng].
View all issues withNAD Editorial status.
Discussion:
Paragraph 3 begins:
The size of the state is r.
However, this is not quite consistent with the remainder of the paragraphwhich specifies a total of nr+1 items in the textual representation ofthe state. We recommend the sentence be corrected to match:
The size of the state is nr+1.
To give meaning to the coefficient n, it may be also desirable to moven's definition from later in the paragraph. Either of the followingseem reasonable formulations:
With n=..., the size of the state is nr+1.
The size of the state is nr+1, where n=... .
Proposed resolution:
[Jens: I plead for "NAD" on the grounds that "size of state" is onlyused as an argument for big-O complexity notation, thusconstant factors and additions don't count.]
[Berlin: N1932 adopts the proposed NAD.]
Section: 29.5.4.4[rand.eng.sub], 99 [tr.rand.eng.sub]Status:NAD EditorialSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.eng.sub].
View all issues withNAD Editorial status.
Discussion:
Paragraph 2 begins:
The size of the state is r.
However, the next sentence specifies a total of r+1 items in the textualrepresentation of the state, r specific x's as well as a specific carry.This makes a total of r+1 items that constitute the size of the state,rather than r.
Proposed resolution:
We recommend the sentence be corrected to match:
The size of the state is r+1.
[Jens: I plead for "NAD" on the grounds that "size of state" is onlyused as an argument for big-O complexity notation, thusconstant factors and additions don't count.]
[Berlin: N1932 adopts the proposed NAD.]
Section: 29.5.2[rand.synopsis], 99 [tr.rand.synopsis]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.synopsis].
View all issues withNAD status.
Discussion:
To accompany the concept of a pseudo-random number engine as defined in Table 17,we propose and recommend an adjunct template, engine_traits, to be declared in[tr.rand.synopsis] as:
template< class PSRE >class engine_traits;
This template's primary purpose would be as an aid to generic programming involvingpseudo-random number engines. Given only the facilities described in tr1, it wouldbe very difficult to produce any algorithms involving the notion of a generic engine.The intent of this proposal is to provide, via engine_traits<>, sufficientdescriptive information to allow an algorithm to employ a pseudo-random number enginewithout regard to its exact type, i.e., as a template parameter.
For example, today it is not possible to write an efficient generic function thatrequires any specific number of random bits. More specifically, consider acryptographic application that internally needs 256 bits of randomness per call:
template< class Eng, class InIter, class OutIter >void crypto( Eng& e, InIter in, OutIter out );
Without knowning the number of bits of randomness produced per call to a providedengine, the algorithm has no means of determining how many times to call the engine.
In a new section [tr.rand.eng.traits], we proposed to define the engine_traitstemplate as:
template< class PSRE >class engine_traits{ static std::size_t bits_of_randomness = 0u; static std::string name() { return "unknown_engine"; } // TODO: other traits here};Further, each engine described in [tr.rand.engine] would be accompanied by acomplete specialization of this new engine_traits template.
Proposed resolution:
[Berlin: Walter: While useful for implementation per TR1, N1932 has no need for thisfeature. Recommend close as NAD.]
Rationale:
Recommend NAD,N1932,N2111covers this. Already in WP.
Section: 29.5.4[rand.eng], 99 [tr.rand.eng.sub1]Status:NAD EditorialSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.eng].
View all issues withNAD Editorial status.
Discussion:
Paragraph 6 says:
... obtained by successive invocations of g, ...
We recommend instead:
... obtained by taking successive invocations of g mod 2**32, ...
as the context seems to require only 32-bit quantities be used here.
Proposed resolution:
Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready.
[Portland: Subsumed by N2111.]
Section: 29.5.3[rand.req], 99 [tr.rand.req]Status:NADSubmitter: Walter BrownOpened: 2005-07-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req].
View all issues withNAD status.
Discussion:
The last two rows of Table 16 deal with the i/o requirements of an engine,specifying that the textual representation of an engine's state,appropriately formatted, constitute the engine's external representation.
This seems adequate when an engine's type is known. However, it seemsinadequate in the context of generic code, where it becomes useful andperhaps even necessary to determine an engine's type via input.
Proposed resolution:
We therefore recommend that, in each of these two rows of Table 16, thetext "textual representation" be expanded so as to read "engine namefollowed by the textual representation."
[Berlin: N1932 considers this NAD. This is a QOI issue.]
Section: 23.2.4[sequence.reqmts]Status:NADSubmitter: Chris JeffersonOpened: 2005-09-14Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD status.
Discussion:
Problem: There are a number of places in the C++ standard library whereit is possible to write what appear to be sensible ways of callingfunctions, but which can cause problems in some (or all)implementations, as they cause the values given to the function to bechanged in a way not specified in standard (and therefore not coded tocorrectly work). These fall into two similar categories.
1) Parameters taken by const reference can be changed during executionof the function
Examples:
Given std::vector<int> v:
v.insert(v.begin(), v[2]);
v[2] can be changed by moving elements of vector
Given std::list<int> l:
l.remove(*l.begin());
Will delete the first element, and then continue trying to access it.This is particularily vicious, as it will appear to work in almost allcases.
2) A range is given which changes during the execution of the function:Similarly,
v.insert(v.begin(), v.begin()+4, v.begin()+6);
This kind of problem has been partly covered in some cases. For examplestd::copy(first, last, result) states that result cannot be in the range[first, last). However, does this cover the case where result is areverse_iterator built from some iterator in the range [first, last)?Also, std::copy would still break if result was reverse_iterator(last +1), yet this is not forbidden by the standard
Solution:
One option would be to try to more carefully limit the requirements ofeach function. There are many functions which would have to be checked.However as has been shown in the std::copy case, this may be difficult.A simpler, more global option would be to somewhere insert text similar to:
If the execution of any function would change either any values passedby reference or any value in any range passed to a function in a way notdefined in the definition of that function, the result is undefined.
Such code would have to at least cover chapters 23 and 25 (the sectionsI read through carefully). I can see no harm on applying it to much ofthe rest of the standard.
Some existing parts of the standard could be improved to fit with this,for example the requires for 25.2.1 (Copy) could be adjusted to:
Requires: For each non-negative integer n < (last - first), assigning to*(result + n) must not alter any value in the range [first + n, last).
However, this may add excessive complication.
One other benefit of clearly introducing this text is that it wouldallow a number of small optimisations, such as caching values passedby const reference.
Matt Austern adds that this issue also exists for theinsert anderase members of the ordered and unordered associative containers.
[Berlin: Lots of controversey over how this should be solved. Lots of confusionas to whether we're talking about self referencing iterators or references.Needs a good survey as to the cases where this matters, for whichimplementations, and how expensive it is to fix each case.]
Proposed resolution:
Rationale:
Recommend NAD.
vector::insert(iter, value) is required to work because the standarddoesn't give permission for it not to work.list::remove(value) is required to work because the standarddoesn't give permission for it not to work.vector::insert(iter, iter, iter) is not required to work because23.2.4[sequence.reqmts], p4 says so.copy has to work, except where 26.7.1[alg.copy] saysit doesn't have to work. While a language lawyer can tear this wording apart,it is felt that the wording is not prone to accidental interpretation.const_iteratoriterator issue when they are the same typeSection: 23.5[unord], 99 [tr.unord.unord]Status:NADSubmitter: Paolo CarliniOpened: 2005-10-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [unord].
View all issues withNAD status.
Discussion:
while implementing the resolution of issue 6.19 I'm noticing thefollowing: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set andunordered_multiset:
"The iterator and const_iterator types are both const types. It isunspecified whether they are the same type"
Now, according to the resolution of 6.19, we have overloads of insertwith hint and erase (single and range) both for iterator andconst_iterator, which, AFAICS, can be meaningful at the same time *only*if iterator and const_iterator *are* in fact different types.
Then, iterator and const_iterator are *required* to be different types?Or that is an unintended consequence? Maybe the overloads for plainiterators should be added only to unordered_map and unordered_multimap?Or, of course, I'm missing something?
Proposed resolution:
Add to 6.3.4.3p2 (and 6.3.4.5p2):
2 ... The iterator and const_iterator types are bothconstconstant iterator types.It is unspecified whether they are the same type.
Add a new subsection to 17.4.4 [lib.conforming]:
An implementation shall not supply an overloaded function signature specified in any library clause if such a signature would be inherently ambiguous during overload resolution due to two library types referring to the same type.
[Note: For example, this occurs when a container's iterator and const_iterator types are the same. -- end note]
[Post-Berlin: Beman supplied wording.]
Rationale:
Toronto: The first issue has been fixed by N2350 (the insert and erase membersare collapsed into one signature). Alisdair to open a separate issue on thechapter 17 wording.
Section: 99 [res.on.required]Status:NAD EditorialSubmitter: David AbrahamsOpened: 2005-10-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
17.4.3.8/1 says:
Violation of the preconditions specified in a function's Required behavior: paragraph results in undefined behavior unless the function's Throws: paragraph specifies throwing an exception when the precondition is violated.
This implies that a precondition violation can lead to definedbehavior. That conflicts with the only reasonable definition ofprecondition: that a violation leads to undefined behavior. Any otherdefinition muddies the waters when it comes to analyzing programcorrectness, because precondition violations may be routinely done incorrect code (e.g. you can use std::vector::at with the fullexpectation that you'll get an exception when your index is out ofrange, catch the exception, and continue). Not only is it a badexample to set, but it encourages needless complication and redundancyin the standard. For example:
21 Strings library 21.3.3 basic_string capacity void resize(size_type n, charT c); 5 Requires: n <= max_size() 6 Throws: length_error if n > max_size(). 7 Effects: Alters the length of the string designated by *this as follows:
The Requires clause is entirely redundant and can be dropped. Wecould make that simplifying change (and many others like it) evenwithout changing 17.4.3.8/1; the wording there just seems to encouragethe redundant and error-prone Requires: clause.
[Batavia: Alan and Pete to work.]
[Bellevue: NAD Editorial, this group likesN2121,Pete agrees, accepting it is Pete's business.General agreement that precondition violations are synonymous with UB.]
Proposed resolution:
1. Change 17.4.3.8/1 to read:
Violation of the preconditions specified in a function'sRequired behavior: paragraph results in undefined behavior
unless the function'sThrows: paragraph specifies throwingan exception when the precondition is violated.
2. Go through and remove redundant Requires: clauses. Specifics to be provided by Dave A.
[Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.]
[Alan provided the surveyN2121.]
Section: 22.4.9[tuple.rel], 99 [tr.tuple.rel]Status:NADSubmitter: David AbrahamsOpened: 2005-11-29Last modified: 2025-10-16
Priority:Not Prioritized
View otheractive issues in [tuple.rel].
View all otherissues in [tuple.rel].
View all issues withNAD status.
Duplicate of:348
Discussion:
Where possible,tuple comparison operators <,<=,=>, and > ought to bedefined in terms ofstd::less rather thanoperator<, in order tosupport comparison of tuples of pointers.
[2009-07-28 Reopened by Alisdair. No longer solved by concepts.]
[2009-10 Santa Cruz:]
If we solve this for
tuplewe would have to solve it forpairalgorithms, etc. It is too late to do that at this time. Move to NAD Future.
[2025-10-16 Status changed: LEWG → NAD.]
Discussed by LEWG in Wrocław, unanimous consent to close as NAD, without prejudice.
Proposed resolution:
change 6.1.3.5/5 from:
Returns: The result of a lexicographical comparison between t and u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for some tuple r is a tuple containing all but the first element of r. For any two zero-length tuples e and f, e < f returns false.
to:
Returns: The result of a lexicographical comparison between t and u. For any two zero-length tuples e and f, e < f returns false. Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some tuple r is a tuple containing all but the first element of r, and cmp(x,y) is an unspecified function template defined as follows.
Where T is the type of x and U is the type of y:
if T and U are pointer types and T is convertible to U, returns less<U>()(x,y)
otherwise, if T and U are pointer types, returns less<T>()(x,y)
otherwise, returns (bool)(x < y)
[Berlin: This issue is much bigger than just tuple (pair, containers,algorithms). Dietmar will survey and work up proposed wording.]
Rationale:
Recommend NAD. This will be fixed with the next revision of concepts.
[San Francisco:]
Solved byN2770.
Section: 23.2[container.requirements]Status:DupSubmitter: Joaquín M López MuñozOpened: 2005-12-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withDup status.
Duplicate of:589
Discussion:
The iterator constructor X(i,j) for containers as defined in 23.1.1 and23.2.2 does only require that i and j be input iterators butnothing is said about their associated value_type. There are threesensibleoptions:
The issue has practical implications, and stdlib vendors havetaken divergent approaches to it: Dinkumware follows 2,libstdc++ follows 3.
The same problem applies to the definition of insert(p,i,j) forsequences and insert(i,j) for associative contianers, as well asassign.
[The following added by Howard and the example code was originally written byDietmar.]
Valid code below?
#include <vector> #include <iterator> #include <iostream> struct foo { explicit foo(int) {} }; int main() { std::vector<int> v_int; std::vector<foo> v_foo1(v_int.begin(), v_int.end()); std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), std::istream_iterator<int>()); }[Berlin: Some support, not universal, for respecting the explicit qualifier.]
Proposed resolution:
Section: C.8[diff.library]Status:NAD EditorialSubmitter: Martin SeborOpened: 2005-11-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [diff.library].
View all issues withNAD Editorial status.
Discussion:
According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>,<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>,or <cwchar>." This is consistent with the C standard.
However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>.
In addition, C.2, p2 claims that "The C++ Standard library provides54 standard macros from the C library, as shown in Table 95." Whiletable 95 does have 54 entries, since a couple of them (including theNULL macro) are listed more than once, the actual number of macrosdefined by the C++ Standard Library may not be 54.
Proposed resolution:
I propose we add <clocale> and <cstdlib> to Table 96 and remove thenumber of macros from C.2, p2 and reword the sentence as follows:
The C++ Standard library
provides 54 standard macros fromdefines a number macros corresponding to those defined by the CStandard library, as shown in Table 96.
[Portland: Resolution is considered editorial. It will be incorporated into the WD.]
Section: 5.1.1 [tr1::tr.rand.req]Status:NADSubmitter: Matt AusternOpened: 2006-01-10Last modified: 2016-10-31
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].The rest of the TR should use that type. I believe this affects two places.First, the random number requirements, 5.1.1/10-11, lists all of the types withwhich template parameters named IntType and UIntType may be instantiated._Longlong (or "long long", assuming it is added to C++0x) should be added to theIntType list, and UIntType (again, or "unsigned long long") should be added tothe UIntType list. Second, 6.3.2 lists the types for which hash<> isrequired to be instantiable. _Longlong and _Ulonglong should be added to thatlist, so that people may use long long as a hash key.
[2009-07 Frankfurt]
We are not going to fix TR1.
The paper "long long goes to the library" addresses the integration oflong long into the C++0x library.
Move to NAD.
Proposed resolution:
Section: 29.5[rand], 99 [tr.rand]Status:NADSubmitter: Matt AusternOpened: 2006-01-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand].
View all issues withNAD status.
Discussion:
Paragraph 10 describes how a variate generator uses numbers produced by anengine to pass to a generator. The sentence that concerns me is: "Otherwise, ifthe value for engine_value_type::result_type is true and the value forDistribution::input_type is false [i.e. if the engine produces integers and theengine wants floating-point values], then the numbers in s_eng are divided byengine().max() - engine().min() + 1 to obtain the numbers in s_e." Since theengine is producing integers, both the numerator and the denominator areintegers and we'll be doing integer division, which I don't think is what wewant. Shouldn't we be performing a conversion to a floating-point type first?
Proposed resolution:
Rationale:
Recommend NAD as the affected section is now gone and so the issue is moot.N2111.
Section: 29.5.7[rand.device], 99 [tr.rand.device]Status:NADSubmitter: Matt AusternOpened: 2006-01-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.device].
View all issues withNAD status.
Discussion:
Class random_device "produces non-deterministic random numbers", using someexternal source of entropy. In most real-world systems, the amount of availableentropy is limited. Suppose that entropy has been exhausted. What is animplementation permitted to do? In particular, is it permitted to blockindefinitely until more random bits are available, or is the implementationrequired to detect failure immediately? This is not an academic question. OnLinux a straightforward implementation would read from /dev/random, and "Whenthe entropy pool is empty, reads to /dev/random will block until additionalenvironmental noise is gathered." Programmers need to know whether random_deviceis permitted to (or possibly even required to?) behave the same way.
[Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cinmay block?]
SeeN2391 andN2423for some further discussion.
Proposed resolution:
Adopt the proposed resolution inN2423 (NAD).
Section: 29.5.9[rand.dist], 99 [tr.rand.dist.bin]Status:NAD EditorialSubmitter: Matt AusternOpened: 2006-01-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist].
View all issues withNAD Editorial status.
Discussion:
Paragraph 1 says that "A binomial distributon random distribution producesinteger values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t andp are the parameters of the distribution. OK, that tells us what t, p, and iare. What's n?
Proposed resolution:
Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
[Portland: Subsumed by N2111.]
intptr_t /uintptr_tSection: 17.4.1[cstdint.syn], 99 [tr.c99.cstdint.syn]Status:NAD EditorialSubmitter: Paolo CarliniOpened: 2006-01-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [cstdint.syn].
View all issues withNAD Editorial status.
Discussion:
In the synopsis, some types are identified as optional:int8_t,int16_t,and so on, consistently with C99, indeed.
On the other hand,intptr_t anduintptr_t, are not marked as such andprobably should, consistently with C99, 7.18.1.4.
Proposed resolution:
Change 17.4.1[cstdint.syn]:
...typedefsigned integer type intptr_t;// optional...typedefunsigned integer type uintptr_t;// optional...
Rationale:
Recommend NAD and fix as editorial with the proposed resolution.
Section: 17.3.5.3[numeric.special]Status:NADSubmitter: Howard HinnantOpened: 2006-01-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numeric.special].
View all issues withNAD status.
Discussion:
I believe we have a bug in the resolution of:184(i)(WP status).
The resolution spells out each member ofnumeric_limits<bool>.The part I'm having a little trouble with is:
static const bool traps = false;
Should this not be implementation defined? Given:
int main(){ bool b1 = true; bool b2 = false; bool b3 = b1/b2;}If this causes a trap, shouldn'tnumeric_limits<bool>::traps betrue?
Proposed resolution:
Change 18.2.1.5p3:
-3- The specialization for
boolshall be provided as follows:namespace std { template <> class numeric_limits<bool> { ... static const bool traps =falseimplementation-defined; ... };}
[Redmond: NAD because traps refers to values, not operations. There is no boolvalue that will trap.]
Section: 8.21 [tr1::tr.c99.boolh]Status:NAD EditorialSubmitter: Paolo CarliniOpened: 2006-02-02Last modified: 2016-10-31
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
This one, if nobody noticed it yet, seems really editorial:s/cstbool/cstdbool/
Proposed resolution:
Change 8.21p1:
-1- The header behaves as if it defines the additional macro defined in
<cstdbool>by including the header<cstdbool>.
[Redmond: Editorial.]
Section: 17.4.1[cstdint.syn], 99 [tr.c99.cstdint]Status:NAD EditorialSubmitter: Paolo CarliniOpened: 2006-02-06Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [cstdint.syn].
View all issues withNAD Editorial status.
Discussion:
I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==long long we end up, essentially, with the same arguments and differentreturn types (lldiv_t and imaxdiv_t, respectively). Similar issue withabs(_Longlong) and abs(intmax_t), of course.
Comparing sections 8.25 and 8.11, I see an important difference,however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlongtypes (rightfully, because not moved over directly from C99), whereasthere is no equivalent in 8.11: the abs and div overloads for intmax_ttypes appear only in the synopsis and are not described anywhere, inparticular no mention in 8.11.2 (at variance with 8.25.2).
I'm wondering whether we really, really, want div and abs for intmax_t...
Proposed resolution:
[Portland: no consensus.]
Rationale:
[Batavia, Bill: The<cstdint> synopsis in [tr.c99.cinttypes.syn] contains:]
intmax_t imaxabs(intmax_t i);intmax_t abs(intmax_t i);imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);imaxdiv_t div(intmax_t numer, intmax_t denom);
[and in [tr.c99.cinttypes.def]:]
The header defines all functions, types, and macros the same as C99subclause 7.8.
[This is as much definition as we give for most other C99 functions,so nothing need change. We might, however, choose to add the footnote:]
[Note: These overloads for
absanddivmay well be equivalent tothose that takelong longarguments. If so, the implementation isresponsible for avoiding conflicting declarations. --end note]
[Bellevue: NAD Editorial. Pete must add a footnote, as described below.]
[Looks like a real problem. Dietmar suggests div() return a templatetype. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedeffor lldiv_t when _Longlong == intmax_t? PJP seems to agree. We wouldneed a non-normative note declaring that the types lldiv_t and imaxdiv_tmay not be unique if intmax_t==_longlong.]
Section: 24.3.5.3[input.iterators]Status:NAD EditorialSubmitter: David AbrahamsOpened: 2006-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [input.iterators].
View all otherissues in [input.iterators].
View all issues withNAD Editorial status.
Discussion:
24.1.1 Input iterators [lib.input.iterators]
1 A class or a built-in type X satisfies the requirements of an input iterator for the value type T if the following expressions are valid, where U is the type of any specified member of type T, as shown in Table 73.
There is no capital U used in table 73. There is a lowercase u, butthat is clearly not meant to denote a member of type T. Also, there'sno description in 24.1.1 of what lowercase a means. IMO the aboveshould have been...Hah, a and b are already covered in 24.1/11, so maybe itshould have just been:
Proposed resolution:
Change 24.1.1p1:
-1- A class or a built-in type
Xsatisfies the requirements of aninput iterator for the value typeTif the following expressions are valid, whereas shown in Table 73.Uis the type of any specified member of typeT,
[Portland: Editorial.]
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: Sergey P. DerevyagoOpened: 2006-02-17Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
User-defined allocators without default constructor are not explicitlysupported by the standard but they can be supported just like std::vectorsupports elements without default constructor.
As a result, there exist implementations that work well with such allocatorsand implementations that don't.
1) The standard doesn't explicitly state this intent but it should. Inparticular, 20.1.5p5 explicitly state the intent w.r.t. the allocatorinstances that compare non-equal. So it can similarly state the intent w.r.t.the user-defined allocators without default constructor.
2) Some container operations are obviously underspecified. In particular,21.3.7.1p2 tells:
template<class charT, class traits, class Allocator> basic_string<charT,traits,Allocator> operator+( const charT* lhs, const basic_string<charT,traits,Allocator>& rhs );Returns:
basic_string<charT,traits,Allocator>(lhs) + rhs.
That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call.Obviously, the right requirement is:
Returns:
basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs.
It seems like a lot of DRs can be submitted on this "Absent call toget_allocator()" topic.
1) Explicitly state the intent to allow for user-defined allocators withoutdefault constructor in 20.1.5 Allocator requirements.
2) Correct all the places, where a correct allocator object is availablethrough the get_allocator() call but default Allocator() gets passed instead.
Let's suppose that the following memory pool is available:
class mem_pool { // ... void* allocate(size_t size); void deallocate(void* ptr, size_t size);};So the following allocator can be implemented via this pool:
class stl_allocator { mem_pool& pool; public: explicit stl_allocator(mem_pool& mp) : pool(mp) {} stl_allocator(const stl_allocator& sa) : pool(sa.pool) {} template <class U> stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {} ~stl_allocator() {} pointer allocate(size_type n, std::allocator<void>::const_pointer = 0) { return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0; } void deallocate(pointer p, size_type n) { if (n!=0) pool.deallocate(p, n*sizeof(T)); } // ...};Then the following code works well on some implementations and doesn't work onanother:
typedef basic_string<char, char_traits<char>, stl_allocator<char> > tl_string;mem_pool mp;tl_string s1("abc", stl_allocator<int>(mp));printf("(%s)\n", ("def"+s1).c_str());In particular, on some implementations the code can't be compiled withoutdefault stl_allocator() constructor.
The obvious way to solve the compile-time problems is to intentionally definea NULL pointer dereferencing default constructor
stl_allocator() : pool(*static_cast<mem_pool*>(0)) {}in a hope that it will not be called. The problem is that it really getscalled by operator+(const char*, const string&) under the current 21.3.7.1p2wording.
Proposed resolution:
Rationale:
Recommend NAD.operator+() withstring already requires the desiredsemantics of copying the allocator from one of the strings (lhs when there is a choice).
log2 overloads missingSection: 8.16.4 [tr1::tr.c99.cmath.over]Status:NADSubmitter: Paolo CarliniOpened: 2006-03-07Last modified: 2016-02-01
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
log2 is missing from the list of "additional overloads" in 8.16.4 [tr1::tr.c99.cmath.over] p1.
Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
[Batavia (2009-05):]
We agree this has been fixed in the Working Draft.Move to NAD.
Proposed resolution:
Addlog2 to the list of functions in 8.16.4 [tr1::tr.c99.cmath.over] p1.
Section: 31.5.4.4[iostate.flags]Status:DupSubmitter: Seungbeom KimOpened: 2006-03-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iostate.flags].
View all issues withDup status.
Duplicate of:272
Discussion:
Section: 27.4.4.3 [lib.iostate.flags]
Paragraph 4 says:
void clear(iostatestate = goodbit);Postcondition: If
rdbuf()!=0thenstate == rdstate();otherwiserdstate()==state|ios_base::badbit.
The postcondition "rdstate()==state|ios_base::badbit" is parsed as"(rdstate()==state)|ios_base::badbit", which is probably what thecommittee meant.
Rationale:
char_traitsSection: 27.2[char.traits]Status:NADSubmitter: Jack ReevesOpened: 2006-04-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [char.traits].
View all issues withNAD status.
Discussion:
Currently, the Standard Library specifies only a declaration for template classchar_traits<> and requires the implementation provide two explicitspecializations:char_traits<char> andchar_traits<wchar_t>. I feel the Standard should require explicit specializations for all built-in character types, i.e.char,wchar_t,unsigned char, andsigned char.
I have put together a paper(N1985)that describes this in more detail andincludes all the necessary wording.
[Portland: Jack will rewriteN1985to propose a primary template that will work with other integral types.]
[Toronto: issue has grown with addition ofchar16_t andchar32_t.]
[post Bellevue:]
We suggest that Jack be asked about the status of his paper, and if itis not forthcoming, the work-item be assigned to someone else. If no onesteps forward to do the paper before the next meeting, we propose tomake this NAD without further discussion. We leave this Open for now,but our recommendation is NAD.
Note: the issue statement should be updated, as the Toronto comment hasalready been resolved. E.g., char_traits specializations for
char16_tandchar32_tare now in the working paper.
[Sophia Antipolis:]
Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
Proposed resolution:
Section: 2[intro.refs]Status:NAD EditorialSubmitter: Beman DawesOpened: 2006-04-08Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [intro.refs].
View all issues withNAD Editorial status.
Discussion:
1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC9899:1990, Programming languages - C. Should that be changed to ISO/IEC9899:1999?
What impact does this have on the library?
Proposed resolution:
In 1.2/1 [intro.refs] of the WP, change:
- ISO/IEC 9899:
19901999 + TC1 + TC2,Programming languages - C
Rationale:
Recommend NAD, fixed editorially.
Section: 29.5[rand], 99 [tr.rand]Status:NADSubmitter: Howard HinnantOpened: 2006-04-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand].
View all issues withNAD status.
Discussion:
In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:variate_generator has been eliminated. Then in full committee we voted to givethis issue WP status (mistakenly).
Proposed resolution:
Strike the proposed resolution of issue 507.
[post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longerexists in the current WD.]
Rationale:
NAD. Will be moot onceN2135is adopted.
Section: 31.5.3[fpos]Status:NADSubmitter: Beman DawesOpened: 2006-04-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [fpos].
View all issues withNAD status.
Discussion:
There are two deficiencies related to file sizes:
std::fpos class does not currently have the ability to set/get file positions.The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
fpos_t belong long, which is large enough to represent any file position likely in the foreseeable future.fpos. For example,fpos_t seekpos() const;
Because there are so many types relating to file positions and offsets (fpos_t,fpos,pos_type,off_type,streamoff,streamsize,streampos,wstreampos, and perhaps more), it is difficult to know if the Dinkumware extensions are sufficient. But they seem a useful starting place for discussions, and they do represent existing practice.
[Kona (2007): We need a paper. It would be nice if someone proposedclarifications to the definitions ofpos_type andoff_type. Currentlythese definitions are horrible. Proposed Disposition: Open]
[2009-07 Frankfurt]
This is the subject of paper N2926.
If we choose to take any action, we will move the paper, so the issue can be closed.
Move to NAD.
Proposed resolution:
erase(iterator) for unordered containers should not return an iteratorSection: 23.2.8[unord.req]Status:NADSubmitter: Joaquín M López MuñozOpened: 2006-06-13Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
Addresses ES-2
SeeN2023for full discussion.
[2009-12-11 Paolo opens:]
I'm asking for DR 579 to be re-opened, basing on recent discussions on thelibrary reflector, see Message c++std-lib-26040 and replies.
[2010-02-07 Paolo updates wording.]
As pointed out by Chris in c++std-lib-26040, that an
erase(unordered_container, iterator)returning aniteratorcaneasily implemented in user code, if needed; that actually returning aniteratorcosts nothing for the overload taking twoiterators,thus that proposed change is only for consistency; thatforward_list::erase_afteralso returnsvoid(for differentreasons, granted, but isn't that any "erase" function in the containersuniformly returns aniterator); that, also in thread started by Chris'message, Alberto pointed out that the proxy idea isn't a good one; that usersboth of the GNU and Boost implementations are reporting serious performanceproblems with the current version returning aniterator.
[2010-02-07 Original wording saved here:]
Option 1:
The problem can be eliminated by omitting the requirement that
a.erase(q)return an iterator. This is, however, in contrast with the equivalent requirements for other standard containers.Option 2:
a.erase(q)can be made to compute the next iterator only when explicitly requested: the technique consists in returning a proxy object implicitly convertible toiterator, so thatiterator q1=a.erase(q);works as expected, while
a.erase(q);does not ever invoke the conversion-to-iterator operator, thus avoiding the associated computation. To allow this technique, some sections of TR1 along the line "return value is an iterator..." should be changed to "return value is an unspecified object implicitly convertible to an iterator..." Although this trick is expected to work transparently, it can have some collateral effects when the expression
a.erase(q)is used inside generic code.
[2010-03-27 Joaquín adds:]
Signature of
iterator erase(const_iterator)should be changed tovoiderase(const_iterator). If this is not viable an acceptable tradeoffcould be to make the return type oferase(const_iterator)implementation defined.The standard should allow implementations of unordered associativecontainers using either singly or doubly linked lists.N2023proves that singly-linked lists implementations cannot provide the requiredcomplexity for
iterator erase(const_iterator). Thus, some action isneeded to allow both implementations.Option 1: Changing the required complexity from O(1) to O(log n). This optionmerely masks a design flaw. Users are forcefully penalized for what they don'tuse (the returned iterator). Besides, they would have to learn about thepathological (yet very real) situations where using
erasecan lead toquadratic performance. Two out of these three objections remain even if somealternative member function likevoid quick_erase(const_iterator)isthrown in to the interface.Some objections have been expressed to changing return type of
erasetovoid, arguing that it would break current existing practice withstandard library implementations based on doubly-linked lists, where the problemdoes not occur. However implementations based on drafts should not block theresolution of a serious design issue, more so when the issue will hurt futureusers of C++, as it's happening already.Option 2: Make
erasereturn typeimplementation defined. There'sa possible tradeoff with the objectors above consisting in changing thesignature toimplementation definederase(iterator), so thatreturning an iterator is indeed a valid extension. To this it can be argued thatthis would make implementantions returning an iterator look as somehow promotingproprietary extensions: this in my opinion is not a valid argument since thoseimplementations arealready extending the required interface byproviding bidirectional iterators (just forward iterators are required).
[2010 Rapperswil:]
The issue was lengthy discussed and implementation experience was demonstrated that a non-void returntype is implementable for both single-linked and double-linked lists without loss of efficiency.
By a 12-1-1-0 poll voted to keep the return type of erase as
iteratorinstead ofvoidand a second 0-0-3-10 poll rejected the additional proposal to add aquick_erasereturningvoid, thus LWG decided for NAD.
Rationale:
No consensus for a change.
Proposed resolution:
Section: 23.2.2[container.requirements.general]Status:NAD EditorialSubmitter: Martin SeborOpened: 2006-06-14Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [container.requirements.general].
View all otherissues in [container.requirements.general].
View all issues withNAD Editorial status.
Duplicate of:479
Discussion:
C++ Standard Library templates that take an allocator as an argumentare required to call theallocate() anddeallocate() members of the allocator object to obtainstorage. However, they do not appear to be required to call any otherallocator members such asconstruct(),destroy(),address(), andmax_size(). This makes these allocator members less thanuseful in portable programs.
It's unclear to me whether the absence of the requirement to use theseallocator members is an unintentional omission or a deliberatechoice. However, since the functions exist in the standard allocatorand since they are required to be provided by any user-definedallocator I believe the standard ought to be clarified to explictlyspecify whether programs should or should not be able to rely onstandard containers calling the functions.
I propose that all containers be required to make use of thesefunctions.
[Batavia: We support this resolution. Martin to provide wording.]
[pre-Oxford: Martin provided wording.]
[2009-04-28 Pablo adds:]
N2554(scoped allocators),N2768(allocator concepts), andN2810(allocator defects), address all of these points EXCEPT
max_size().So, I would add a note to that affect and re-class the defect as belongingto section 23.2.2[container.requirements.general].
[2009-07 Frankfurt]
The comment in the description of this issue that this "would be"rendered editorial by the adoption of N2257 is confusing. It appearsthat N2257 was never adopted.
[2009-10 Santa Cruz:]
NAD Editorial. Addressed byN2982.
Proposed resolution:
Specifically, I propose to change 23.2[container.requirements],p9 as follows:
-9- Copy constructors for all container types defined in this clausethat are parametrized on
Allocatorcopyanthe allocator argument from their respectivefirst parameters.All other constructors for these container types take anconstAllocator&argument (20.1.6), anallocator whosevalue_typeis the same as the container'svalue_type.A copy of this argumentisshall be used for anymemory allocation and deallocation performed,by these constructors and by all member functions,duringthe lifetime of each container object.Allocation shall beperformed "as if" by calling theallocate()memberfunction on a copy of the allocator object of the appropriate typeNew Footnote), and deallocation "as if" by callingdeallocate()on a copy of the same allocator object ofthe corresponding type.A copy of this argument shall also be used to construct anddestroy objects whose lifetime is managed by the container, includingbut not limited to those of the container'svalue_type,and to obtain their address. All objects residing in storageallocated by a container's allocator shall be constructed "as if" bycalling theconstruct()member function on a copy of theallocator object of the appropriate type. The same objects shall bedestroyed "as if" by callingdestroy()on a copy of thesame allocator object of the same type. The address of such objectsshall be obtained "as if" by calling theaddress()memberfunction on a copy of the allocator object of the appropriatetype.Finally, a copy of this argument shall be used by its containerobject to determine the maximum number of objects of the container'svalue_typethe container may store at the same time. Thecontainer member functionmax_size()obtains this numberfrom the value returned by a call toget_allocator().max_size().In all container types defined in this clausethat areparametrized onAllocator, the memberget_allocator()returns a copy of theAllocatorobject used to construct thecontainer.258)New Footnote: This type may be different from
Allocator:it may be derived fromAllocatorviaAllocator::rebind<U>::otherfor the appropriatetypeU.
The proposed wording seems cumbersome but I couldn't think of a betterway to describe the requirement that containers use theirAllocator to manage only objects (regardless of theirtype) that persist over their lifetimes and not, for example,temporaries created on the stack. That is, containers shouldn't berequired to callAllocator::construct(Allocator::allocate(1),elem) just to construct a temporary copy of an element, orAllocator::destroy(Allocator::address(temp), 1) todestroy temporaries.
[Howard: This same paragraph will need some work to accommodate431(i).]
[post Oxford: This would be rendered NAD Editorial by acceptance ofN2257.]
Section: 26.11.5[uninitialized.copy]Status:NADSubmitter: Martin SeborOpened: 2006-06-14Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [uninitialized.copy].
View all issues withNAD status.
Discussion:
The specialized algorithms [lib.specialized.algorithms] are specifiedas having the general effect of invoking the following expression:
new (static_cast<void*>(&*i)) typename iterator_traits<ForwardIterator>::value_type (x)
This expression is ill-formed when the type of the subexpression&*i is some volatile-qualifiedT.
[Batavia: Lack of support for proposed resolution but agree there is adefect. Howard to look at wording. Concern that move semanticsproperly expressed if iterator returns rvalue.]
[2009-06-17 Pablo adds:]
Propose that Issue582(i) be closed NAD.
Issue582(i) asks that
uninitialized_copy,uninitialized_fill, anduninitialized_fill_nshould bewell-formed if the result type is volatile. My feeling is that thestandard does not, and should not, guarantee any useful behavior whenconstructors are invoked on volatile storage, so making it syntacticallylegal to calluninitialized_copyon volatile storage is not useful. Apossible editorial change would be to put my previous sentence into anon-normative note.Note that the three sections starting with 26.11.5[uninitialized.copy] do notyet have concepts. Here's a first crack at the first one:
template <InputIterator InIter, OutputIterator OutIter>requires ExplicitConvertible<HasDereference<OutIter::reference>::result, OutIter::value_type&> && Convertible<OutIter::value_type*, void*> && ExplicitConvertible<OutIter::value_type, InIter::reference> OutIter uninitialized_copy(InIter first, InIter last, OutIter result);Effects:
while (first != last) { typedef OutIter::value_type value_type; value_type& outRef = static_cast<value_type&>(*result++); ::new (static_cast<void*>(addressof(outRef))) value_type(*first++);}Notes:
- This definition is actually LESS constrained than in C++03 becausethere is no requirement that the result be a forward iterator.
- IfOutIter returns a proxy type with an overloaded operator&, thisdefinition probably won't compile. Lifting this limitation whileallowing value_type to have an overloaded operator& would be hard, butis probably possible with careful overloading. I'm not sure it's worthit.
- This definition retains the prohibition on the use of volatile types for the result.
[2009-07 Frankfurt]
We don't deal with volatile in the library.
Jim: should we state that explicitly somewhere?
Beman: you might argue that clause 17 should say something aboutvolatile. However, if you want to raise we argument, we should open itas a separate issue and consult with experts on concurrency.
Hinnant: actually, some library components do handle volatile, so we'dneed to be very careful about what we say in clause 17.
No objection to NAD.
Move to NAD.
Proposed resolution:
In order to allow these algorithms to operate on volatile storage Ipropose to change the expression so as to make it well-formed even forpointers to volatile types. Specifically, I propose the followingchanges to clauses 20 and 24. Change 20.6.4.1, p1 to read:
Effects:typedef typename iterator_traits<ForwardIterator>::pointer pointer;typedef typename iterator_traits<ForwardIterator>::value_type value_type;for (; first != last; ++result, ++first) new (static_cast<void*>(const_cast<pointer>(&*result)) value_type (*first);
change 20.6.4.2, p1 to read
Effects:typedef typename iterator_traits<ForwardIterator>::pointer pointer;typedef typename iterator_traits<ForwardIterator>::value_type value_type;for (; first != last; ++result, ++first) new (static_cast<void*>(const_cast<pointer>(&*first)) value_type (*x);
and change 20.6.4.3, p1 to read
Effects:typedef typename iterator_traits<ForwardIterator>::pointer pointer;typedef typename iterator_traits<ForwardIterator>::value_type value_type;for (; n--; ++first) new (static_cast<void*>(const_cast<pointer>(&*first)) value_type (*x);
In addition, since there is no partial specialization foriterator_traits<volatile T*> I propose to add oneto parallel such specialization for <const T*>. Specifically, Ipropose to add the following text to the end of 24.3.1, p3:
and for pointers to volatile as
namespace std {template<class T> struct iterator_traits<volatile T*> {typedef ptrdiff_t difference_type;typedef T value_type;typedef volatile T* pointer;typedef volatile T& reference;typedef random_access_iterator_tag iterator_category;};}Note that the change toiterator_traits isn't necessaryin order to implement the specialized algorithms in a way that allowsthem to operate on volatile strorage. It is only necesassary in orderto specify their effects in terms ofiterator_traits asis done here. Implementations can (and some do) achieve the sameeffect by means of function template overloading.
div() for unsigned integral typesSection: 29.7[c.math]Status:NADSubmitter: Beman DawesOpened: 2006-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
There is nodiv() function for unsigned integer types.
There are several possible resolutions. The simplest one is noted below. Otherpossibilities include a templated solution.
Proposed resolution:
Add to 26.7 [lib.c.math] paragraph 8:
struct udiv_t div(unsigned, unsigned);struct uldiv_t div(unsigned long, unsigned long);struct ulldiv_t div(unsigned long long, unsigned long long);
Rationale:
Toronto: C99 does not have these unsigned versions becausethe signed version exist just to define the implementation-defined behaviorof signed integer division. Unsigned integer division has no implementation-definedbehavior and thus does not need this treatment.
pow(int,int) functionalitySection: 29.7[c.math]Status:NADSubmitter: Beman DawesOpened: 2006-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
There is nopow() function for any integral type.
Proposed resolution:
Add something like:
template< typename T>T power( T x, int n );// requires: n >=0
Rationale:
Toronto: We already havedouble pow(integral,integral) from 29.7[c.math] p11.
Section: 28.3.4[locale.categories]Status:NADSubmitter: Martin Sebor, Paolo CarliniOpened: 2006-06-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.categories].
View all issues withNAD status.
Discussion:
Section 22.2, paragraph 2 requires facetget() membersthat take anios_base::iostate& argument,err, to ignore the (initial) value of theargument, but to set it toios_base::failbit in case of aparse error.
We believe there are a few minor problems with this blanketrequirement in conjunction with the wording specific to eachget() member function.
First, besidesget() there are other member functionswith a slightly different name (for example,get_date()). It's not completely clear that the intent ofthe paragraph is to include those as well, and at least oneimplementation has interpreted the requirement literally.
Second, the requirement to "set the argument toios_base::failbit suggests that the functions are notpermitted to set it to any other value (such asios_base::eofbit, or evenios_base::eofbit |ios_base::failbit).
However, 22.2.2.1.2, p5 (Stage 3 ofnum_get parsing) andp6 (bool parsing) specifies that thedo_getfunctions performerr |= ios_base::eofbit, whichcontradicts the earlier requirement to ignoreerr's initialvalue.
22.2.6.1.2, p1 (the Effects clause of themoney_getfacet'sdo_get member functions) also specifies thaterr's initial value be used to compute the finalvalue by ORing it with eitherios_base::failbit orwithios_base::eofbit | ios_base::failbit.
[2009-07 Frankfurt]
Move to NAD.
Proposed resolution:
We believe the intent is for all facet member functions that take anios_base::iostate& argument to:
err argument,err toios_base::goodbit priorto any further processing,ios_base::eofbit, orios_base::failbit, or both inerr, asappropriate, in response to reaching the end-of-file or on parseerror, or both.To that effect we propose to change 22.2, p2 as follows:
Theput() members make no provision for errorreporting. (Any failures of the OutputIterator argument must beextracted from the returned iterator.)Unless otherwisespecified,theget() membersthattake anios_base::iostate& argumentwhose valuethey ignore, but set to ios_base::failbit in case of a parseerror.,err, start by evaluatingerr = ios_base::goodbit, and may subsequently seterr to eitherios_base::eofbit, orios_base::failbit, orios_base::eofbit |ios_base::failbit in response to reaching the end-of-file or incase of a parse error, or both, respectively.
[Kona (2007): We need to change the proposed wording to clarify that thephrase "the get members" actually denotesget(),get_date(), etc.Proposed Disposition: Open]
Section: 99 [depr.istrstream.cons]Status:NAD EditorialSubmitter: Martin SeborOpened: 2006-06-22Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Theiststream(char*, streamsize) ctor is in the classsynopsis in D.7.2 but its signature is missing in the descriptionbelow (in D.7.2.1).
Proposed resolution:
This seems like a simple editorial issue and the missing signature canbe added to the one forconst char* in paragraph 2.
[post Oxford: Noted that it is already fixed inN2284]
tr1::arrays and other detailsSection: 23.3.3[array]Status:NADSubmitter: Gennaro ProtaOpened: 2006-07-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [array].
View all issues withNAD status.
Discussion:
The wording used for section 23.2.1 [lib.array] seems to be subtlyambiguous about zero sized arrays (N==0). Specifically:
* "An instance of array<T, N> stores N elements of type T, so that[...]"
Does this imply that a zero sized array object stores 0 elements, i.e.that it cannot store any element of type T? The next point clarifiesthe rationale behind this question, basically how to implement begin()and end():
* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==end() == unique value."
What does "unique" mean in this context? Let's consider the followingpossible implementations, all relying on a partial specialization:
a) template< typename T > class array< T, 0 > { .... iterator begin() { return iterator( reinterpret_cast< T * >( this ) ); } .... };This has been used in boost, probably intending that the return valuehad to be unique to the specific array object and that array couldn'tstore any T. Note that, besides relying on a reinterpret_cast, has(more than potential) alignment problems.
b) template< typename T > class array< T, 0 > { T t; iterator begin() { return iterator( &t ); } .... };This provides a value which is unique to the object and to the type ofthe array, but requires storing a T. Also, it would allow the user tomistakenly provide an initializer list with one element.
A slight variant could be returning *the* null pointer of type T
return static_cast<T*>(0);
In this case the value would be unique to the type array<T, 0> but notto the objects (all objects of type array<T, 0> with the same valuefor T would yield the same pointer value).
Furthermore this is inconsistent with what the standard requires fromallocation functions (see library issue 9).
c) same as above but with t being a static data member; again, thevalue would be unique to the type, not to the object.
d) to avoid storing a T *directly* while disallowing the possibilityto use a one-element initializer list a non-aggregate nested classcould be defined
struct holder { holder() {} T t; } h;and then begin be defined as
iterator begin() { return &h.t; }But then, it's arguable whether the array stores a T or not.Indirectly it does.
-----------------------------------------------------
Now, on different issues:
* what's the effect of calling assign(T&) on a zero-sized array? Thereseems to be only mention of front() and back(), in 23.2.1 [lib.array]p4 (I would also suggest to move that bullet to section 23.2.1.5[lib.array.zero], for locality of reference)
* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bitinconsistent with that of other sequences: that's not a problem initself, but compare it for instance with "A vector is a kind ofsequence that supports random access iterators"; though the intent isobvious one might argue that the wording used for arrays doesn't tellwhat an array is, and relies on the reader to infer that it is whatthe <array> header defines.
* it would be desiderable to have a static const data member of typestd::size_t, with value N, for usage as integral constant expression
* section 23.1 [lib.container.requirements] seem not to considerfixed-size containers at all, as it says: "[containers] controlallocation and deallocation of these objects [the contained objects]through constructors, destructors, *insert and erase* operations"
* max_size() isn't specified: the result is obvious but, technically,it relies on table 80: "size() of the largest possible container"which, again, doesn't seem to consider fixed size containers
[2009-05-29 Daniel adds:]
star bullet 1 ("what's the effect of calling
assign(T&)on azero-sized array?[..]");
assignhas been renamed tofilland the semantic offillis nowdefined in terms ofthe free algorithmfill_n, which is well-defined for this situation.star bullet 3 ("it would be desiderable to have a static const datamember..."):
It seems that
tuple_size<array<T, N> >::valueas of 23.3.3.7[array.tuple] doesprovide this functionality now.
[2009-07 Frankfurt]
Alisdair to address by the next meeting, or declare NAD.
Moved to Tentatively NAD.
[2009 Santa Cruz:]
Moved to NAD.
Proposed resolution:
[Kona (2007): requirements on zero sizedtr1::arrays and other detailsIssue 617:std::array is a sequence that doesn't satisfy the sequencerequirements? Alisdair will prepare a paper. Proposed Disposition: Open]
Section: 21[meta], 99 [tr.meta.req]Status:NAD EditorialSubmitter: Beman DawesOpened: 2006-08-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta].
View all otherissues in [meta].
View all issues withNAD Editorial status.
Discussion:
20.4.9 [lib.meta.req], Implementation requirements, provides latitude for typetraits implementers that is not needed in C++0x. It includes the wording:
[Note: the latitude granted to implementers in this clause is temporary,and is expected to be removed in future revisions of this document. --end note]
Note:N2157: Minor Modifications to the type traits Wordingalso has the intent of removing this wording from the WP.
Proposed resolution:
Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
[post-Oxford: Recommend NAD Editorial. This resolution is now in thecurrent working draft.]
Section: 17.3.5.2[numeric.limits.members]Status:NAD EditorialSubmitter: whyglinuxOpened: 2006-08-08Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numeric.limits.members].
View all issues withNAD Editorial status.
Discussion:
18.2.1.2 numeric_limits members [lib.numeric.limits.members]Paragraph 7:
"For built-in integer types, the number of non-sign bits in therepresentation."
26.1 Numeric type requirements [lib.numeric.requirements]Footnote:
"In other words, value types. These include built-in arithmetic types,pointers, the library class complex, and instantiations of valarray forvalue types."
Integer types (which are bool, char, wchar_t, and the signed andunsigned integer types) and arithmetic types (which are integer andfloating types) are all built-in types and thus there are nonon-built-in (that is, user-defined) integer or arithmetic types. Sincethe redundant "built-in" in the above 2 sentences can mislead thatthere may be built-in or user-defined integer and arithmetic types(which is not correct), the "built-in" should be removed.
Proposed resolution:
18.2.1.2 numeric_limits members [lib.numeric.limits.members]Paragraph 7:
"For
built-ininteger types, the number of non-sign bits in therepresentation."
26.1 Numeric type requirements [lib.numeric.requirements]Footnote:
"In other words, value types. These include
built-inarithmetic types,pointers, the library class complex, and instantiations of valarray forvalue types."
Rationale:
Recommend NAD / Editorial. The proposed resolution is accepted as editorial.
Section: 31.10.4.4[ifstream.members]Status:NAD EditorialSubmitter: Christopher KohlhoffOpened: 2006-08-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ifstream.members].
View all issues withNAD Editorial status.
Discussion:
I just spotted a minor problem in 27.8.1.7[lib.ifstream.members] para 4 and also 27.8.1.13[lib.fstream.members] para 4. In both places it says:
void close();Effects: Calls rdbuf()->close() and, if that function returns false, ...
However, basic_filebuf::close() (27.8.1.2) returns a pointer to thefilebuf on success, null on failure, so I think it is meant tosay "if that function returns a null pointer". Oddly, it iscorrect for basic_ofstream.
Proposed resolution:
Change 31.10.4.4[ifstream.members], p5:
Effects: Calls
rdbuf()->close()and, if that functionfails (returnsa null pointer),callsfalsesetstate(failbit)(which may throwios_base::failure(27.4.4.3)).
Change 31.10.6.4[fstream.members], p5:
Effects: Calls
rdbuf()->close()and, if that functionfails (returnsa null pointer),callsfalsesetstate(failbit)(which may throwios_base::failure(27.4.4.3)).
[Kona (2007): Proposed Disposition: NAD, Editorial]
Section: 3.2 [dec.tr::trdec.types.types]Status:NADSubmitter: Daveed VandevoordeOpened: 2006-04-05Last modified: 2016-01-31
Priority:Not Prioritized
View all otherissues in [dec.tr::trdec.types.types].
View all issues withNAD status.
Discussion:
In a private email, Daveed writes:
I am not familiar with the C TR, but my guess is that theclass type approach still won't match a built-in typeapproach because the notion of "promotion" cannot beemulated by user-defined types.
Here is an example:
struct S { S(_Decimal32 const&); // Converting constructor }; void f(S); void f(_Decimal64); void g(_Decimal32 d) { f(d); }If _Decimal32 is a built-in type, the call f(d) will likelyresolve to f(_Decimal64) because that requires only apromotion, whereas f(S) requires a user-defined conversion.
If _Decimal32 is a class type, I think the call f(d) will beambiguous because both the conversion to _Decimal64 and theconversion to S will be user-defined conversions with neitherbetter than the other.
Robert comments:
In general, a library of arithmetic types cannot exactly emulate the behavior of the intrinsic numeric types. There are several ways to tell whether an implementation of the decimal types uses compiler intrinisics or a library. For example:
_Decimal32 d1; d1.operator+=(5); // If d1 is a builtin type, this won't compile.
In preparing the decimal TR, we have three options:
We decided as a group to pursue option #3, but that approach implies that implementations may not agree on the semantics of certain use cases (first example, above), or on whether certain other cases are well-formed (second example). Another potentially important problem is that, under the present definition of POD, the decimal classes are not POD types, but builtins will be.
Note that neither example above implies any problems with respect to C-to-C++ compatibility, since neither example can be expressed in C.
[2009-07 Frankfurt]
Decimal numeric types may either be builtin types or library types. Weonly intend to specify the common subset of behaviors of the twoimplementation approaches. The front matter of the Decimal TR says thisexplicitly.
Move to NAD.
Proposed resolution:
Section: 3.2 [dec.tr::trdec.types.types]Status:NADSubmitter: Martin SeborOpened: 2006-06-15Last modified: 2016-01-31
Priority:Not Prioritized
View all otherissues in [dec.tr::trdec.types.types].
View all issues withNAD status.
Discussion:
In c++std-lib-17205, Martin writes:
...was it a deliberate design choice to make narrowing assignments ill-formed while permitting narrowing compound assignments? For instance:
decimal32 d32; decimal64 d64; d32 = 64; // error d32 += 64; // okay
In c++std-lib-17229, Robert responds:
It is a vestige of an old idea that I forgot to remove from the paper. Narrowing assignments should be permitted. The bug is that the converting constructors that cause narrowing should not be explicit. Thanks for pointing this out.
[2009-07 Frankfurt]
The current state of the Decimal TR is the result of a deliberate designdecision that has been examined many times.
Move to NAD.
Proposed resolution:
1. In "3.2.2 Classdecimal32" synopsis, remove theexplicit specifier from the narrowing conversions:
//3.2.2.2 conversion from floating-point type:explicitdecimal32(decimal64d64);explicitdecimal32(decimal128d128);
2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
3. In "3.2.3 Classdecimal64" synopsis, remove theexplicit specifier from the narrowing conversion:
//3.2.3.2 conversion from floating-point type:explicitdecimal64(decimal128d128);
4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
[Redmond: We prefer explicit conversions for narrowing and implicit for widening.]
std::string allocator requirements still inconsistentSection: 27.4.3[basic.string]Status:NADSubmitter: Bo PerssonOpened: 2006-12-05Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD status.
Discussion:
This is based on N2134, where 21.3.1/2 states:"... The Allocator object used shall be a copy of the Allocator object passed to the basic_string object's constructor or, if the constructor does not take an Allocator argument, a copy of a default-constructed Allocator object."
Section 21.3.2/1 lists two constructors:
basic_string(const basic_string<charT,traits,Allocator>& str );basic_string(const basic_string<charT,traits,Allocator>& str , size_type pos , size_type n = npos, const Allocator& a = Allocator());
and then says "In the first form, the Allocator value used is copied from str.get_allocator().", which isn't an option according to 21.3.1.
[Batavia: We need blanket statement to the effect of:]
[Review constructors and functions that return a string; make sure we follow theserules (substr, operator+, etc.). Howard to supply wording.]
[Bo adds: The new container constructor which takes only asize_type is notconsistent with 23.2[container.requirements], p9 which says in part:]
All other constructors for these container types take an
Allocator&argument (20.1.2), an allocator whose value typeis the same as the container's value type. A copy of this argument isused for any memory allocation performed, by these constructors and byall member functions, during the lifetime of each container object.
[post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.]
[2009-07 Frankfurt]
Move to NAD.
Proposed resolution:
Section: 27.5[c.strings]Status:NAD EditorialSubmitter: Bo PerssonOpened: 2006-12-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [c.strings].
View all otherissues in [c.strings].
View all issues withNAD Editorial status.
Discussion:
In the current draft N2134, 21.4/1 says
"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers <cctype>, <cwctype>, <cstring>, <cwchar>, and <cstdlib> (character conversions), respectively."
Here footnote 229 applies to table 62, not table 63.
Also, footnote 230 lists the new functions in table 63, "atoll, strtoll, strtoull, strtof, and strtold added by TR1". However, strtof is not present in table 63.
Proposed resolution:
Rationale:
Recommend NAD, editorial. Send to Pete.
Section: 16.3.2.4[structure.specifications]Status:NAD EditorialSubmitter: Martin SeborOpened: 2007-01-20Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [structure.specifications].
View all otherissues in [structure.specifications].
View all issues withNAD Editorial status.
Discussion:
TheRemark clauses newly introduced into the Working Paper (N2134)are not mentioned in 16.3.2.4[structure.specifications] where we list themeaning ofEffects,Requires, and other clauses (withthe exception ofNotes which are documented as informative in16.3.2.2[structure.summary], p2, and which they replace in many cases).
Propose add a bullet forRemarks along with a brief description.
[Batavia: Alan and Pete to work.]
[Bellevue: Already resolved in current working paper.]
Proposed resolution:
Section: 17.6.3.2[new.delete.single]Status:NADSubmitter: P.J. PlaugerOpened: 2007-01-23Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [new.delete.single].
View all otherissues in [new.delete.single].
View all issues withNAD status.
Discussion:
I recognize the need for nothrow guarantees in the exception reportingmechanism, but I strongly believe that implementors also need an escape hatchwhen memory gets really low. (Like, there's not enough heap to construct andcopy exception objects, or not enough stack to process the throw.) I'd like tothink we can put this escape hatch in 17.6.3.2[new.delete.single],operator new, but I'm not sure how to do it. We need more than afootnote, but the wording has to be a bit vague. The idea is that ifnew can't allocate something sufficiently small, it has the right toabort/callterminate/callunexpected.
[Bellevue: NAD. 1.4p2 specifies a program must behave correctly "withinits resource limits", so no further escape hatch is necessary.]
Proposed resolution:
BinaryPredicateSection: 26[algorithms]Status:NADSubmitter: James KanzeOpened: 2007-01-31Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [algorithms].
View all otherissues in [algorithms].
View all issues withNAD status.
Discussion:
The general requirements forBinaryPredicate
[...] if an algorithm takes
BinaryPredicatebinary_predas its argument andfirst1andfirst2 as itsiterator arguments, it should work correctly in the constructif(binary_pred (*first1 , *first2 )){...}.BinaryPredicatealways takes the first iterator type as itsfirst argument, that is, in those cases whenTvalueispart of the signature, it should work correctly in the context ofif(binary_pred (*first1 ,value)){...}.
In the description ofupper_bound (26.8.4.3[upper.bound]/2), however, the use is described as"!comp(value,e)", wheree is anelement of the sequence (a result of dereferencing*first).
In the description oflexicographical_compare, we have both"*first1 < *first2" and "*first2< *first1" (which presumably implies "comp(*first1, *first2 )" and "comp( *first2,*first1 )".
Logically, theBinaryPredicate is used as an orderingrelationship, with the semantics of "less than". Depending on thefunction, it may be used to determine equality, or any of the inequalityrelationships; doing this requires being able to use it with eitherparameter first. I would thus suggest that the requirement be:
Alternatively, one could specify an order for each function. IMHO, thiswould be more work for the committee, more work for the implementors,and of no real advantage for the user: some functions, such aslexicographical_compare orequal_range, will still require bothfunctions, and it seems like a much easier rule to teach that bothfunctions are always required, rather than to have a complicated list ofwhen you only need one, and which one.
[Toronto: Moved to Open. ConceptGCC seems to getlower_boundandupper_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 useBinaryPredicate, and where it is used,it is consistent with [algorithm]/8, so the main complaint of the issueis moot.
[2010-01-16 Beman clarified wording.]
[2010-01-31: Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Rationale:
[post San Francisco:]
Solved byN2759.
2010-01-31: The draft standard is well specified as is, and this specificationis desired. Issues556(i) and870(i) solve the remainingunclearness regarding the meaning of BinaryPredicate.
Proposed resolution:
Change 26[algorithms] paragraph 8 as indicated:
8 The
BinaryPredicateparameter is used whenever an algorithm expects afunction object that when applied to the result of dereferencing twocorresponding iterators or to dereferencing an iterator and typeTwhenTis part of the signature returns a value testable as true.BinaryPredicatealways takes the first iteratorvalue_typeasone of its arguments; which argument is unspecified.In other words,ifIf an algorithm takesBinaryPredicate binary_predas its argument andfirst1andfirst2as its iteratorarguments, it should work correctlyboth in the constructif(binary_pred(*first1, *first2)){...}andif (binary_pred (*first2,*first1)){...}.In those caseswhenBinaryPredicatealways takes the firstiterator type as its first argument, that is, inT valueis part of the signature, it should work correctly in thecontext ofif (binary_pred(*first1, value)){...}and ofif(binary_pred (value, *first1)){...}.[Note: if the two types are not identical, and neither isconvertable to the other, this may require that thebinary_predshallnot apply any non-constant function through the dereferenced iterators.BinaryPredicatebea functional object with two overloadedoperator()()functions.—end note]
size() forstd::setSection: 23.2[container.requirements]Status:NADSubmitter: Lionel BOpened: 2007-02-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withNAD status.
Discussion:
A recent news group discussion:
Anyone know if the Standard has anything to say about the time complexityof
size()forstd::set? I need to access a set's size (not to know if it is empty!) heavily during an algorithm and was thus wondering whether I'd be better off tracking the size "manually" or whether that'd be pointless.That would be pointless.
size()is O(1).Nit: the standard says "should" have constant time. Implementations may takelicense to do worse. I know that some do this for
std::list<>as a part ofsome trade-off with other operation.I was aware of that, hence my reluctance to use size() for std::set.
However, this reason would not apply to
std::set<>as far as I can see.Ok, I guess the only option is to try it and see...
If I have any recommendation to the C++ Standards Committee it is thatimplementations must (not "should"!) document clearly[1], where known, thetime complexity of *all* container access operations.
[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()for std::set is not documented... but if it is it's certainly well hiddenaway.
[Kona (2007): This issue affects all the containers. We'd love to see apaper dealing with the broad issue. We think that the complexity of thesize() member of every container -- except possiblylist -- should beO(1). Alan has volunteered to provide wording.]
[Bellevue:]
Mandating O(1) size will not fly, too many implementations would beinvalidated. Alan to provide wording that toughens wording, but thatdoes not absolutely mandate O(1).
[Batavia (2009-05):]
We observed that the wording "should" (in note a) has no effect.Howard prefers that O(1) size be mandated.It is not clear that this issue can be resolved to everyone's satisfaction,but Alan will provide wording nonetheless.
[2009-07 Frankfurt]
Fixed by paper N2923.
Proposed resolution:
Section: 22.10.17.3.6[func.wrap.func.targ]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-02-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.wrap.func.targ].
View all issues withNAD Editorial status.
Discussion:
22.10.17.3.6[func.wrap.func.targ], p4 says:
Returns: If
type() == typeid(T), a pointer to the storedfunction target; otherwise a null pointer.
type, nor memberfunctiontype() in class template function nor in the global orstd namespace.type should have beentarget_type(),this description would lead to false results, ifT =cvvoid due to returns clause 22.10.17.3.6[func.wrap.func.targ], p1.Proposed resolution:
Change 22.10.17.3.6[func.wrap.func.targ], p4:
Returns: If
, a pointer to the stored function target;otherwise a null pointer.type()target_type() == typeid(T)&& typeid(T) !=typeid(void)
[Pete: Agreed. It's editorial, so I'll fix it.]
Section: 29.6.2.4[valarray.access]Status:NAD EditorialSubmitter: Bo PerssonOpened: 2007-02-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.access].
View all issues withNAD Editorial status.
Discussion:
The signature of the const operator[] has been changed to return a const reference.
The description in paragraph 1 still says that the operator returns by value.
[Pete recommends editorial fix.]
Proposed resolution:
Section: 29.7[c.math]Status:NAD EditorialSubmitter: Bo PerssonOpened: 2007-02-13Last modified: 2016-02-01
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD Editorial status.
Discussion:
29.7[c.math], paragraph 10 has long lists of added signatures for float and long double functions. All the signatures have float/long double return values, which is inconsistent with some of the double functions they are supposed to overload.
Proposed resolution:
Change 29.7[c.math], paragraph 10,
floatint ilogb(float);floatlong lrint(float);floatlong lround(float);floatlong long llrint(float);floatlong long llround(float);long doubleint ilogb(long double);long doublelong lrint(long double);long doublelong lround(long double);long doublelong long llrint(long double);long doublelong long llround(long double);
Section: 31.7.5.3.3[istream.extractors], 31.7.6.3.3[ostream.inserters]Status:NADSubmitter: Daniel KrüglerOpened: 2007-02-17Last modified: 2017-04-22
Priority:Not Prioritized
View all otherissues in [istream.extractors].
View all issues withNAD status.
Discussion:
There already exist two active DR's for the wording of [istream::extractors]/13from 14882:2003(E), namely64(i) and413(i).
Even with these proposed corrections, already maintained in N2134,I have the feeling, that the current wording does still not properlyhandle the "exceptional" situation. The combination of para 14
"[..] Characters are extracted and inserted untilany of the following occurs:
[..]
- an exception occurs (in which case the exception is caught)."
and 15
"If the function inserts no characters, it calls setstate(failbit),whichmay throw ios_base::failure (27.4.4.3). If it inserted no charactersbecause it caught an exception thrown while extracting charactersfrom *this and failbit is on in exceptions() (27.4.4.3), then thecaughtexception is rethrown."
both in N2134 seems to imply that any exception, which occurs*after* at least one character has been inserted is caught and lostforever. It seems that even if failbit is on in exceptions() rethrow isnotallowed due to the wording "If it inserted no characters because itcaught an exception thrown while extracting".
Is this behaviour by design?
I would like to add that its output counterpart in 31.7.6.3.3[ostream.inserters]/7-9(alsoN2134) does not demonstrate such an exception-loss-behaviour.On the other side, I wonder concerning several subtle differencescompared to input::
1) Paragraph 8 says at its end:
"- an exception occurs while getting a character from sb."
Note that there is nothing mentioned which would imply that suchan exception will be caught compared to [istream::extractors]/14.
2) Paragraph 9 says:
"If the function inserts no characters, it calls setstate(failbit)(whichmay throw ios_base::failure (27.4.4.3)). If an exception was thrownwhile extracting a character, the function sets failbit in errorstate,and if failbit is on in exceptions() the caught exception isrethrown."
The sentence starting with "If an exception was thrown" seems toimply that such an exception *should* be caught before.
Proposed resolution:
(a) In [istream::extractors]/15 (N2134) change the sentence
If the function inserts no characters, it calls
setstate(failbit), which may throwios_base::failure(27.4.4.3). Ifit inserted no characters because it caught anexception thrown while extracting characters froman exception was thrown while extracting a character from*this*this, the function setsfailbitin error state,andfailbitis on inexceptions()(27.4.4.3), then thecaught exception is rethrown.
(b) In 31.7.6.3.3[ostream.inserters]/8 (N2134) change the sentence:
Gets characters from
sband inserts them in*this.Characters are read fromsband inserted until any of thefollowing occurs:
- end-of-file occurs on the input sequence;
- inserting in the output sequence fails (in which case the character to be inserted is not extracted);
- an exception occurs while getting a character from
sb(in whichcase the exception is caught).
Rationale:
This extractor is described as a formatted input function so theexception behavior is already specified. There is additional behaviordescribed in this section that applies to the case in which failbit isset. This doesn't contradict the usual exception behavior for formattedinput functions because that applies to the case in which badbit is set.
Section: 31.7.8[ext.manip]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-02-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ext.manip].
View all issues withNAD Editorial status.
Discussion:
The functionf in para 4 (31.7.8[ext.manip]) references an unknownstrmin the following line:
mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
Proposed resolution:
Change 31.7.8[ext.manip], p4:
mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
[Oxford: Editorial.]
Section: 31.10.4.4[ifstream.members], 31.10.5.4[ofstream.members]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-02-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [ifstream.members].
View all issues withNAD Editorial status.
Discussion:
The standard wording of N2134 has extended the 14882:2003(E)wording for the ifstream/ofstream/fstream open function to fixa long standing problem, see409(i).
Now it's properly written as
"If that function does not return a null pointer calls clear(),otherwisecalls setstate(failbit)[..]"
instead of the previous
"If that function returns a null pointer, calls setstate(failbit)[..]
While the old footnotes saying
"A successful open does not change the error state."
where correct and important, they are invalid now for ifstream andofstream (because clear *does* indeed modify the error state) andshould be removed (Interestingly fstream itself never had these,althoughthey where needed for that time).
Proposed resolution:
In 31.10.4.4[ifstream.members], remove footnote:
334) A successful open does not change the error state.
In 31.10.5.4[ofstream.members], remove footnote:
335) A successful open does not change the error state.
Section: 22.10.17.3[func.wrap.func]Status:NADSubmitter: Bo PerssonOpened: 2007-02-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.wrap.func].
View all issues withNAD status.
Discussion:
22.10.17.3[func.wrap.func]
The note in paragraph 2 refers to 'undefined void operators', while thesection declares a pair of operators returningbool.
[Post-Sophia Antipolis:]
Changed from Pending WP to Open. This issue was voted to WP at the same time the operators werechanged from private to deleted. The two issues stepped on each other. What do we want the returntype of these deleted functions to be?
[2009-05-02 Daniel adds:]
I suggest harmonizing this issue with similar classes. E.g. in20.3.2.3[util.smartptr.weak]
boolreturn values fortemplate <class Y> bool operator<(weak_ptr<Y> const&) const = delete;template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete;template <class Y> bool operator>(weak_ptr<Y> const&) const = delete;template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete;are used and basically allnewer provided deleted copy assignment operatorsof type
Xuse the canonical return typeX&instead ofvoid. Since the notementioned in the issue description has now already been changed todeleted overloads close possible hole in the type system
it seems to be of even lesser need to perform the change. ThereforeI recommend declaring the issue as NAD.
[Batavia (2009-05):]
We agree with Daniel's recommendation.
Move to NAD.
Proposed resolution:
Change 22.10.17.3[func.wrap.func]
...private: // 22.10.17.3[func.wrap.func], undefined operators: template<class Function2>boolvoid operator==(const function<Function2>&); template<class Function2>boolvoid operator!=(const function<Function2>&);};
Change 22.10.17.3[func.wrap.func]
template<class Function2>boolvoid operator==(const function<Function2>&);template<class Function2>boolvoid operator!=(const function<Function2>&);
Section: 28.6.9[re.results]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-02-26Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.results].
View all issues withNAD Editorial status.
Discussion:
According to the description given in 28.6.9[re.results]/2 the class templatematch_results "shall satisfy the requirements of a Sequence, [..],except that only operations defined for const-qualified Sequencesare supported".Comparing the provided operations from 28.6.9[re.results]/3 with thesequence/container tables 80 and 81 one recognizes the followingmissing operations:
1) The members
const_iterator rbegin() const;const_iterator rend() const;
should exists because 23.1/10 demands these for containers(all sequences are containers) which support bidirectionaliterators. Aren't these supported by match_result? This is notexplicitely expressed, but it's somewhat implied by two arguments:
(a) Several typedefs delegate toiterator_traits<BidirectionalIterator>.
(b) The existence ofconst_reference operator[](size_type n) constimplies even random-access iteration.I also suggest, thatmatch_result should explicitly mention,which minimum iterator category is supported and if this doesnot include random-access the existence ofoperator[] issomewhat questionable.
2) The new "convenience" members
const_iterator cbegin() const;const_iterator cend() const;const_iterator crbegin() const;const_iterator crend() const;
should be added according to tables 80/81.
Proposed resolution:
Add the following members to thematch_results synopsis afterend() in 28.6.9[re.results]para 3:
const_iterator cbegin() const; const_iterator cend() const;
In section 28.6.9.5[re.results.acc] change:
const_iterator begin() const;const_iterator cbegin() const;-7-Returns: A starting iterator that enumerates over all the sub-expressions stored in
*this.const_iterator end() const;const_iterator cend() const;-8-Returns: A terminating iterator that enumerates over all the sub-expressions stored in
*this.
[Kona (2007): Voted to adopt proposed wording inN2409except removing the entry in the table container requirements. Moved to Review.]
[Bellevue: Proposed wording now in the WP.]
regex_search paramsSection: 28.6.10.3[re.alg.search]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-02-26Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
28.6.10.3[re.alg.search]/5 declares
template <class iterator, class charT, class traits>bool regex_search(iterator first, iterator last, const basic_regex<charT, traits>& e, regex_constants::match_flag_type flags = regex_constants::match_default);
where it's not explained, which iterator categorythe parameter iterator belongs to. This is inconsistentto the preceding declaration in the synopsis section28.6.3[re.syn], which says:
template <class BidirectionalIterator, class charT, class traits>bool regex_search(BidirectionalIterator first, BidirectionalIterator last, const basic_regex<charT, traits>& e, regex_constants::match_flag_type flags = regex_constants::match_default);
Proposed resolution:
In 28.6.10.3[re.alg.search]/5 replace all three occurences of param "iterator" with"BidirectionalIterator"
template <classiteratorBidirectionalIterator, class charT, class traits> bool regex_search(iteratorBidirectionalIterator first,iteratorBidirectionalIterator last, const basic_regex<charT, traits>& e, regex_constants::match_flag_type flags = regex_constants::match_default);-6-Effects: Behaves "as if" by constructing an object what oftype
match_results<and then returning the resultofiteratorBidirectionalIterator>regex_search(first, last, what, e, flags).
Rationale:
Applied to working paper while issue was still in New status.
Section: 28.6.11.1.2[re.regiter.cnstr]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-03-03Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
In 28.6.11.1.2[re.regiter.cnstr]/2 the effects paragraph starts with:
Effects: Initializes begin and end to point to the beginning and theend of the target sequence, sets pregex to &re, sets flags to f,[..]
There are two issues with this description:
Proposed resolution:
In 28.6.11.1.2[re.regiter.cnstr]/2 change the above quoted part by
Effects: Initializes
beginandendto point tothe beginning and the end of the target sequencedesignated by theiterator range[a, b), setspregexto&re, setsflagsto, then callsfmregex_search(begin, end, match,*pregex, flags). If this call returnsfalsetheconstructor sets*thisto the end-of-sequence iterator.
Section: 28.6.11.2.2[re.tokiter.cnstr]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-03-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.tokiter.cnstr].
View all issues withNAD Editorial status.
Discussion:
In 28.6.11.2.2[re.tokiter.cnstr]/1+2 both the constructor declarationand the following text shows some obvious typos:
1) The third constructor form is written as
template <std::size_t N> regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re, const int (&submatches)[R], regex_constants::match_flag_type m = regex_constants::match_default);
where the dimensions of submatches are specified by anunknown value R, which should be N.
2) Paragraph 2 of the same section says in its last sentence:
The third constructor initializes the member
substo hold acopy of the sequence of integer values pointed to by the iterator range[&submatches, &submatches + R).
where again R must be replaced by N.
3) Paragraph 3 of the same section says in its first sentence:
Each constructor then sets
Nto0, andpositiontoposition_iterator(a, b, re, f).
where a non-existing parameter "f" is mentioned, which must bereplacedby the parameter "m".
Proposed resolution:
Change 28.6.11.2.2[re.tokiter.cnstr]/1:
template <std::size_t N> regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re, const int (&submatches)[RN], regex_constants::match_flag_type m = regex_constants::match_default);
Change 28.6.11.2.2[re.tokiter.cnstr]/2:
Effects: The first constructor initializes the member
substo hold the single valuesubmatch. The secondconstructor initializes the membersubsto hold a copy of theargumentsubmatches. The third constructor initializes themembersubsto hold a copy of the sequence of integer valuespointed to by the iterator range[&submatches, &submatches +.RN)
Change 28.6.11.2.2[re.tokiter.cnstr]/3:
Each constructor then sets
Nto0, andpositiontoposition_iterator(a, b, re,. Iffm)positionis not an end-of-sequenceiterator the constructor setsresultto the address of thecurrent match. Otherwise if any of the values stored insubsisequal to-1the constructor sets*thisto a suffixiterator that points to the range[a, b), otherwise theconstructor sets*thisto an end-of-sequence iterator.
Section: 2[intro.refs]Status:NADSubmitter: Alisdair MeredithOpened: 2007-03-08Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [intro.refs].
View all issues withNAD status.
Discussion:
2[intro.refs] Normative references
The following standards contain provisions which, through reference inthis text, constitute provisions of this Interna- tional Standard. Atthe time of publication, the editions indicated were valid. Allstandards are subject to revision, and parties to agreements based onthis International Standard are encouraged to investigate thepossibility of applying the most recent editions of the standardsindicated below. Members of IEC and ISO maintain registers of currentlyvalid International Standards.
- Ecma International, ECMAScript Language Specification, StandardEcma-262, third edition, 1999.
- ISO/IEC 2382 (all parts), Information technology - Vocabulary
- ISO/IEC 9899:1990, Programming languages - C
- ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: CIntegrity
- ISO/IEC 9899:1999, Programming languages - C
- ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C
- ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C
- ISO/IEC 9945:2003, Information Technology-Portable Operating SystemInterface (POSIX)
- ISO/IEC 10646-1:1993 Information technology - Universal Multiple-OctetCoded Character Set (UCS) - Part 1: Architecture and Basic MultilingualPlane
I'm not sure how many of those reserve naming patterns that might affectus, but I am equally sure I don't own a copy of any of these to check!
The point is to list the reserved naming patterns, rather than theindividual names themselves - although we may want to list C keywordsthat are valid identifiers in C++ but likely to cause trouble in sharedheaders (e.g. restrict)
[Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one.]
[Post-Kona: Alisdair request Open. A good example of the problem was adiscussion of the system error proposal, where it was pointed out an all-capsidentifier starting with a capital E conflicted with reserved macro names forboth Posix and C. I had absolutely no idea of this rule, and suspect I wasnot the only one in the room.
Resolution will require someone with access to all the listed documents toresearch their respective name reservation rules, or people with access tospecific documents add their rules to this issue until the list is complete.]
[Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.Suggest a formal paper rather than a defect report is the correct way to proceed.]
Proposed resolution:
Section: 29.5.2[rand.synopsis]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-03-08Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.synopsis].
View all issues withNAD Editorial status.
Discussion:
29.5.2[rand.synopsis] the header<random> synopsiscontains an unreasonable closing curly brace inside thesubtract_with_carry_engine declaration.
Proposed resolution:
Change the current declaration in 29.5.2[rand.synopsis]
template <class UIntType, size_t w}, size_t s, size_t r>class subtract_with_carry_engine;
[Pete: Recommends editorial.]
Section: 16.4.3.2[using.headers]Status:NADSubmitter: Gennaro ProtaOpened: 2007-03-14Last modified: 2025-10-15
Priority:Not Prioritized
View all otherissues in [using.headers].
View all issues withNAD status.
Discussion:
16.4.3.2[using.headers] states:
A translation unit shall include a header only outside of anyexternal declaration or definition, [...]
I see three problems with this requirement:
The C++ standard doesn't define what an "external declaration" oran "external definition" are (incidentally the C99 standard does, andhas a sentence very similar to the above regarding header inclusion).
I think the intent is that the #include directive shall lexicallyappear outside *any* declaration; instead, when the issue was pointedout on comp.std.c++ at least one poster interpreted "externaldeclaration" as "declaration of an identifier with external linkage".If this were the correct interpretation, then the two inclusions belowwould be legal:
// at global scope static void f() {# include <cstddef> } static void g() {# include <stddef.h> }(note that while the first example is unlikely to compile correctly,the second one may well do)
as the sentence stands, violations will require a diagnostic; isthis the intent? It was pointed out on comp.std.c++ (by severalposters) that at least one way to ensure a diagnostic exists:
[If there is an actual file for each header,] one simple way to implement this would be to insert a reserved identifier such as __begin_header at the start of each standard header. This reserved identifier would be ignored for all other purposes, except that, at the appropriate point in phase 7, if it is found inside an external definition, a diagnostic is generated. There's many other similar ways to achieve the same effect.
--James Kuyper, on comp.std.c++
is the term "header" meant to be limited to standard headers?Clause 17 is all about the library, but still the general question isinteresting and affects one of the points in the explicit namespacesproposal (n1691):
Those seeking to conveniently enable argument-dependent lookups for all operators within an explicit namespace could easily create a header file that does so:
namespace mymath:: { #include "using_ops.hpp" }
[2025-10-15; Jonathan adds additional rationale]
For the second point, LWG2428(i) removed "external"and LWG2225(i) added "no diagnostic is required".For the third point, 16.4.2.3[headers] clearly defines "header"to mean only standard library headers; other#included files are"source files" (5.1[lex.separate]).
Proposed resolution:
Rationale:
We believe that the existing language does not cause any real confusionand any new formulation of the rules that we could come up with areunlikely to be better than what's already in the standard.
Section: 28.3.4.3.2.3[facet.num.get.virtuals]Status:NADSubmitter: Cosmin TrutaOpened: 2007-04-05Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [facet.num.get.virtuals].
View all otherissues in [facet.num.get.virtuals].
View all issues withNAD status.
Discussion:
From Section 28.3.4.3.2.3[facet.num.get.virtuals], paragraphs 11 and 12, it is impliedthat the value read from a stream must be storedeven if the placement of thousands separators does not conform to thegrouping() specification from thenumpunct facet.Since incorrectly-placed thousands separators are flagged as an extractionfailure (by the means offailbit), we believe it is better notto store the value. A consistent strategy, in which any kind of extractionfailure leaves the input item intact, is conceptually cleaner, is able to avoidcorner-case traps, and is also more understandable from the programmer's pointof view.
Here is a quote from"The C++ Programming Language (Special Edition)"by B. Stroustrup (Section D.4.2.3, pg. 897):
"If a value of the desired type could not be read, failbit is set in r.[...] An input operator will use r to determine how to set the state of itsstream. If no error was encountered, the value read is assigned through v;otherwise, v is left unchanged."
This statement implies thatrdstate() alone is sufficient todetermine whether an extracted value is to be assigned to the input itemval passed todo_get. However, this is in disagreementwith the current C++ Standard. The above-mentioned assumption is true in allcases, except when there are mismatches in digit grouping. In the latter case,the parsed value is assigned toval, and, at the same time,erris assigned toios_base::failbit (essentially "lying" about thesuccess of the operation). Is this intentional? The current behavior raisesboth consistency and usability concerns.
Although digit grouping is outside the scope ofscanf (on whichthe virtual methods ofnum_get are based), handling of groupingshould be consistent with the overall behavior of scanf. The specification ofscanf makes a distinction between input failures and matchingfailures, and yet both kinds of failures have no effect on the input itemspassed toscanf. A mismatch in digit grouping logically falls inthe category of matching failures, and it would be more consistent, and lesssurprising to the user, to leave the input item intact whenever a failure isbeing signaled.
The extraction ofbool is another example outside the scope ofscanf, and yet consistent, even in the event of a successfulextraction of along but a failed conversion fromlong tobool.
Inconsistency is further aggravated by the fact that, when failbit is set,subsequent extraction operations are no-ops untilfailbit isexplicitly cleared. Assuming that there is no explicit handling ofrdstate() (as incin>>i>>j) it iscounter-intuitive to be able to extract an integer with mismatched digitgrouping, but to be unable to extract another, properly-formatted integerthat immediately follows.
Moreover, settingfailbit, and selectively assigning a value tothe input item, raises usability problems. Either the strategy ofscanf (when there is no extracted value in case of failure), orthe strategy of thestrtol family (when there is always anextracted value, and there are well-defined defaults in case of a failure) areeasy to understand and easy to use. On the other hand, iffailbitalone cannot consistently make a difference between a failed extraction, and asuccessful but not-quite-correct extraction whose output happens to be the sameas the previous value, the programmer must resort to implementation tricks.Consider the following example:
int i = old_i; cin >> i; if (cin.fail()) // can the value of i be trusted? // what does it mean if i == old_i? // ...
Last but not least, the current behvaior is not only confusing to the casualreader, but it has also been confusing to some book authors. BesidesStroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" byLanger and Kreft) are describing the same mistaken assumption. Although booksare not to be used instead of the standard reference, the readers of thesebooks, as well as the people who are generally familiar toscanf,are even more likely to misinterpret the standard, and expect the input itemsto remain intact when a failure occurs.
Proposed resolution:
Change 28.3.4.3.2.3[facet.num.get.virtuals]:
Stage 3: The result of stage 2 processing can be one of
- A sequence of
charshas been accumulated in stage 2 that is converted (according to the rules ofscanf) to a value of the type ofval.This value is stored invalandios_base::goodbitis stored inerr.- The sequence of
charsaccumulated in stage 2 would have causedscanfto report an input failure.ios_base::failbitis assigned toerr.In the first case,
Ddigit grouping is checked. That is, the positions of discarded separators is examined for consistency withuse_facet<numpunct<charT> >(loc).grouping(). If they are not consistent thenios_base::failbitis assigned toerr.Otherwise, the value that was converted in stage 2 is stored invalandios_base::goodbitis stored inerr.
Rationale:
post-Toronto: Changed from New to NAD at the request of the author. The preferred solution ofN2327makes this resolution obsolete.
Section: 16.3.2.4[structure.specifications]Status:NADSubmitter: Thomas PlumOpened: 2007-04-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [structure.specifications].
View all otherissues in [structure.specifications].
View all issues withNAD status.
Discussion:
16.3.2.4[structure.specifications] para 5 says
-5- Complexity requirements specified in the libraryclauses are upper bounds, and implementations that provide bettercomplexity guarantees satisfy the requirements.
The followingobjection has been raised:
The library clauses suggest generalguidelines regarding complexity, but we have been unable to discoverany absolute hard-and-fast formulae for these requirements. Unlessor until the Library group standardizes specific hard-and-fastformulae, we regard all the complexity requirements as subject to a"fudge factor" without any intrinsic upper bound.
[Plum ref_23213Y31 etc]
Proposed resolution:
Rationale:
Kona (2007): No specific instances of underspecification have beenidentified, and big-O notation always involves constant factors.
money_get's widened minus signSection: 28.3.4.7.2.3[locale.money.get.virtuals]Status:NADSubmitter: Thomas PlumOpened: 2007-04-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.money.get.virtuals].
View all issues withNAD status.
Discussion:
28.3.4.7.2.3[locale.money.get.virtuals], para 1 says:
The result is returned as an integral valuestored in
unitsor as a sequence of digits possibly preceded by aminus sign (as produced byct.widen(c)wherecis '-' or in the rangefrom '0' through '9', inclusive) stored indigits.
The followingobjection has been raised:
Some implementations interpret this to mean that a facet derived from
ctype<wchar_t>can provide its own memberdo_widen(char)which produces e.g.L'@'for the "widened" minus sign, and that the'@'symbol will appear in the resulting sequence of digits. Otherimplementations have assumed that one or more places in the standard permit theimplementation to "hard-wire"L'-'as the "widened" minus sign. Areboth interpretations permissible, or only one?
[Plum ref _222612Y14]
Furthermore: ifct.widen('9') producesL'X' (a non-digit), does aparse fail if a'9' appears in the subject string? [Plum ref _22263Y33]
[Kona (2007): Bill and Dietmar to provide proposed wording.]
[post Bellevue: Bill adds:]
The Standard is clear that the minus sign stored in
digitsisct.widen('-').The subject string must contain characterscin the set[-0123456789]which are translated byct.widen(c)calls before being stored indigits;the widened characters are not relevant to the parsing of the subject string.
[Batavia (2009-05):]
We agree with Bill's comment above,in line with the first of the interpretations offered in the issue.Move to NAD.
Proposed resolution:
money_get's empty minus signSection: 28.3.4.7.2.3[locale.money.get.virtuals]Status:NADSubmitter: Thomas PlumOpened: 2007-04-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.money.get.virtuals].
View all issues withNAD status.
Discussion:
28.3.4.7.2.3[locale.money.get.virtuals], para 3 says:
If
posornegis empty, the sign component isoptional, and if no sign is detected, the result is given the signthat corresponds to the source of the empty string.
The following objection has been raised:
A
negative_signof "" means "there is noway to write a negative sign" not "any null sequence is a negativesign, so it's always there when you look for it".
[Plum ref _222612Y32]
[Kona (2007): Bill to provide proposed wording and interpretation of existing wording.]
[2009-05-17 Howard adds:]
I disagree that a
negative_signof "" means "there is no way towrite a negative sign". The meaning requires the sentences of 28.3.4.7.2.3[locale.money.get.virtuals] p3 following that quoted above to betaken into account:-3- ... If
posornegis empty, the sign component isoptional, and if no sign is detected, the result is given the sign thatcorresponds to the source of the empty string. Otherwise, the characterin the indicated position must match the first character ofposorneg, and the result is given the corresponding sign. If thefirst character ofposis equal to the first character ofneg, or if both strings are empty, the result is given apositive sign.So a
negative_signof "" means "there is no way to write anegative sign" only whenpositive_signis also "". Howeverwhennegative_signis "" andpostive_sign.size() >0, then one writes a negative value by not writing thepostive_signin the position indicated bymoney_base::sign.For example:pattern = {symbol, sign, value, none}positive_sign = "+"negative_sign = ""$123 // a negative value, using optional sign$+123 // a positive value$-123 // a parse errorAnd:
pattern = {symbol, sign, value, none}positive_sign = ""negative_sign = ""$123 // a positive value, no sign possible$+123 // a parse error$-123 // a parse errorpattern = {symbol, sign, value, none}positive_sign = "-"negative_sign = "-"$123 // a parse error, sign is mandatory$+123 // a parse error$-123 // a positive valueThe text seems both unambiguous and clear to me. I recommend NAD forboth this issue and669(i). However I would have noobjection to adding examples such as those above.
[Batavia (2009-05):]
This discussion applies equally to issue669(i) (q.v.).Howard has added examples above,and recommends either NAD or a resolution that adds his (or similar) examplesto the Working Paper.
Alan would like to rewrite paragraph 3.
We recommend moving to NAD.Anyone who feels strongly about adding the examplesis invited to submit corresponding wording.We further recommend issue669(i) be handled identically.
[2009-07-14 Alan reopens with improved wording.]
[2009-07 Frankfurt]
No consensus for closing as NAD. Leave in Review.
[2009-10 Santa Cruz:]
NAD. Agreed that the original assessment as NAD was correct.
Proposed resolution:
Change 28.3.4.7.2.3[locale.money.get.virtuals] p3:
-3-
If the first character (if any) in the string pos returned byThe sign pattern stringsmp.positive_sign()or the stringnegreturned bymp.negative_sign()is recognized in the position indicated bysign in the format pattern, it is consumed and any remaining charactersin the string are required after all the other format components.[Example: Ifshowbaseis off, then for anegvalue of "()" and a currency symbol of "L", in "(100 L)" the "L" isconsumed; but ifnegis "-", the "L" in "-100 L" is notconsumed. --end example] Ifposornegisempty, the sign component is optional, and if no sign is detected, theresult is given the sign that corresponds to the source of the emptystring. Otherwise, the character in the indicated position must matchthe first character ofposorneg, and the result isgiven the corresponding sign. If the first character ofposisequal to the first character ofneg, or if both strings areempty, the result is given a positive sign.posandnegare returned bymp.positive_sign()andmp.negative_sign()respectively. A sign patternis matched if its first character is recognized insin the positionindicated bysignin the format pattern, or if the pattern is empty andthere is no sign recognized ins. A match is required to occur. If bothpatterns are matched, the result is given a positive sign, otherwise theresult is given the sign corresponding to the matched pattern. If the pattern contains more than one character, the characters after the first must be matched insafter all other format components. If any signcharacters are matched,sis consumed up to and including those characters.[Example: Ifshowbaseis off, then for anegvalue of "()" and a currency symbol of "L", in"(100 L)" the entire string is consumed; but for anegvalue of "-", in "-100 L", the string is consumedthrough the second "0" (the space and "L" are not consumed). —endexample]
money_getSection: 28.3.4.7.2.3[locale.money.get.virtuals]Status:NADSubmitter: Thomas PlumOpened: 2007-04-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.money.get.virtuals].
View all issues withNAD status.
Discussion:
28.3.4.7.2.3[locale.money.get.virtuals], para 3 sentence 4 says:
If the first character of
posis equal to the first character ofneg, or if both strings are empty, the result is given a positive sign.
One interpretation is that an input sequence must match either thepositive pattern or the negative pattern, and then in either event itis interpreted as positive. The following objections has been raised:
The input can successfully match only a positive sign, so the negativepattern is an unsuccessful match.
[Plum ref _222612Y34, 222612Y51b]
[Bill to provide proposed wording and interpretation of existing wording.]
[2009-05-17 See Howard's comments in related issue668(i).]
[Batavia (2009-05):]
This discussion applies equally to issue668(i) (q.v.).Howard has added examples there,and recommends either NAD or a resolution that adds his (or similar) examplesto the Working Paper.
We recommend moving to NAD.Anyone who feels strongly about adding the examplesis invited to submit corresponding wording.We further recommend issue668(i) be handled identically.
Proposed resolution:
money_base::pattern andspaceSection: 28.3.4.7.4[locale.moneypunct]Status:DupSubmitter: Thomas PlumOpened: 2007-04-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [locale.moneypunct].
View all issues withDup status.
Duplicate of:836
Discussion:
28.3.4.7.4[locale.moneypunct], para 2 says:
The value
spaceindicates that at least one space is required at that position.
The following objection has been raised:
Whitespace is optional when matching space. (See 28.3.4.7.2.3[locale.money.get.virtuals], para 2.)
[Plum ref _22263Y22]
[Kona (2007): Bill to provide proposed wording. We agree that C++03 isambiguous, and that we want C++0X to say "space" means 0 or morewhitespace characters on input.]
Proposed resolution:
Section: 28.6.11.2[re.tokiter]Status:NAD EditorialSubmitter: Eric NieblerOpened: 2007-06-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.tokiter].
View all issues withNAD Editorial status.
Discussion:
28.6.11.2[re.tokiter], p3 says:
After it is constructed, the iterator finds and stores a value
match_results<BidirectionalIterator>position and sets theinternal countNto zero.
Should read:
After it is constructed, the iterator finds and stores a value
position and sets the internal countmatch_resultsregex_iterator<BidirectionalIterator, charT, traits>Nto zero.
[John adds:]
Yep, looks like a typo/administrative fix to me.
Proposed resolution:
Section: 28.6.9[re.results]Status:NAD EditorialSubmitter: Nozomu KatooOpened: 2007-05-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.results].
View all issues withNAD Editorial status.
Discussion:
In 28.6.3[re.syn] of N2284, two template functions are declared here:
// 28.10, class template match_results: <snip>// match_results comparisons template <class BidirectionalIterator, class Allocator> bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, const match_results<BidirectionalIterator, Allocator>& m2); template <class BidirectionalIterator, class Allocator> bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, const match_results<BidirectionalIterator, Allocator>& m2); // 28.10.6, match_results swap:
But the details of these two bool operator functions (i.e., which members ofmatch_results should be used in comparison) are not described in anyfollowing sections.
[John adds:]
That looks like a bug:
operator==should returntrueonly ifthe two objects refer to the same match - ie if one object was constructed as acopy of the other.
[Kona (2007): Bill and Pete to add minor wording to that proposed inN2409.]
Proposed resolution:
Add a new section after 28.6.9.8[re.results.swap], which reads:
28.10.7 match_results non-member functions.
template<class BidirectionalIterator, class Allocator> bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, const match_results<BidirectionalIterator, Allocator>& m2);Returns:
trueonly if the two objects refer to the same match.
template<class BidirectionalIterator, class Allocator> bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, const match_results<BidirectionalIterator, Allocator>& m2);Returns:
!(m1 == m2).
template<class BidirectionalIterator, class Allocator> void swap(match_results<BidirectionalIterator, Allocator>& m1, match_results<BidirectionalIterator, Allocator>& m2);Returns:
m1.swap(m2).
[Bellevue: Proposed wording now in WP.]
unique_ptr andshared_ptr fail to specify non-convertibility to int for unspecified-bool-typeSection: 20.3.1.3.5[unique.ptr.single.observers], 20.3.2.2.6[util.smartptr.shared.obs]Status:NADSubmitter: Beman DawesOpened: 2007-06-14Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [unique.ptr.single.observers].
View all otherissues in [unique.ptr.single.observers].
View all issues withNAD status.
Discussion:
The standard library uses theoperatorunspecified-bool-type() const idiom infive places. In three of those places (22.10.17.3.4[func.wrap.func.cap], function capacity for example) the returned value is constrained to disallowunintended conversions to int. The standardese is
The return type shall not be convertible to
int.
This constraint is omitted forunique_ptr andshared_ptr. It should be added for those.
[Bellevue:]
Close as NAD. Accepting paperN2435makes it irrelevant.
Proposed resolution:
To theReturns paragraph foroperatorunspecified-bool-type()const of 20.3.1.3.5[unique.ptr.single.observers] paragraph 11 and 20.3.2.2.6[util.smartptr.shared.obs] paragraph 16, add the sentence:
The return type shall not be convertible to
int.
[Kona (2007): Uncertain ifnullptr will address this issue.]
Section: 29.7[c.math]Status:NAD EditorialSubmitter: Niels DekkerOpened: 2007-06-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.math].
View all issues withNAD Editorial status.
Discussion:
Quoting the latest draft (n2135), 29.7[c.math]:
The added signatures are:
long abs(long); // labs()long abs(long long); // llabs()
Shouldn'tabs(long long) havelong long as return type?
Proposed resolution:
Change 29.7[c.math]:
longlong abs(long long); // llabs()
Rationale:
Had already been fixed in the WP by the time the LWG reviewed this.
Section: 5.2.1.1 [tr1::tr.num.sf.Lnm]Status:NADSubmitter: Christopher CrawfordOpened: 2007-06-30Last modified: 2016-02-01
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
I see that the definition the associated Laguerrepolynomials 5.2.1.1 [tr1::tr.num.sf.Lnm] has been corrected sinceN1687.However, the draft standard only specifies ranks of integer valuem,while the associated Laguerre polynomials are actually valid for realvalues ofm > -1. In the case of non-integer values ofm, thedefinitionLn(m) = (1/n!)exx-m (d/dx)n (e-xxm+n)must be used, which also holds for integer values ofm. SeeAbramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 forthe integer case. In fact fractional values are most commonly used inphysics, for example tom = +/- 1/2 to describe the harmonicoscillator in 1 dimension, and1/2, 3/2, 5/2, ... in 3dimensions.
If I am correct, the calculation of the more general case is nomore difficult, and is in fact the function implemented in the GNUScientific Library. I would urge you to consider upgrading the standard, either adding extra functions for realm or switching thecurrent ones todouble.
[Batavia (2009-05):]
We understand the issue, and have opted not to extend as recommended.
Move to NAD.
Proposed resolution:
Section: 5.2.1.2 [tr1::tr.num.sf.Plm]Status:NADSubmitter: Christopher CrawfordOpened: 2007-06-30Last modified: 2016-02-01
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
One other small thing, in 5.2.1.2 [tr1::tr.num.sf.Plm], the restriction should be|x| <= 1, notx >= 0.
[Batavia (2009-05):]
The error has been corrected in the pending IS.
Move to NAD.
Proposed resolution:
exception_ptrSection: 17.9.7[propagation]Status:NADSubmitter: Jens MaurerOpened: 2007-07-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [propagation].
View all issues withNAD status.
Discussion:
From the Toronto Core wiki:
What do you mean by "null pointer constant"? How do you guarantee thatexception_ptr() == 1 doesn't work? Do you even want to prevent that?What's the semantics? What aboutvoid *p = 0; exception_ptr() == p?Maybe disallow those in the interface, but how do you do that withportable C++? Could specify just "make it work".
Peter's response:
null pointer constant as defined in 7.3.12[conv.ptr]. Intent is "just make itwork", can be implemented as assignment operator taking a unique pointerto member, as in the unspecified bool type idiom.
[Bellevue:]
Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
Even simpler now with nullptr_t.
NAD Rationale : null pointer constant is a perfectly defined term, andwhile API is clearly implementable there is no need to spell outimplementation details.
Proposed resolution:
Section: 28.3[localization]Status:NADSubmitter: Peter DimovOpened: 2007-07-28Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [localization].
View all issues withNAD status.
Discussion:
The POSIX "Extended API Set Part 4,"
introduces extensions to the C locale mechanism thatallow multiple concurrent locales to be used in the same applicationby introducing a typelocale_t that is very similar tostd::locale, and a number of_l functions that make use of it.
The global locale (set by setlocale) is now specified to be per-process. If a thread does not calluselocale, the global locale isin effect for that thread. It can install a per-thread locale byusinguselocale.
There is also a nicequerylocale mechanism by which one can obtainthe name (such as "de_DE") for a specificfacet, even for combinedlocales, with nostd::locale equivalent.
std::locale should be harmonized with the new POSIXlocale_tmechanism and provide equivalents foruselocale andquerylocale.
[Kona (2007): Bill and Nick to provide wording.]
[San Francisco: Bill and Nick still intend to provide wording, but thisis a part of the task to be addressed by the group that will look intoissue860(i).]
[2009-07 Frankfurt:]
It's our intention to stay in sync with WG14. If WG14 makes a decisionthat requires a change in WG21 the issue will be reopened.
Move to NAD Future.
[LEWG Kona 2017]
Recommend NAD:uselocale() is bad; pass locales around as objects
[Kona 2019]
Jonathan points out: The standard already allows per-thread locales, see [locale] p9.
Proposed resolution:
valarray::operator[] specification in [valarray.access]Section: 29.6.2.4[valarray.access]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-08-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.access].
View all issues withNAD Editorial status.
Discussion:
Since the return type ofvalarray'soperator[] const overload has beenchanged toconst T& as described in389(i) several paragraphs ofthe section 29.6.2.4[valarray.access] are nowincompletelyspecified, because many requirements and guarantees should now alsoapply to the const overload. Most notably, the address and referenceguarantees should be extended to the const overload case.
Proposed resolution:
Change 29.6.2.4[valarray.access]:
-1-
When applied to a constant array, the subscript operator returns areference to the corresponding element of the array. When applied to anon-constant array, tThe subscript operator returns areference to the corresponding element of the array.-3- The expression
&a[i+j] == &a[i] + jevaluates astruefor allsize_t iandsize_t jsuch thati+jis less than the length of thenon-constantarraya.-4- Likewise, the expression
&a[i] != &b[j]evaluatesastruefor any twonon-constantarraysaandband for anysize_t iandsize_t jsuch thatiis less than the length ofaandjis lessthan the length ofb. This property indicates an absence ofaliasing and may be used to advantage by optimizingcompilers.281)-5- The reference returned by the subscript operator for an
non-constantarray is guaranteed to be valid untilthe member functionresize(size_t, T)(26.5.2.7) is called for that array or until the lifetime of that array ends, whichever happens first.
basic_string is not a sequenceSection: 27.4.3[basic.string]Status:NAD EditorialSubmitter: Bo PerssonOpened: 2007-08-18Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD Editorial status.
Discussion:
Paragraph 27.4.3[basic.string]/3 states:
The class template
basic_stringconforms to the requirements for a Sequence (23.1.1) and for a Reversible Container (23.1).
First of all, 23.2.4[sequence.reqmts] is no longer "Sequence" but "Sequence container". Secondly, after the resent changes to containers (emplace,push_back,const_iterator parameters toinsert anderase),basic_string is not even close to conform to the current requirements.
[Bellevue:]
- emplace, for example, may not make sense for strings. Is also likely suboptimal
- with concepts do we need to maintain string as sequence container?
- One approach might be to say something like: string is a sequence except it doesn't have these functions
- basic_string already has push_back
- const_iterator parameters to insert and erase should be added to basic_string
- this leaves emplace to handle -- we have the following options:
- option 1: add it to string even though it's optional
- option 2: make emplace optional to sequences (move from table 89 to 90)
- option 3: say string not sequence (the proposal),
- option 4: add an exception to basic string wording.
General consensus is to suggest option 2.
[2009-07 Frankfurt:]
Move to NAD Editorial
Proposed resolution:
Remove this sentence, in recognition of the fact thatbasic_string is not just avector-light for literal types, but something quite different, a string abstraction in its own right.
wstring_convert inconsistensiesSection: 99 [depr.conversions.string]Status:NADSubmitter: Bo PerssonOpened: 2007-08-27Last modified: 2017-04-22
Priority:Not Prioritized
View all otherissues in [depr.conversions.string].
View all issues withNAD status.
Discussion:
Paragraph 3 says that theCodecvt template parameter shall meet the requirements ofstd::codecvt, even thoughstd::codecvt itself cannot be used (because of a protected destructor).
How are we going to explain this code to beginning programmers?
template<class I, class E, class S>struct codecvt : std::codecvt<I, E, S>{ ~codecvt() { }};void main(){ std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok; std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;}[San Francisco:]
Bill will propose a resolution.
[2009-07 Frankfurt:]
codecvt isn't intended for beginning programmers. This is a regrettableconsequence of the original design of the facet.
Move to NAD.
Proposed resolution:
Section: 23.2.4[sequence.reqmts]Status:NAD EditorialSubmitter: David AbrahamsOpened: 2007-09-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD Editorial status.
Discussion:
Table 90: (Optional sequence container operations) states the"assertion note pre/post-condition" ofoperator[] to be
*(a.begin() + n)
Surely that's meant to be "operational semantics?"
Proposed resolution:
Table 90: Optional sequence container operations expression return type assertion/note
pre/post-condition
operational semanticscontainer
regex_replace() overloadsSection: 28.6.10.4[re.alg.replace]Status:NADSubmitter: Stephan T. LavavejOpened: 2007-09-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.alg.replace].
View all issues withNAD status.
Discussion:
Two overloads ofregex_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);
const charT * are provided forregex_match() andregex_search(), but notregex_replace(). This is inconsistent.The absence ofconst 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 deducetemplate argument for 'const std::basic_string<_Elem> &' from 'constchar[1]'".
Users expect that anything taking abasic_string<charT> can also take aconst charT *. In their own code, when they write a function takingstd::string (orstd::wstring), they can pass aconst char * (orconstwchar_t *), thanks tobasic_string's implicit constructor. Because theregex algorithms are templated oncharT, they can't rely onbasic_string's implicit constructor (as the compiler error messageindicates, template argument deduction fails first).
If a user figures out what the compiler error message means, workaroundsare available - but they are all verbose. Explicit template argumentscould be given toregex_replace(), allowingbasic_string's implicitconstructor to be invoked - butcharT is the last template argument, notthe first, so this would be extremely verbose. Therefore, constructingabasic_string from each C string is the simplest workaround.
basic_strings canimpose performance costs that could be avoided by a libraryimplementation taking C strings and dealing with them directly. (Currently, for replacement sources, C strings can be converted intoiterator pairs at the cost of verbosity, but for format strings, thereis no way to avoid constructing abasic_string.)[Sophia Antipolis:]
We note that Boost already has these overloads. However, the proposedwording is provided only for 28.6.10.4[re.alg.replace]; wording is needed for the synopsisas 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 and727(i).]
[2009-10 Santa Cruz:]
Leave Open. Though we believe this is solved by the proposed resolutionto727(i).
[2010-01-27 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Rationale:
Proposed resolution:
Provide additional overloads forregex_replace(): one additionaloverload of the iterator-based form (takingconst charT* fmt), and threeadditional overloads of the convenience form (one takingconst charT*str, another takingconst charT* fmt, and the third taking bothconstcharT* str andconst charT* fmt). 28.6.10.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: 29.5.3.4[rand.req.eng]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req.eng].
View all issues withNAD status.
Discussion:
The 3rd table row in 29.5.3.4[rand.req.eng]/3 requires random number engines to accept any arithmetic type as a seed, which is then casted to the engine'sresult_type and subsequently used for seeding the state of the engine. The requirement stated as "Creates an engine with initial state determined bystatic_cast<X::result_type>(s)" forces random number engines to either use a seeding method that completely depends on theresult_type (see the discussion of seeding for themersenne_twister_engine in point T2 above) or at least to throw away "bits of randomness" in the seed value if theresult_type is smaller than the seed type. This seems to be inappropriate for many modern random number generators, in particular F2-linear or cryptographic ones, which operate on an internal bit array that in principle is independent of the type of numbers returned.
Possible resolution: I propose to change the wording to a version similar to "Creates an engine with initial state determined bystatic_cast<UintType>(s), whereUintType is an implementation specific unsigned integer type."
Additionally, the definition of s in 29.5.3.4[rand.req.eng]/1 c) could be restricted to unsigned integer types.
Similarly, the type of the seed in 29.5.3.5[rand.req.adapt]/3 e) could be left unspecified.
SeeN2424for further discussion.
[Stephan Tolksdorf adds pre-Bellevue:]
In reply to the discussion inN2424regarding this issue:
The descriptions of all engines and engine adaptors given in sections29.5.4[rand.eng] and 29.5.5[rand.adapt] already specify the concretetypes of the integer arguments for seeding. Hence, relaxing the generalrequirement in 29.5.3.4[rand.req.eng] would not affect portability andreproducibility of the standard library. Furthermore, it is not clear tome what exactly the guarantee "with initial state determined by
static_cast<X::result_type>(s)" is useful for. On the other hand,relaxing the requirement would allow developers to implement otherrandom number engines that do not have to cast all arithmetic seedarguments to their result_types.
[Bellevue:]
Propose close NAD for the reasons given in N2424.
Proposed resolution:
SeeN2424for further discussion.
[Stephan Tolksdorf adds pre-Bellevue:]
Change row 3 of table 105 "Random number engine requirements" in 29.5.3.4[rand.req.eng]/3
Creates an engine with initial state determined by
static_cast<X::result_type>(s)Similarly, change 29.5.3.5[rand.req.adapt]/3 e)
When
X::Xis invoked withanvalueX::result_typesof arithmetic type (3.9.1), ...
Section: 29.5.3.5[rand.req.adapt]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
If an engine adaptor is invoked with an argument of typeseed_seq, then all base engines are specified to be seeded with thisseed_seq. Asseed_seq's randomization method is qualified as constant, this procedure will ef fectively initialize all base engines with the same seed (though the resulting state might still dif fer to a certain degree if the engines are of different types). It is not clear whether this mode of operation is in general appropriate, hence -- as far as the stated requirements are of general nature and not just specific to the engine adaptors provided by the library -- it might be better to leave the behaviour unspecified, since the current definition ofseed_seq does not allow for a generally satisfying specification.
Posssible resolution: [As above]
SeeN2424for further discussion.
[Bellevue:]
Close NAD for the reasons given in N2424.
Proposed resolution:
SeeN2424for the proposed resolution.
seed_seqSection: 29.5.8.1[rand.util.seedseq]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.util.seedseq].
View all issues withNAD status.
Discussion:
The proper way to seed random number engines seems to be the most frequently discussed issue of the 29.5[rand] proposal. While the newseed_seq approach is already rather general and probably sufficient for most situations, it is unlikely to be optimal in every case (one problem was pointed out in point T5 above). In some situations it might, for instance, be better to seed the state with a cryptographic generator.
In my opinion this is a pretty strong argument for extending the standard with a simple facility to customize the seeding procedure. This could, for example, be done with the following minimal changes:
Possible resolution:
seed_seq as a default implementation of the SeedSeq interface.Supplement theseed_seq with a traits class
template <typename T> struct is_seed_seq { static const bool value = false; }and the specialization
template <> struct is_seed_seq<seed_seq> { static const bool value = true; }which users can supplement with further specializations.
[Bellevue:]
See N2424. Close NAD but note that "conceptizing" the library may causethis problem to be solved by that route.
Proposed resolution:
SeeN2424for the proposed resolution.
Section: 29.5.3.6[rand.req.dist]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req.dist].
View all issues withNAD status.
Discussion:
The requirement "P shall have a declaration of the formtypedef X distribution_- type" effectively makes the use of inheritance for implementing distributions very inconvenient, because the child of a distribution class in general will not satisfy this requirement. In my opinion the benefits of having a typedef in the parameter class pointing back to the distribution class are not worth the hassle this requirement causes. [In my code base I never made use of the nested typedef but on several occasions could have profited from being able to use simple inheritance for the implementation of a distribution class.]
Proposed resolution: I propose to drop this requirement.
[Bellevue:]
Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
Proposed resolution:
SeeN2424for the proposed resolution.
Section: 29.5.9.3.2[rand.dist.bern.bin], 29.5.9.3.4[rand.dist.bern.negbin]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
In my opinion the choice of name for thet parameter of thebinomial_distributionis very unfortunate. In virtually every internet reference, book and software implementation this parameter is calledn instead, see for example Wikipedia, Mathworld, Evans et al. (1993) Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, Mathematica and Matlab.
Similarly, the choice ofk for the parameter of the negative binomial distributions is rather unusual. The most common choice for the negative binomial distribution seems to ber instead.
Choosing unusual names for the parameters causes confusion among users and makes the interface unnecessarily inconvenient to use.
Possible resolution: For these reasons, I propose to change the name of the respective parameterston andr.
[Bellevue:]
In N2424. NAD It has been around for a while. It is hardly universal,there is prior art, and this would confuse people.
Proposed resolution:
SeeN2424for the proposed resolution.
Section: 29.5.9.6.1[rand.dist.samp.discrete]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.samp.discrete].
View all issues withNAD status.
Discussion:
discrete_distribution requires the memberprobabilities()to return a vector ofstandardized probabilities, which forces the implementation every time to divide each probability by the sum of all probabilities, as the sum will in practice almost never be exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to compute the standardized probabilities at all and could instead work with the non-standardized probabilities and the sum. If there was no standardization the user would just get back the probabilities that were previously supplied to the distribution object, which to me seems to be the more obvious solution.discrete_distribution is not specified in case the number of givenprobabilities is larger than the maximum number representable by the IntType.Possible resolution: I propose to change the specification such that the non-standardized probabilities need to be returned and that an additional requirement is included for the number of probabilities to be smaller than the maximum of IntType.
[Stephan Tolksdorf adds pre-Bellevue:]
In reply to the discussion inN2424of this issue:
Rescaled floating-point parameter vectors can not be expected to compareequal because of the limited precision of floating-point numbers.My proposal would at least guarantee that a parametervector (of type double) passed into the distribution would compare equalwith the one returned by the
probabilities()method. Furthermore, I donot understand why "the changed requirement would lead to a significantincrease in the amount of state in the distribution object". A typicalimplementation's state would increase by exactly one number: the sum ofall probabilities. The textual representation for serialization wouldnot need to grow at all. Finally, the proposed replacement "0 < n <=numeric_limits<IntType>::max() + 1" makes the implementationunnecessarily complicated, "0 < n <= numeric_limits<IntType>::max()"would be better.
[Bellevue:]
In N2424. We agree with the observation and the proposed resolution topart b). We recommend the wording n > 0 be replaced with 0 < nnumeric_limits::max() + 1. However, we disagree with part a), as itwould interfere with the definition of parameters' equality. Further,the changed requirement would lead to a significant increase in theamount of state of the distribution object.
As it stands now, it is convenient, and the changes proposed make itmuch less so.
NAD. Part a the current behavior is desirable. Part b, any constructorcan fail, but the rules under which it can fail do not need to be listedhere.
Proposed resolution:
SeeN2424for the proposed resolution.
[Stephan Tolksdorf adds pre-Bellevue:]
In 29.5.9.6.1[rand.dist.samp.discrete]:
Proposed wording a):
Change in para. 2
Constructs a
discrete_distributionobject withn=1andp0= w0 = 1and change in para. 5
Returns: A
vector<double>whosesizemember returnsnand whoseoperator[]member returnsthe weightpkwkas a double valuewhen invoked with argumentkfork = 0,..., n-1Proposed wording b):
Change in para. 3:
If
firstW == lastW, let the sequencewhave lengthn = 1and consistof the single valuew0 = 1. Otherwise,[firstW,lastW)shall form asequencewof lengthnsuch that> 00 < n <= numeric_limits<IntType>::max(),and*firstWshall yield a valuew0convertible todouble. [Note: The valueswkare commonly knownas the weights .-- end note]
Section: 29.5.9.6.2[rand.dist.samp.pconst]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.samp.pconst].
View all issues withNAD status.
Discussion:
probabilities() similarly applies to the methoddensities() ofpiecewise_constant_distribution.The design of the constructor
template <class InputIteratorB, class InputIteratorW> piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, InputIteratorW firstW);
is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see any performance or convenience reasons that would justify the risks inherent in such a function interface, in particular the risk that input error might go unnoticed.
Possible resolution: I propose to add anInputIteratorW lastW argument to the interface.
[Stephan Tolksdorf adds pre-Bellevue:]
In reply to the discussion inN2424I'd like to make the same comments as for736(i).
[Bellevue:]
In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
Proposed resolution:
SeeN2424for the proposed resolution.
[Stephan Tolksdorf adds pre-Bellevue:]
In 29.5.9.6.2[rand.dist.samp.pconst]:
Proposed wording a)
Change in para. 2
Constructs a
piecewise_constant_distributionobject withn = 1,p0= w0 = 1,b0 = 0, andb1 = 1and change in para. 5
A
vector<result_type>whosesizemember returnsnand whoseoperator[]member returnsthe weightpkwkas a double valuewhen invoked with argumentkfork = 0, ..., n-1Proposed wording b)
Change both occurrences of
"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB, InputIteratorW firstW, InputIteratorW lastW)and change in para. 3
the length of the sequencewstarting fromfirstWshall be at leastn,*firstWshall return a valuew0that is convertible todouble, and anywkfork >= nshall be ignored by the distribution[firstW, lastW)shall form a sequencewof lengthnwhose leading elementw0shall be convertible todouble
Section: 29.5.5.2[rand.adapt.disc]Status:NAD EditorialSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.adapt.disc].
View all issues withNAD Editorial status.
Discussion:
Since the template parameterp andr are of typesize_t, the membern in the class exposition should have typesize_t, too.
Proposed resolution:
SeeN2424for the proposed resolution.
Section: 29.5.8.2[rand.util.canonical]Status:NADSubmitter: Stephan TolksdorfOpened: 2007-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.util.canonical].
View all issues withNAD status.
Discussion:
The complexity ofgenerate_canonical is specified to be "exactly k=max(1, ceil(b/log2 R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in general) be computed at compile time. As this function template is performance critical, I propose to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
SeeN2424for further discussion.
[Bellevue:]
In N2424. Close NAD as described there.
Proposed resolution:
SeeN2424for the proposed resolution.
get_deleter function forshared_ptrSection: 20.3.2.2.11[util.smartptr.getdeleter]Status:NADSubmitter: Daniel KrüglerOpened: 2007-09-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [util.smartptr.getdeleter].
View all issues withNAD status.
Discussion:
The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
According to the recent draft N2369, both the header memory synopsisof 20.2[memory] and 20.3.2.2.11[util.smartptr.getdeleter] declare:
template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
This allows to retrieve the pointer to a mutable deleter of aconstshared_ptr (if that owns one) and therefore contradicts the usualphilosophy that associated functors are either read-only (e.g.key_comp orvalue_comp ofstd::map) or do at least reflectthe mutability of the owner (as seen for the both overloads ofunique_ptr::get_deleter).Even the next similar counter-part ofget_deleter - the twooverloads offunction::target in the class template functionsynopsis 22.10.17.3[func.wrap.func] or in 22.10.17.3.6[func.wrap.func.targ] - doproperly mirror the const-state of the owner.
Possible proposed resolutions:
Replace the declarations ofget_deleter in the header<memory>synopsis of 20.2[memory] and in 20.3.2.2.11[util.smartptr.getdeleter] by one of thefollowing alternatives (A) or (B):
container::get_allocator(),map::key_comp(), ormap::value_comp.template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
Alberto Ganesh Barbati adds:
Replace it with two functions:
template <class D, class T> D get_deleter(shared_ptr<T> const&);template <class D, class T> bool has_deleter(shared_ptr<T> const&);
The first one would throw ifD is the wrong type, while the latter wouldnever throw. This approach would reflect the current praxis ofuse_facet/has_facet, with the twist of returning the deleter by value ascontainer::get_allocator() do.
Peter Dimov adds:
My favorite option is "not a defect". A, B and C break useful code.
[Bellevue:]
Concern this is similar to confusing "pointer to const" with "a constant pointer".
Proposed resolution:
Section: 17.9.7[propagation]Status:NADSubmitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [propagation].
View all issues withNAD status.
Discussion:
It could be I did not understand the design rationale, but I thoughtcopy_exception would produce an exception_ptr to the most-derived (dynamic)type of the passed exception. Instead it slices, which appears to be lessuseful, and a likely source of FAQ questions in the future.
(Peter Dimov suggests NAD)
[Bellevue: ]
How could this be implemented in a way that the dynamic type is cloned?
The feature is designed to create an exception_ptr from an object whosestatic type is identical to the dynamic type and thus there is noslicing involved.
Proposed resolution:
Section: 21.3.6.4[meta.unary.prop]Status:NADSubmitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.unary.prop].
View all otherissues in [meta.unary.prop].
View all issues withNAD status.
Discussion:
We have 3 separate type traits to identify classes supporting no-throwoperations, which are very useful when trying to provide exception safetyguarantees. However, I'm not entirely clear on what the current wordingrequires of a conforming implementation. To quote fromhas_nothrow_default_constructor:
or
Tis a class type with a default constructor that is known not to throwany exceptions
What level of magic do we expect to deduce if this is known?
E.g.
struct test{ int x; test() : x() {}};Should I expect a conforming compiler toassert( has_nothrow_constructor<test>::value )
Is this a QoI issue?
Should I expect to 'know' only if-and-only-if there is an inline definitionavailable?
Should I never expect that to be true, and insist that the user supplies anempty throw spec if they want to assert the no-throw guarantee?
It would be helpful to maybe have a footnote explaining what is required,but right now I don't know what to suggest putting in the footnote.
(agreement since is that trivial ops and explicit no-throws are required.Open if QoI should be allowed to detect further)
[Bellevue:]
This looks like a QoI issue.In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.Move to OPEN. Need to talk to Core about this.
[2009-07 Frankfurt:]
This is QoI.
Move to NAD.
Proposed resolution:
Section: 21.3.6.4[meta.unary.prop]Status:NADSubmitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.unary.prop].
View all otherissues in [meta.unary.prop].
View all issues withNAD status.
Discussion:
I am trying to decide is a pure virtual function is anecessary as well assufficient requirement to be classified as abstract?
For instance, is the following (non-polymorphic) type considered abstract?
struct abstract {protected: abstract(){} abstract( abstract const & ) {} ~abstract() {}};(Suggested that this may be NAD, with an editorial fix-up from Pete on thecore wording to make clear that abstract requires a pure virtual function)
Proposed resolution:
Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
is_convertible requires that the type beimplicitly convertible, so explicit constructors are ignored.Section: 21.3.8[meta.rel]Status:DupSubmitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.rel].
View all otherissues in [meta.rel].
View all issues withDup status.
Duplicate of:719
Discussion:
With the pending arrival of explicit conversion functions though, I'mwondering if we want an additional trait,is_explictly_convertible?
[Bellevue:]
Alisdair is considering preparing a paper listing a number of missingtype traits, and feels that it might be useful to handle them alltogether rather than piecemeal. This would affect issue 719 and 750.These two issues should move to OPEN pending AM paper on type traits.
[2009-07 Frankfurt:]
[Addressed inN2947.]
Proposed resolution:
vector<bool> to pass-by-value?Section: 23.3.14[vector.bool]Status:NADSubmitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [vector.bool].
View all issues withNAD status.
Discussion:
A number ofvector<bool> members take const bool& as arguments.Is there any chance we could change them to pass-by-value or would I be wasting everyone's time if wrote up an issue?
[post Bellevue:]
As we understand it, the original requester (Martin Sebor) would likefor implementations to be permitted to pass-by-value. Alisdair suggeststhat if this is to be resolved, it should be resolved more generally,e.g. in other containers as well.
We note that this would break ABI. However, we also suspect that thismight be covered under the "as-if" rule in section 1.9.
Many in the group feel that for vector<bool>, this is a "don't care",and that at this point in the process it's not worth the bandwidth.
Issue679(i) -- which was in ready status pre-Bellevue and isnow in the working paper -- is related to this, though not a duplicate.
Moving to Open with a task for Alisdair to craft a informative note tobe put whereever appropriate in the WP. This note would clarify placeswhere pass-by-const-ref can be transformed to pass-by-value under theas-if rule.
[San Francisco:]
This is really a clause 17 issue, rather than something specific to vector<bool>.
Move to Open. Alisdair to provide a resolution. Alternately, Howard canclose this as NAD and then open a new issue to handle the general issue(rather than the vector<bool> one).
Howard: Haven't yet opened new issue. Lacking wording for it.
[2009-07 Frankfurt:]
NAD. Insufficient motivation to make any changes.
Proposed resolution:
std::uninitialized_copySection: 26.11.5[uninitialized.copy]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2007-10-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [uninitialized.copy].
View all issues withNAD Editorial status.
Discussion:
14882-2003, [lib.uninitialized.copy] is currently written as follows:
template <class InputIterator, class ForwardIterator> ForwardIterator uninitialized_copy(InputIteratorfirst, InputIteratorlast, ForwardIteratorresult);-1-Effects:
for (; first != last; ++result, ++first) new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);-2-Returns:
result
similarily for N2369, and its corresponding section26.11.5[uninitialized.copy].
It's not clear to me what the return clause is supposed to mean, I seetwopossible interpretations:
result is supposed to mean the value given by thefunction parameterresult [Note to the issue editor: Please use italics forresult].This seems somewhat implied by recognizing that both the functionparameterand the name used in the clause do have the same italic font.resultafter thepreceding effects clause. This is in fact what all implementations Icheckeddo (and which is probably it's intend, because it matches thespecification ofstd::copy).The problem is: I see nothing in the standard which grants that thisinterpretationis correct, specifically [lib.structure.specifications] or16.3.2.4[structure.specifications]resp. do not clarify which "look-up" rules apply for names found inthe elementsof the detailed specifications - Do they relate to the correspondingsynopsis orto the effects clause (or possibly other elements)? Fortunately mostdetaileddescriptions are unambigious in this regard, e.g. this problem doesnot applyforstd::copy.
Proposed resolution:
Change the wording of the return clause to say (26.11.5[uninitialized.copy]):
-2-Returns:The value of
resultafter effects have taken place.
[Bellevue:]
Resolution: NAD editorial -- project editor to decide if change isworthwhile. Concern is that there are many other places this mightoccur.
Section: 23.3.13[vector]Status:NAD EditorialSubmitter: Paolo CarliniOpened: 2007-11-04Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [vector].
View all issues withNAD Editorial status.
Discussion:
In the synopsis 23.3.13[vector], there is the signature:
void insert(const_iterator position, size_type n, T&& x);
instead of:
iterator insert(const_iterator position, T&& x);
23.3.13.5[vector.modifiers] is fine.
Proposed resolution:
Change the synopsis in 23.3.13[vector]:
iterator insert(const_iterator position, const T& x);iterator insert(const_iterator position, T&& x);void insert(const_iterator position, size_type n, const T& x);void insert(const_iterator position, size_type n, T&& x);
Section: 23.2[container.requirements]Status:NADSubmitter: Paolo CarliniOpened: 2007-11-11Last modified: 2017-07-17
Priority:2
View all otherissues in [container.requirements].
View all issues withNAD status.
Discussion:
In anemplace member function the function parameter pack may be boundto a priori unlimited number of objects: some or all of them can beelements of the container itself. Apparently, in order to conform to theblanket statement 23.2[container.requirements]/11, theimplementation must check all of them for that possibility. A possiblesolution can involve extending the exception in 23.2[container.requirements]/12 also to the emplace member. As aside note, thepush_back andpush_front memberfunctions are luckily not affected by this problem, can be efficientlyimplemented anyway.
[Related to767(i) and to2164(i)]
[Bellevue:]
The proposed addition (13) is partially redundant with the existingparagraph 12. Why was the qualifier "rvalues" added to paragraph 12? Whydoes it not cover subelements and pointers?
Resolution: Alan Talbot to rework language, then set state to Review.
[2009-07 Frankfurt]
The problem is broader than
emplace. The LWG doesn'tfeel that it knows how to write wording that prohibits all of theproblematic use cases at this time.NAD Future.
[2015-02 Cologne]
LWG believes that2164(i) addresses this issue and therefore considers760(i) as NAD.
Proposed resolution:
Add after 23.2[container.requirements]/12:
-12- Objects passed to member functions of a container as rvaluereferences shall not be elements of that container. No diagnosticrequired.
-13- Objects bound to the function parameter pack of the
emplacemember function shall not be elements or sub-objects ofelements of the container. No diagnostic required.
emplace() overloadsSection: 23.2.7[associative.reqmts]Status:NADSubmitter: Sylvain PionOpened: 2007-12-04Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
The associative containers provide 2 overloads ofemplace():
template <class... Args> pair<iterator, bool> emplace(Args&&... args);template <class... Args> iterator emplace(const_iterator position, Args&&... args);
This is a problem if you mean the first overload while passingaconst_iterator as first argument.
[Bellevue:]
This can be disambiguated by passing "begin" as the first argument inthe case when the non-default choice is desired. We believe that desirewill be rare.
[For related discussion see1302(i)]
LWGN2680 renamed one of the overloads toemplace_hint.
Resolution: Change state to NAD.
Proposed resolution:
Rename one of the two overloads.For example toemplace_here,hint_emplace...
equal_range on unordered containers should return apair oflocal_iteratorsSection: 23.2.8[unord.req]Status:NADSubmitter: Joe GottmanOpened: 2007-11-29Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
A major attribute of the unordered containers is that iterating though them inside a bucket is very fast while iterating between buckets can be much slower. If an unordered container has a low load factor, iterating between the last iterator in one bucket and the next iterator, which is in another bucket, isO(bucket_count()) which may be much larger thanO(size()).
Ifb is an non-const unordered container of typeB andk is an object of it'skey_type, thenb.equal_range(k) currently returnspair<B::iterator, B::iterator>. Consider the following code:
B::iterator lb, ub;tie(lb, ub) = b.equal_range(k);for (B::iterator it = lb; it != ub; ++it) { // Do something with *it}Ifb.equal_range(k) returns a non-empty range (i.e.b contains at least on element whose key is equivalent tok), then every iterator in the half-open range[lb, ub) will be in the same bucket, butub will likely either be in a different bucket or be equal tob.end(). In either case, iterating betweenub - 1 andub could take a much longer time than iterating through the rest of the range.
If instead of returningpair<iterator, iterator>,equal_range were to returnpair<local_iterator, local_iterator>, thenub (which, likelb, would now be alocal_iterator) could be guaranteed to always be in the same bucket aslb. In the cases where currentlyub is equal tob.end()or is in a different bucket,ub would be equal tob.end(b.bucket(key)). This would make iterating betweenlb andub much faster, as every iteration would be constant time.
[Bellevue:]
The proposed resolution breaks consistency with other container typesfor dubious benefit, and iterators are already constant time.
Proposed resolution:
Change the entry forequal_range in Table 93 (23.2.8[unord.req]) as follows:
| expression | return type | assertion/note pre/post-condition | complexity |
|---|---|---|---|
b.equal_range(k) | pair<local_iterator,local_iterator>; pair<const_local_iterator,const_local_iterator> forconst b. | Returns a range containing all elements with keys equivalent tok. Returnsmake_pair(b.end(b.bucket(key)),b.end(b.bucket(key))) if no such elements exist. | Average case Θ(b.count(k)). Worst case Θ(b.size()). |
Section: 29.5.9.2[rand.dist.uni]Status:NADSubmitter: P.J. PlaugerOpened: 2008-01-14Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.uni].
View all issues withNAD status.
Discussion:
uniform_int constructor has changed the defaultmax constructor parameter from 9 (in TR1) tomax(). The valueis arbitrary at best and shouldn't be lightly changed becauseit breaks backward compatibility.uniform_int has a parameterparam that you canprovide on construction oroperator(), set, and get. But thereis not even a hint of what this might be for.uniform_real. Same issue as #2.[Bellevue:]
NAD. Withdrawn.
Proposed resolution:
Section: 32.6.5.4.4[thread.lock.unique.mod]Status:NADSubmitter: Constantine SapuntzakisOpened: 2008-02-02Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
unique_lock::release will probably lead to many mistakes where peoplecallrelease instead ofunlock. I just coded such a mistake using theboost pre-1.35 threads library last week.
In many threading libraries, a call withrelease in it unlocks thelock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
I don't callunique_lock::lock much at all, so I don't get to see thesymmetry between::lock and::unlock. I usually use the constructor tolock the mutex. So I'm left to remember whether to callrelease orunlock during the few times I need to release the mutex before the scopeends. If I get it wrong, the compiler doesn't warn me.
An alternative name for release may bedisown.
This might be a rare case where usability is hurt by consistency withthe rest of the C++ standard (e.g.std::auto_ptr::release).
[Bellevue:]
Change a name from release to disown. However prior art uses the releasename. Compatibility with prior art is more important that any possiblebenefit such a change might make. We do not see the benefit forchanging. NAD
Proposed resolution:
Change the synopsis in 32.6.5.4[thread.lock.unique]:
template <class Mutex> class unique_lock { public: ... mutex_type*releasedisown(); ...};Change 32.6.5.4.4[thread.lock.unique.mod]:
mutex_type *releasedisown();
Section: 5.1.4.5 [tr1::tr.rand.eng.disc], 5.1.4.6 [tr1::tr.rand.eng.xor]Status:NADSubmitter: John MaddockOpened: 2008-01-15Last modified: 2016-02-01
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Table 16 of TR1 requires that all Pseudo Random Number generators have a
seed(integer-type s)
member function that is equivalent to:
mygen = Generator(s)
But the generatorsxor_combine anddiscard_block have no such seed member, only the
template <class Gen>seed(Gen&);
member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
So... is this a bug in TR1?
This is a real issue BTW, since the Boost implementation does adhere to the requirements of Table 16, while at least one commercial implementation does not and follows a strict adherence to sections 5.1.4.5 and 5.1.4.6 instead.
[Jens adds:]
Both engines do have the necessaryconstructor, therefore the omission of the
seed()memberfunctions appears to be an oversight.
[Post Summit Daniel adds:]
Recommend NAD:
xor_combinedoes no longer exist anddiscard_block[_engine]has now the required seed overload accepting aresult_type, which shall be anunsigned integral type.
[Batavia (2009-05):]
Move to NAD as recommended.
Proposed resolution:
NAD Recommended.
xor_combine::seed not specifiedSection: 99 [rand.adapt.xor]Status:NADSubmitter: P.J. PlaugerOpened: 2008-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.adapt.xor].
View all issues withNAD status.
Discussion:
xor_combine::seed(result_type) andseed(seed_seq&) don't say whathappens to each of the sub-engine seeds. (Should probably do the sameto both, unlike TR1.)
[Bellevue:]
Overcome by the previous proposal. NAD mooted by resolution of789(i).
Proposed resolution:
piecewise_constant_distribution::densities has wrong nameSection: 29.5.9.6.2[rand.dist.samp.pconst]Status:NADSubmitter: P.J. PlaugerOpened: 2008-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.samp.pconst].
View all issues withNAD status.
Discussion:
piecewise_constant_distribution::densities() should beprobabilities(),just likediscrete_distribution. (There's no real use for weights dividedby areas.)
[Bellevue:]
Fermilab does not agree with this summary. As defined in the equation in26.4.8.5.2/4, the quantities are indeed probability densities notprobabilities. Because we view this distribution as a parameterizationof a *probability density function*, we prefer to work in terms ofprobability densities.
We don't think this should be changed.
If there is a technical argument about why the implementation dealingwith these values can't be as efficient as one dealing withprobabilities, we might reconsider. We don't care about this one memberfunction being somewhat more or less efficient; we care about the sizeof the distribution object and the speed of the calls to generatevariates.
Proposed resolution:
Change synopsis in 29.5.9.6.2[rand.dist.samp.pconst]:
template <class RealType = double> class piecewise_constant_distribution { public: ... vector<double>densitiesprobabilities() const; ...};Change 29.5.9.6.2[rand.dist.samp.pconst]/6:
vector<double>densitiesprobabilities() const;
general_pdf_distribution should be droppedSection: 99 [rand.dist.samp.genpdf]Status:DupSubmitter: P.J. PlaugerOpened: 2008-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.dist.samp.genpdf].
View all issues withDup status.
Duplicate of:732
Discussion:
general_pdf_distribution should be dropped. (It's a research topic inadaptive numerical integration.)
[Stephan Tolksdorf notes:]
Proposed resolution:
ranlux48_base returns wrong valueSection: 29.5.6[rand.predef]Status:NADSubmitter: P.J. PlaugerOpened: 2008-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.predef].
View all issues withNAD status.
Discussion:
The 10,000th value returned byranlux48_base is supposed to be61839128582725. We get 192113843633948. (Note that the underlyinggenerator was changed in Kona.)
[Bellevue:]
Submitter withdraws defect.
Proposed resolution:
Change 29.5.6[rand.predef]/p5:
typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12> ranlux48_base;Required behavior: The 10000th consecutive invocation of a default-constructedobject of type
ranlux48_baseshall produce the value61839128582725192113843633948.
ranlux48 returns wrong valueSection: 29.5.6[rand.predef]Status:NADSubmitter: P.J. PlaugerOpened: 2008-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.predef].
View all issues withNAD status.
Discussion:
The 10,000th value returned byranlux48 is supposed to be249142670248501. We get 88229545517833. (Note that this dependsonranlux48_base.)
[Bellevue:]
Submitter withdraws defect.
Proposed resolution:
Change 29.5.6[rand.predef]/p6:
typedef discard_block_engine<ranlux48_base, 389, 11> ranlux48Required behavior: The 10000th consecutive invocation of a default-constructedobject of type
ranlux48shall produce the value24914267024850188229545517833.
Section: 29.5.4.3[rand.eng.mers], 99 [tr.rand.eng.mers]Status:NADSubmitter: Stephan TolksdorfOpened: 2008-02-18Last modified: 2023-05-24
Priority:Not Prioritized
View all otherissues in [rand.eng.mers].
View all issues withNAD status.
Discussion:
99 [tr.rand.eng.mers](10) requires thatoperator== for themersenne_twisterreturnstrue if and only if the states of twomersenne_twisters,consisting each ofn integers between0 and2w - 1, are completelyequal. This is a contradiction with 99 [tr.rand.req](3) because the givendefinition of the state also includes the lowerr bits ofx(i-n), whichwill never be used to generate a random number. If twomersenne_twistersonly differ in the lower bits ofx(i-n) they will not compare equal,although they will produce an identical sequence of random numbers.
29.5.4.3[rand.eng.mers] in the latest C++ draft does not specify the behaviourofoperator== but uses a similar definition of the state and, just like99 [tr.rand.eng.mers], requires the textual representation of amersenne_twister_engine to consist ofXi-n toXi-1, including thelower bits ofXi-n. This leads to two problems: First, theunsuspecting implementer is likely to erroneously compare the lowerrbits ofXi-n inoperator==. Second, if only the lowerr bits differ,twomersenne_twister_engines will compare equal (if correctlyimplemented) but have different textual representations, whichconceptually is a bit ugly.
I propose that a paragraph or footnote is added to 29.5.4.3[rand.eng.mers] whichclarifies that the lowerr bits ofXi-n are not to be compared inoperator== andoperator!=. It would only be consequent if furthermorethe specification for the textual respresentation was changed toXi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), ..., Xi-1 orsomething similar.
These changes would likely have no practical effect, but would allow animplementation that does the right thing to be standard-conformant.
[Bellevue:]
Fermi Lab has no objection to the proposed change. However it feels thatmore time is needed to check the details, which would suggest a changeto REVIEW.
Bill feels that this is NAD, not enough practical importance to abandonthe simple definition of equality, and someone would have to do a lotmore study to ensure that all cases are covered for a very smallpayback. The submitter admits that "These changes would likely have nopractical effect,", and according to Plum's razor this means that it isnot worth the effort!
Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
Proposed resolution:
In 29.5.4.3[rand.eng.mers]:
Insert at the end of para 2.:
[Note: The lower
rbits ofXi-ndo not influencethe state transition and hence should not be compared when comparing twomersenne_twister_engineobjects.-- end note]In para 5. change:
The textual representation of
xiconsists of the values ofXi-nbitand ((2w - 1) - (2r - 1)), Xi-(n-1),..., Xi-1, in that order.
knuth_b returns wrong valueSection: 29.5.6[rand.predef]Status:NADSubmitter: P.J. PlaugerOpened: 2008-02-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.predef].
View all issues withNAD status.
Discussion:
The 10,000th value returned byknuth_b is supposed to be1112339016. We get 2126698284.
Proposed resolution:
Change 29.5.6[rand.predef]/p8:
typedef shuffle_order_engine<minstd_rand0, 256> knuth_b;Required behavior: The 10000th consecutive invocation of a default-constructedobject of type
knuth_bshall produce the value11123390162126698284.
[Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.]
Section: 26.8.2[alg.sort]Status:NAD EditorialSubmitter: Paul McKenneyOpened: 2008-02-27Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Multi-threading is a good thing, but unsolicited multi-threading canpotentially be harmful. For example,sort() performance might begreatly increased via a multithreaded implementation. However, sucha multithreaded implementation could result in concurrent invocationsof the user-supplied comparator. This would in turn result in problemsgiven a caching comparator that might be written for complex sort keys.Please note that this is not a theoretical issue, as multithreadedimplementations ofsort() already exist.
Having a multithreadedsort() available is good, but it should notbe the default for programs that are not explicitly multithreaded.Users should not be forced to deal with concurrency unless they haveasked for it.
[This may be covered byN2410Thread-Safety in the Standard Library (Rev 1).]
Proposed resolution:
Rationale:
This is already covered by 17.6.5.6/20 in N2723.
CopyConstructibleSection: 16.4.4.2[utility.arg.requirements]Status:NADSubmitter: James KanzeOpened: 2008-04-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility.arg.requirements].
View all issues withNAD status.
Discussion:
I just noticed that the following program is legal in C++03, butis forbidden in the current draft:
#include <vector>#include <iostream>class Toto{public: Toto() {} explicit Toto( Toto const& ) {}} ;intmain(){ std::vector< Toto > v( 10 ) ; return 0 ;}Is this change intentional? (And if so, what is thejustification? I wouldn't call such code good, but I don't seeany reason to break it unless we get something else in return.)
[San Francisco:]
The subgroup that looked at this felt this was a good change, but it mayalready be handled by incoming concepts (we're not sure).
[Post Summit:]
Alisdair: Proposed resolution kinda funky as these tables no longerexist. Move from direct init to copy init. Clarify with Doug, recommendsNAD.
Walter: Suggest NAD via introduction of concepts.
Recommend close as NAD.
[2009-07 Frankfurt:]
Need to look at again without concepts.
[2009-07 Frankfurt:]
Move to Ready with original proposed resolution.
[Howard: Original proposed resolution restored.]
[2010-11 Batavia:]
This issue was re-reviewed in relation to [another issue, number to follow],and the verdict was reversed. Explicit copy and move constructors are rarebeasts, and the ripple effect of this fix was far more difficult to containthan simply saying such types do not satisfy theMoveConstructibleandCopyConstructible requirements.
In 16.4.4.2[utility.arg.requirements] change Table 33:
MoveConstructiblerequirements [moveconstructible]:
expression post-condition T t(rv)= rvtis equivalent to the value ofrvbefore the construction... In 16.4.4.2[utility.arg.requirements] change Table 34:
CopyConstructiblerequirements [copyconstructible]:
expression post-condition T t(u)= uthe value of uis unchanged and is equivalent tot...
Proposed resolution:
Resolved byn3215.
%'d, or rather, lack thereof?Section: 28.3.4.3.3[locale.nm.put]Status:NADSubmitter: Peter DimovOpened: 2008-04-07Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
In the spirit ofprintf vs iostream...
POSIXprintf says that%'d should insert grouping characters (and theimplication is that in the absence of' no grouping characters areinserted). Thenum_put facet, on the other hand, seems to always insertgrouping characters. Can this be considered a defect worth fixing forC++0x? Maybeios_base needs an additional flag?
[Pablo Halpern:]
I'm not sure it constitutes a defect, but I would be in favor of addinganother flag (and corresponding manipulator).
[Martin Sebor:]
I don't know if it qualifies as a defect but I agree that thereshould be an easy way to control whether the thousands separatorshould or shouldn't be inserted. A new flag would be in line withthe current design of iostreams (like
boolalpha,showpos, orshowbase).
[Sophia Antipolis:]
This is not a part of C99. LWG suggests submitting a paper may be appropriate.
Proposed resolution:
Section: 27.2[char.traits]Status:NAD EditorialSubmitter: Dietmar KühlOpened: 2008-04-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [char.traits].
View all issues withNAD Editorial status.
Discussion:
Paragraph 4 of 27.2[char.traits] mentions that this section specifies two specializations (char_traits<char> and (char_traits<wchar_t>). However, there are actually four specializations provided, i.e. in addition to the two above alsochar_traits<char16_t> andchar_traits<char32_t>). I guess this was just an oversight and there is nothing wrong with just fixing this.
[Alisdair adds:]
char_traits< char16/32_t >should also be added to<ios_fwd>in 31.3[iostream.forward], and all the specializationstaking achar_traitsparameter in that header.
[Sophia Antipolis:]
Idea of the issue is ok.
Alisdair to provide wording, once that wording arrives, move to review.
[2009-05-04 Alisdair adds:]
The main point of the issue was resolved editorially inN2723,so we areclose to NAD Editorial.However, exploring the issue we found a second tweak was necessary for
<iosfwd>and that is still outstanding, so here are the words I am longoverdue delivering:[Howard: I've put Alisdair's words into the proposed wording section andmoved the issue to Review.]
[Original proposed wording.]
Replace paragraph 4 of 27.2[char.traits] by:
This subclause specifies a struct template,
char_traits<charT>, and four explicit specializations of it,char_traits<char>,char_traits<char16_t>,char_traits<char32_t>, andchar_traits<wchar_t>, all of which appear in the header <string> and satisfy the requirements below.
[Batavia (2009-05):]
We agree. Move to NAD Editorial.
Proposed resolution:
Change Forward declarations 31.3[iostream.forward]:
Header
<iosfwd>synopsisnamespace std { template<class charT> class char_traits; template<> class char_traits<char>;template<> class char_traits<char16_t>;template<> class char_traits<char32_t>; template<> class char_traits<wchar_t>;...}
Section: 27.2.4[char.traits.specializations]Status:NAD EditorialSubmitter: Dietmar KühlOpened: 2008-04-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [char.traits.specializations].
View all issues withNAD Editorial status.
Discussion:
In Table 56 (Traits requirements) thenot_eof() member function is using an argument of typee which denotes an object of typeX::int_type. However, the specializations in 27.2.4[char.traits.specializations] all usechar_type. This would effectively mean that the argument type actually can't represent EOF in the first place. I'm pretty sure that the type used to beint_type which is quite obviously the only sensible argument.
This issue is close to being editorial. I suspect that the proposal changing this section to include the specializations forchar16_t andchar32_t accidentally used the wrong type.
Proposed resolution:
In 27.2.4.2[char.traits.specializations.char], [char.traits.specializations.char16_t], [char.traits.specializations.char32_t], and [char.traits.specializations.wchar_t] correct the argument type fromchar_type toint_type.
Rationale:
Already fixed in WP.
Section: 19.5[syserr]Status:NADSubmitter: Beman DawesOpened: 2008-05-14Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [syserr].
View all issues withNAD status.
Discussion:
Initialization of objects of classerror_code(19.5.4[syserr.errcode]) and classerror_condition (19.5.5[syserr.errcondition]) can be made simpler and more reliable by use ofthe newconstexpr feature [N2349]of C++0x. Less code will need to begenerated for both library implementations and user programs whenmanipulating constant objects of these types.
This was not proposed originally because the constant expressionsproposal was moving into the standard at about the same time as theDiagnostics Enhancements proposal [N2241],and it wasn't desirable tomake the later depend on the former. There were also technical concernsas to howconstexpr would apply to references. Those concerns are nowresolved;constexpr can't be used for references, and that fact isreflected in the proposed resolution.
Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification ofconstexpr requirements.
LWG issue804(i) is related in that it raises the question of whether theexposition only membercat_ of classerror_code (19.5.4[syserr.errcode]) and classerror_condition (19.5.5[syserr.errcondition]) should be presented as a reference or pointer.While in the context of804(i) that is arguably an editorial question,presenting it as a pointer becomes more or less required with thisproposal, givenconstexpr does not play well with references. Theproposed resolution thus changes the private member to a pointer, whichalso brings it in sync with real implementations.
[Sophia Antipolis:]
On going question of extern pointer vs. inline functions for interface.
[Pre-San Francisco:]
Beman Dawes reports that this proposal is unimplementable, and thus NAD.
Implementation would require
constexprobjects of classes derivedfrom classerror_category, which has virtual functions, and that isnot allowed by the core language. This was determined when trying toimplement the proposal using a constexpr enabled compiler providedby Gabriel Dos Reis, and subsequently verified in discussions withGabriel and Jens Maurer.
Proposed resolution:
The proposed wording assumes the LWG805(i) proposed wording has beenapplied to the WP, resulting in the formerposix_category being renamedgeneric_category. If805(i) has not been applied, the names in thisproposal must be adjusted accordingly.
Change 19.5.3.1[syserr.errcat.overview] Classerror_category overviewerror_category synopsis asindicated:
const error_category& get_generic_category();const error_category& get_system_category();staticextern const error_category&* const generic_category= get_generic_category();staticextern const error_category&* constnative_categorysystem_category= get_system_category();
Change 19.5.3.5[syserr.errcat.objects] Error category objects as indicated:
extern const error_category&* constget_generic_category();
Returns: A referencegeneric_categoryshall pointtoana statically initialized object of a type derived fromclasserror_category.
Remarks:The object'sdefault_error_conditionandequivalentvirtualfunctions shall behave as specified for the classerror_category. Theobject'snamevirtual function shall return a pointer to the string"GENERIC".extern const error_category&* constget_system_category();
Returns: A referencesystem_categoryshall pointtoana staticallyinitialized object of a type derived from classerror_category.
Remarks:The object'sequivalentvirtual functions shall behave asspecified for classerror_category. The object'snamevirtual functionshall return a pointer to the string"system". The object'sdefault_error_conditionvirtual function shall behave as follows:If the argument
evcorresponds to a POSIXerrnovalueposv, the functionshall returnerror_condition(posv, generic_category). Otherwise, thefunction shall returnerror_condition(ev, system_category). Whatconstitutes correspondence for any given operating system isunspecified. [Note: The number of potential system error codes is largeand unbounded, and some may not correspond to any POSIXerrnovalue.Thus implementations are given latitude in determining correspondence.-- end note]
Change 19.5.4.1[syserr.errcode.overview] Classerror_code overview as indicated:
class error_code {public: ...;constexpr error_code(int val, const error_category&* cat); ... void assign(int val, const error_category&* cat); ... const error_category&* category() const; ...private: int val_; // exposition only const error_category&* cat_; // exposition onlyChange 19.5.4.2[syserr.errcode.constructors] Classerror_code constructors as indicated:
constexpr error_code(int val, const error_category&* cat);Effects: Constructs an object of type
error_code.Postconditions:
val_ == valandcat_ == cat.Throws: Nothing.
Change 19.5.4.3[syserr.errcode.modifiers] Classerror_code modifiers as indicated:
void assign(int val, const error_category&* cat);Postconditions:
val_ == valandcat_ == cat.Throws: Nothing.
Change 19.5.4.4[syserr.errcode.observers] Classerror_code observers as indicated:
const error_category&* category() const;Returns:
cat_.Throws: Nothing.
Change 19.5.5.1[syserr.errcondition.overview] Classerror_condition overview as indicated:
class error_condition {public: ...;constexpr error_condition(int val, const error_category&* cat); ... void assign(int val, const error_category&* cat); ... const error_category&* category() const; ...private: int val_; // exposition only const error_category&* cat_; // exposition onlyChange 19.5.5.2[syserr.errcondition.constructors] Classerror_condition constructors as indicated:
constexpr error_condition(int val, const error_category&* cat);Effects: Constructs an object of type
error_condition.Postconditions:
val_ == valandcat_ == cat.Throws: Nothing.
Change 19.5.5.3[syserr.errcondition.modifiers] Classerror_condition modifiers as indicated:
void assign(int val, const error_category&* cat);Postconditions:
val_ == valandcat_ == cat.Throws: Nothing.
Change 19.5.5.4[syserr.errcondition.observers] Classerror_condition observers as indicated:
const error_category&* category() const;Returns:
cat_.Throws: Nothing.
Throughout 19.5[syserr] System error support, change "category()." to "category()->".Appears approximately six times.
[Partially Editorial] In 19.5.6[syserr.compare] Comparison operators,paragraphs 2 and 4, change "category.equivalent(" to"category()->equivalent(".
Change 19.5.8.1[syserr.syserr.overview] Class system_error overview as indicated:
public: system_error(error_code ec, const string& what_arg); system_error(error_code ec); system_error(int ev, const error_category&* ecat, const string& what_arg); system_error(int ev, const error_category&* ecat);
Change 19.5.8.2[syserr.syserr.members] Class system_error members as indicated:
system_error(int ev, const error_category&* ecat, const string& what_arg);Effects: Constructs an object of class
system_error.Postconditions:
code() == error_code(ev, ecat)andstrcmp(runtime_error::what(), what_arg.c_str()) == 0.system_error(int ev, const error_category&* ecat);Effects: Constructs an object of class
system_error.Postconditions:
code() == error_code(ev, ecat)andstrcmp(runtime_error::what(), "") == 0.
Rationale:
[San Francisco:]
NAD because Beman said so.
Section: 16.4.2.5[compliance]Status:NADSubmitter: Beman DawesOpened: 2008-05-14Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [compliance].
View all issues withNAD status.
Discussion:
Once the C++0x standard library is feature complete, the LWG needs toreview 16.4.2.5[compliance] Freestanding implementations header list toensure it reflects LWG consensus.
[San Francisco:]
This is a placeholder defect to remind us to review the table once we'vestopped adding headers to the library.
Three new headers that need to be added to the list:
<initializer_list> <concept> <iterator_concepts>
<iterator_concepts>, in particular, has lots of stuffthat isn't needed, so maybe the stuff that is needed should be brokenout into a separate header.Robert: What about
reference_closure? It's currently in<functional>.
[Post Summit Daniel adds:]
- The comment regarding
reference_closureseems moot since it was justrecently decided to remove that.- A reference to proposalN2814("Fixing freestanding") should be added. Thispaper e.g. proposes to add only
<initializer_list>to the include listof freestanding.
[2009-07 Frankfurt:]
Addressed by paperN2814.
Move to NAD.
Proposed resolution:
basic_ios::copyfmt() overly loosely specifiedSection: 31.5.4.3[basic.ios.members]Status:NAD EditorialSubmitter: Martin SeborOpened: 2008-05-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [basic.ios.members].
View all issues withNAD Editorial status.
Discussion:
Thebasic_ios::copyfmt() member function is specified in 31.5.4.3[basic.ios.members] to have the following effects:
Effects: If
(this == &rhs)doesnothing. Otherwise assigns to the member objects of*thisthe corresponding member objects ofrhs, except that
rdstate()andrdbuf()are left unchanged;exceptions()is altered last bycallingexceptions(rhs.except)- the contents of arrays pointed at by
pwordandiwordare copied not the pointers themselves
Since the rest of the text doesn't specify what the member objectsofbasic_ios are this seems a little too loose.
[Batavia (2009-05):]
We agree with the proposed resolution.Move to NAD Editorial.
Proposed resolution:
I propose to tighten things up by adding aPostcondition clauseto the function like so:
Postconditions:
copyfmt()postconditionsElement Value rdbuf()unchanged tie()rhs.tie()rdstate()unchanged exceptions()rhs.exceptions()flags()rhs.flags()width()rhs.width()precision()rhs.precision()fill()rhs.fill()getloc()rhs.getloc()
The format of the table follows Table 117 (asofN2588):basic_ios::init()effects.
The intent of the new table is not to impose any new requirements orchange existing ones, just to be more explicit about what I believe isalready there.
pair default template argumentSection: 22.3[pairs]Status:NADSubmitter: Thorsten OttosenOpened: 2008-05-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [pairs].
View all issues withNAD status.
Discussion:
I have one issue withstd::pair. Well, it might just be a very annoyinghistorical accident, but why is there no default template argument forthe second template argument? This is so annoying when the type inquestion is looong and hard to write (type deduction withauto won'thelp those cases where we use it as a return or argument type).
Proposed resolution:
Change the synopsis in 22.2[utility] to read:
template <class T1, class T2= T1> struct pair;
Change 22.3[pairs] to read:
namespace std { template <class T1, class T2= T1> struct pair { typedef T1 first_type; typedef T2 second_type; ...Rationale:
std::pair is a heterogeneous container.
Section: 17.4.1[cstdint.syn]Status:NAD EditorialSubmitter: Martin SeborOpened: 2008-05-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [cstdint.syn].
View all issues withNAD Editorial status.
Discussion:
In specifying the names of macros and types defined inheader<stdint.h>, C99 makes use of thesymbolN to accommodate unusual platforms withword sizes that aren't powers of two. C99permitsN to take on any positive integer value(including, for example, 24).
In [stdint.sy] Header<cstdint>synopsis, C++ on the other hand, fixes the valueofN to 8, 16, 32, and 64, and specifies onlytypes with these exact widths.
In addition, paragraph 1 of the same section makes use of a ratherinformal shorthand notation to specify sets of macros. Wheninterpreted strictly, the notation specifies macros suchasINT_8_MIN that are not intended to be specified.
Finally, the section is missing the usual table of symbols definedin that header, making it inconsistent with the rest of thespecification.
Proposed resolution:
I propose to use the same approach in the C++ spec as C99 uses, thatis, to specify the header synopsis in terms of "exposition only" typesthat make use of the symbolN to denote one ormore of a theoretically unbounded set of widths.
Further, I propose to add a new table to section listing the symbolsdefined in the header using a more formal notation that avoidsintroducing inconsistencies.
To this effect, in [stdint.sy]Header<cstdint> synopsis, replace both thesynopsis and paragraph 1 with the following text:
- In the names defined in the
<cstdint>header, thesymbolNrepresents a positive decimal integerwith no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With theexception of exact-width types, macros and types for valuesofNin the set of 8, 16, 32, and 64 arerequired. Exact-width types, and any macros and types for valuesofNother than 8, 16, 32, and 64 areoptional. However, if an implementation provides integer types withwidths of 8, 16, 32, or 64 bits, the corresponding exact-width typesand macros are required.namespace std { // required types // Fastest minimum-width integer types typedefsigned integer type int_fast8_t; typedefsigned integer type int_fast16_t; typedefsigned integer type int_fast32_t; typedefsigned integer type int_fast64_t; typedefunsigned integer type uint_fast8_t; typedefunsigned integer type uint_fast16_t; typedefunsigned integer type uint_fast32_t; typedefunsigned integer type uint_fast64_t; // Minimum-width integer types typedefsigned integer type int_least8_t; typedefsigned integer type int_least16_t; typedefsigned integer type int_least32_t; typedefsigned integer type int_least64_t; typedefunsigned integer type uint_least8_t; typedefunsigned integer type uint_least16_t; typedefunsigned integer type uint_least32_t; typedefunsigned integer type uint_least64_t; // Greatest-width integer types typedefsigned integer type intmax_t; typedefunsigned integer type uintmax_t; // optionally defined types // Exact-width integer types typedefsigned integer type intN_t; typedefunsigned integer type uintN_t; // Fastest minimum-width integer types for values // ofN other than 8, 16, 32, and 64 typedefsigned integer type uint_fastN_t; typedefunsigned integer type uint_fastN_t; // Minimum-width integer types for values // ofN other than 8, 16, 32, and 64 typedefsigned integer type uint_leastN_t; typedefunsigned integer type uint_leastN_t; // Integer types capable of holding object pointers typedefsigned integer type intptr_t; typedefsigned integer type intptr_t;}
[Note to editor: Remove all of the existing paragraph 1 from [stdint.sy].]
Table ??: Header
<cstdint>synopsis
Type Name(s) Macros: INTN_MININTN_MAXUINTN_MAXINT_FASTN_MININT_FASTN_MAXUINT_FASTN_MAXINT_LEASTN_MININT_LEASTN_MAXUINT_LEASTN_MAXINTPTR_MININTPTR_MAXUINTPTR_MAXINTMAX_MININTMAX_MAXUINTMAX_MAXPTRDIFF_MINPTRDIFF_MAXPTRDIFF_MAXSIG_ATOMIC_MINSIG_ATOMIC_MAXSIZE_MAXWCHAR_MINWCHAR_MAXWINT_MINWINT_MAXINTN_C()UINTN_C()INTMAX_C()UINTMAX_C()Types: intN_tuintN_tint_fastN_tuint_fastN_tint_leastN_tuint_leastN_tintptr_tuintptr_tintmax_tuintmax_t
Section: 21.3.9.7[meta.trans.other]Status:NADSubmitter: Thorsten OttosenOpened: 2008-06-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [meta.trans.other].
View all issues withNAD status.
Discussion:
The type traits library contains various traits to dealt withpolymorphic types, e.g.std::has_virtual_destructor,std::is_polymorphicandstd::is_base_of. However, there is no way to compute the uniquepublic base class of a type if such one exists. Such a trait could bevery useful if one needs to instantiate a specialization made for theroot class whenever a derived class is passed as parameter. For example,imagine that you wanted to specializestd::hash for a classhierarchy---instead of specializing each class, you could specialize thestd::hash<root_class> and provide a partial specialization that workedfor all derived classes.
This ability---to specify operations in terms of their equivalent in theroot class---can be done with e.g. normal functions, but there is,AFAIK, no way to do it for class templates. Being able to accesscompile-time information about the type-hierachy can be very powerful,and I therefore also suggest traits that computes the directly derivedclass whenever that is possible.
If the computation can not be done, the traits should fall back on anidentity transformation. I expect this gives the best overall usability.
Proposed resolution:
Add the following to the synopsis in 21.3.3[meta.type.synop] under "other transformations":
template< class T > struct direct_base_class;template< class T > struct direct_derived_class;template< class T > struct root_base_class;
Add three new entries to table 51 (21.3.9.7[meta.trans.other]) with the following content
Template Condition Comments template< class T > struct direct_base_class;Tshall be a complete type.The member typedef typeshall equal the accessible unambiguous direct base class ofT.If no such type exists, the member typedeftypeshall equalT.template< class T > struct direct_derived_class;Tshall be a complete type.The member typedef typeshall equal the unambiguous type which hasTas an accessible unambiguous direct base class. If no such type exists, the member typedeftypeshall equalT.template< class T > struct root_base_class;Tshall be a complete type.The member typedef typeshall equal the accessible unambiguous most indirect base class ofT. If no such type exists, the member typedef type shall equalT.
Rationale:
2008-9-16 San Francisco: Issue pulled by author prior to being reviewed by the LWG.
Section: 23.3.3[array]Status:NADSubmitter: Benjamin KosnikOpened: 2008-06-05Last modified: 2017-06-06
Priority:Not Prioritized
View all otherissues in [array].
View all issues withNAD status.
Discussion:
This is an issue that came up on the libstdc++ list, where adiscrepancy between "C" arrays and C++0x'sstd::array was pointedout.
In "C," this array usage is possible:
int ar[] = {1, 4, 6};But for C++,
std::array<int> a = { 1, 4, 6 }; // errorInstead, the second parameter of thearray template must beexplicit, like so:
std::array<int, 3> a = { 1, 4, 6 };Doug Gregor proposes the following solution, that assumesgeneralized initializer lists.
template<typename T, typename... Args>inline array<T, sizeof...(Args)> make_array(Args&&... args) { return { std::forward<Args>(args)... }; }Then, the way to build anarray from a list of unknown size is:
auto a = make_array<T>(1, 4, 6);
[San Francisco:]
Benjamin: Move to Ready?
Bjarne: I'm not convinced this is useful enough to add, so I'd like usto have time to reflect on it.
Alisdair: the constraints are wrong, they should be
template<ValueType T, ValueType... Args>requires Convertible<Args, T>...array<T, sizeof...(Args)> make_array(Args&&... args);Alidair: this would be useful if we had a constexpr version.
Bjarne: this is probably useful for arrays with a small number ofelements, but it's not clearly useful otherwise.
Consensus is to move to Open.
[2009-06-07 Daniel adds:]
I suggest a fix and a simplification of the current proposal: Recentprototyping byHoward showed, that a fix is required because narrowing conversion9.5.5[dcl.init.list]/6 b.3would severely limit the possible distribution of argument types, e.g.the expression
make_array<double>(1, 2.0)is ill-formed, because the narrowinghappensinside thefunction body where no constant expressions exist anymore. Furthermoregiven e.g.int f();double g();we probably want to support
make_array<double>(f(), g());as well. To make this feasible, the currently suggested expansion
{ std::forward<Args>(args)... }needs to be replaced by
{ static_cast<T>(std::forward<Args>(args))... }which is safe, because we already ensure convertibility via theelement-wise
Convertible<Args, T>requirement. Some other fixes arenecessary: TheValueTyperequirement for the functionparametersis invalid, because all lvalue arguments will deduce to an lvalue-reference,thereby no longer satisfying this requirement.The suggested simplification is to provide a default-computed effectivetype for the result array based on common_type and decay, inunconstrained form:
template<typename... Args>array<typename decay<typename common_type<Args...>::type>::type,sizeof...(Args)>make_array(Args&&... args);The approach used below is similar to that of
make_pairandmake_tupleusing a symbolCto represent the decayed common type [Note: Specialhandling ofreference_wrappertypes is intentionallynot provided, becauseour target has so satisfyValueType, thus under the revised proposal onlyan all-reference_wrapper-arguments would be well-formed and an array ofreference_wrapperwill be constructed]. I do currently not suggest toadd new concepts reflectingdecayandcommon_type, but an implementor willneed something like this to succeed. Note that we use a similar fuzziness formake_pairandmake_tuplecurrently. This fuzziness is not related tothe currentlymissingConstructible<Vi, Ti&&>requirement for those functions. The followingproposal fixes that miss formake_array. If the correspondingCtypededuction isexplicitly wanted for standardization, here the implementationauto concept DC<typename... T> { typename type = typename decay<typename common_type<T...>::type>::type;}where
Cis identical toDC<Args...>::typein the proposed resolution below.I intentionally added no further type relation between type and the concepttemplate parameters, but instead added this requirement below to makethe specification as transparent as possible. As written this concept issatisfied, if the corresponding associated type exists.
Suggested Resolution:
Add to the array synopsis in 23.3[sequences]:
template<ReferentType... Args>requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...array<C, sizeof...(Args)>make_array(Args&&... args);Append after 23.3.3.7[array.tuple] Tuple interface to class template arraythe following new section:
23.4.1.7 Array creation functions [array.creation]
template<ReferentType... Args>requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>...array<C, sizeof...(Args)>make_array(Args&&... args);Let
Cbedecay<common_type<Args...>::type>::type.Returns: an
array<C, sizeof...(Args)>initialized with{ static_cast<C>(std::forward<Args>(args))... }.
[2009-07 Frankfurt:]
The proposed resolution uses concepts.
Daniel to rewrite the proposed resolution.
Leave Open.
[2009-07-25 Daniel provides rewritten proposed resolution.]
[2009-10 Santa Cruz:]
Argument for NAD future: everything about this could be added on. Thisdoes not require changes to the existing text.
[2015-11-29, Alisdair comments]
N4391 was adopted for Fundamentals 2 at the Lenexa meeting.
[2017-02 in Kona, LEWG recommends NAD]
[2017-06-02 Issues Telecon]
It seems as if deduction guides can solve most of the problem. In additionto that, make_array is available in Library Fundamentals TS v2. Ifit's desired to be able to specify the type but not the extent, make_arraycan do that, and if make_array isn't acceptable for that, we are talkingabout a language extension in deduction guides, which needs a proposalpaper.
Resolve as NAD
Proposed resolution:
Add to the array synopsis in 23.3[sequences]:
template<class... Args> array<CT, sizeof...(Args)> make_array(Args&&... args);
Append after 23.3.3.7[array.tuple] "Tuple interface to class template array" thefollowing new section:
XX.X.X.X Array creation functions [array.creation]
template<class... Args>array<CT, sizeof...(Args)>make_array(Args&&... args)LetCT be
decay<common_type<Args...>::type>::type.Returns: An
array<CT, sizeof...(Args)>initialized with{static_cast<CT>(std::forward<Args>(args))... }.[Example:
int i = 0; int& ri = i;make_array(42u, i, 2.78, ri);returns an array of type
array<double, 4>—end example]
Section: 23.3.5.3[deque.capacity]Status:NADSubmitter: Hervé BrönnimannOpened: 2008-06-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [deque.capacity].
View all issues withNAD status.
Discussion:
The main point is thatcapacity can be viewed as a mechanism to guarantee the validity ofiterators when onlypush_back/pop_backoperations are used. Forvector, this goes with reallocation. Fordeque, this is a bit more subtle:capacity() of adeque may shrink, whereas that ofvector doesn't. In a circular buffer impl. of the map, as Howard did, there is very similar notion of capacity: as long assize() is less thanB * (total size of the map- 2), it is guaranteed that noiterator is invalidated after any number ofpush_front/back andpop_front/back operations. But this does not hold for other implementations.
Still, I believe,capacity() can be defined bysize() + how manypush_front/back minuspop_front/back that can be performed before terators are invalidated. In a classical impl.,capacity() = size()+ the min distance to either "physical" end of the deque (i.e., counting the empty space in the last block plus all the blocks until the end of the map of block pointers). In Howard's circular buffer impl.,capacity() = B * (total size of the map- 2) still works with this definition, even though the guarantee could be made stronger.
A simple picture of a deque:
A-----|----|-----|---F+|++++|++B--|-----|-----Z
(A,Z mark the beginning/end, | the block boundaries, F=front, B=back, and - are uninitialized, + are initialized)In that picture:capacity = size() + min(dist(A,F),dist(B,Z)) = min (dist(A,B),dist(F,Z)).
Reserve(n) can grow the map of pointers and add possibly a number of empty blocks to it, in order to guarantee that the nextn-size()push_back/push_front operations will not invalidate iterators, and also will not allocate (i.e. cannot throw). The second guarantee is not essential and can be left as a QoI. I know well enough existing implementations ofdeque (sgi/stl, roguewave, stlport, and dinkumware) to know that either can be implemented with no change to the existing class layout and code, and only a few modifications if blocks are pre-allocated (instead of always allocating a new block, check if the next entry in the map of block pointers is not zero).
Due to the difference withvector, wording is crucial. Here's a proposed wording to make things concrete; I tried to be reasonably careful but please double-check me:
[San Francisco:]
Hans: should the Returns clause for capacity read "1 Returns: A lowerbound..." rather than "1 Returns: An upper bound..."
Howard: maybe what's needed is capacity_front and capacity_back. Infact, I think I implemented a deque that had these members asimplementation details.
Proposed resolution:
Add new signatures to synopsis in 23.3.5[deque]:
size_type capacity() const;bool reserve(size_type n);
Add new signatures to 23.3.5.3[deque.capacity]:
size_type capacity() const;1Returns: An upper bound on
n + max(n_f - m_f, n_b - m_b)such that, for any sequence ofn_f push_front,m_f pop_front,n_b push_back, andm_b pop_backoperations, interleaved in any order, starting with the currentdequeof sizen, thedequedoes not invalidate any of its iterators except to the erased elements.2Remarks: Unlike a
vector's capacity, the capacity of adequecan decrease after a sequence of insertions at both ends, even if none of the operations caused thedequeto invalidate any of its iterators except to the erased elements.
bool reserve(size_type n);2Effects: A directive that informs a
dequeof a planned sequence ofpush_front,pop_front,push_back, andpop_backoperations, so that it can manage iterator invalidation accordingly. Afterreserve(),capacity()is greater or equal to the argument ofreserveif this operation returnstrue; and equal to the previous value ofcapacity()otherwise. If an exception is thrown, there are no effects.3Returns:
trueif iterators are invalidated as a result of this operation, and false otherwise.4Complexity: It does not change the size of the sequence and takes at most linear time in
n.5Throws:
length_errorifn > max_size().6Remarks: It is guaranteed that no invalidation takes place during a sequence of
insertoreraseoperations at either end that happens after a call toreserve()except to the erased elements, until the time when an insertion would makemax(n_f-m_f, n_b-m_b)larger thancapacity(), wheren_fis the number ofpush_front,m_fofpop_front,n_bofpush_back, andm_bofpop_backoperations since the call toreserve().7 An implementation is free to pre-allocate buffers so as to offer the additional guarantee that no exception will be thrown during such a sequence other than by the element constructors.
And 23.3.5.4[deque.modifiers] para 1, can be enhanced:
1Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of thedeque. An insertion at either end of the deque invalidates all the iterators to the deque,unless provisions have been made with reserve,but has no effect on the validity of references to elements of the deque.
Rationale:
Complication outweighs the benefit.
Section: 26.8.7.2[includes]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2008-07-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [includes].
View all issues withNAD Editorial status.
Discussion:
In 26.8.7.2[includes] the complexity is "at most -1 comparisons" if passedtwo empty ranges. I don't know how to perform a negative number ofcomparisions!
This same issue also applies to:
set_unionset_intersectionset_differenceset_symmetric_differencemerge[2009-03-30 Beman adds:]
Suggest NAD. The complexity of empty ranges is -1 in other places in thestandard. See 26.8.6[alg.merge]
mergeandinplace_merge, andforward_listmerge, for example.The time and effort to find and fix all places in the standard whereempty range[s] result in negative complexity isn't worth the verylimited benefit.
[2009-05-09 Alisdair adds:]
I'm not happy with NAD if we can find a simple solution.
How about adding a rider somewhere in clause 17 suggesting that complexitiesthat specify a negative number of operations are treated as specifying zerooperations? That should generically solve the issue without looking forfurther cases.
[Batavia (2009-05):]
Pete to provide "straightforward" wording.Move to NAD Editorial.
Proposed resolution:
Recommend NAD.
Section: 31.10[file.streams]Status:NADSubmitter: Steve ClamageOpened: 2008-07-08Last modified: 2017-06-15
Priority:Not Prioritized
View all otherissues in [file.streams].
View all issues withNAD status.
Discussion:
Suppose writing to an[o]fstream fails and you later close thestream.Theoverflow() function is called to flush the buffer (if it exists).Then the file is unconditionally closed, as if by callingflcose.
If eitheroverflow orfclose fails,close() reports failure, and clearlythestream should be in a failed or bad state.
Suppose the buffer is empty or non-existent (so thatoverflow() does notfail), andfclose succeeds. Theclose() function reports success, butwhat is the state of thestream?
[Batavia (2009-05):]
Tom's impression is that the issue is about the
failbit, etc.Bill responds that the stream is now closed,and any status bits remain unchanged.
See the description of
close()in 31.10.6.4[fstream.members].We prefer not to add wording to say that nothing changes.Move to NAD.
Proposed resolution:
Section: 32.5.8.2[atomics.types.operations]Status:NAD EditorialSubmitter: Anthony WilliamsOpened: 2008-07-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withNAD Editorial status.
Discussion:
There's an error in 32.5.8.2[atomics.types.operations]/p9:
C atomic_load(const volatile A * object);C atomic_load_explicit(const volatile A * object, memory_order);C A ::load(memory_order order = memory_order_seq_cst) const volatile;Requires: The
orderargument shall not bememory_order_acquirenormemory_order_acq_rel.
I believe that this should state
shall not be
memory_order_release.
There's also an error in 32.5.8.2[atomics.types.operations]/p17:
... When only one
memory_orderargument is supplied, the value of successisorder, andthe value of failure isorderexcept that a value ofmemory_order_acq_relshall be replaced by the valuememory_order_require...
I believe this should state
shall be replaced by the value
memory_order_acquire...
Proposed resolution:
Change 32.5.8.2[atomics.types.operations]/p9:
C atomic_load(const volatile A * object);C atomic_load_explicit(const volatile A * object, memory_order);C A ::load(memory_order order = memory_order_seq_cst) const volatile;Requires: The
orderargument shall not bememory_order_acquirememory_order_releasenormemory_order_acq_rel.
Change 32.5.8.2[atomics.types.operations]/p17:
... When only one
memory_orderargument is supplied, the value of successisorder, andthe value of failure isorderexcept that a value ofmemory_order_acq_relshall be replaced by the valuememory_order_requirememory_order_acquire...
Rationale:
Already fixed by the time the LWG processed it.
Section: 29.6.2.2[valarray.cons]Status:NAD EditorialSubmitter: Alberto Ganesh BarbatiOpened: 2008-07-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.cons].
View all issues withNAD Editorial status.
Discussion:
From 29.6.2.2[valarray.cons], paragraph 2:
explicit valarray(size_t);The array created by this constructor has a length equal to the value of the argument. The elementsof the array are constructed using the default constructor for the instantiating type
T.
The problem is that the most obviousTs forvalarray arefloatanddouble, they don't have a default constructor. I guess the intent is to value-initializethe elements, so I suggest replacing:
The elements of the array are constructed using the default constructor for the instantiating type
T.
with
The elements of the array are value-initialized.
There is another reference to the default constructor ofT in the non-normative note in paragraph 9.That reference should also be replaced. (The normative wording in paragraph 8 refers toT()and so it doesn't need changes).
[Batavia (2009-05):]
We agree with the proposed resolution.Move to NAD Editorial.
Proposed resolution:
Change 29.6.2.2[valarray.cons], paragraph 2:
explicit valarray(size_t);The array created by this constructor has a length equal to the value of the argument. The elementsof the array are
constructed using the default constructor for the instantiating typevalue-initialized (9.5[dcl.init]).T
Change 29.6.2.8[valarray.members], paragraph 9:
[Example: If the argument has the value -2, the first two elements of the result will be
constructed using the default constructorvalue-initialized (9.5[dcl.init]);the third element of the result will be assigned the value of the first element of the argument; etc.-- end example]
Section: 6.9.2[basic.fundamental]Status:NAD EditorialSubmitter: Travis VitekOpened: 2008-06-30Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Neither the term "signed integral type" nor the term "unsigned integral type" is defined in the core language section of the standard, therefore the library section should avoid its use. The termssigned integer type andunsigned integer type are indeed defined (in 6.9.2[basic.fundamental]), thus the usages should be replaced accordingly.
Note that the key issue here is that "signed" + "integral type" != "signed integral type". The typesbool,char,char16_t,char32_t andwchar_t are all listed as integral types, but are neither ofsigned integer type orunsigned integer type. According to 6.9[basic.types] p7, a synonym for integral type isinteger type. Given this, one may choose to assume that anintegral type that can represent values less than zero is asigned integral type. Unfortunately this can cause ambiguities. As an example, ifT isunsigned char, the expressionmake_signed<T>::type, is supposed to name a signed integral type. There are potentially two types that satisfy this requirement, namelysigned char andchar (assumingCHAR_MIN < 0).
[San Francisco:]
Plum, Sebor to review.
[Post Summit Daniel adds:]
The proposed resolution needs to be "conceptualized". Currently we havein [concept.support] only concept
IntegralTypefor all "integral types", thus indeed the currentContainerconcept and Iterator concepts are sufficiently satisfied with "integraltypes". If the changes are applied, we might ask core for conceptBilateralIntegerTypeand add proper restrictions to the libraryconcepts.
Proposed resolution:
I propose to use the terms "signed integer type" and "unsigned integer type" in place of "signed integral type" and "unsigned integral type" to eliminate such ambiguities.
The proposed change makes it absolutely clear that the difference between two pointers cannot bechar orwchar_t, but could be any of the signed integer types. 7.6.6[expr.add] paragraph 6...
- When two pointers to elements of the same array object are subtracted, the result is the difference of the subscripts of the two array elements. The type of the result is an implementation-defined
signed integral typesigned integer type; this type shall be the same type that is defined asstd::ptrdiff_tin the<cstdint>header (18.1)...
The proposed change makes it clear thatX::size_type andX::difference_type cannot bechar orwchar_t, but could be one of the signed or unsigned integer types as appropriate. 16.4.4.6[allocator.requirements] table 40...
Table 40: Allocator requirements
expression return type assertion/note/pre/post-condition X::size_typeunsigned integral typeunsigned integer typea type that can represent the size of the largest object in the allocation model. X::difference_typesigned integral typesigned integer typea type that can represent the difference between any two pointers in the allocation model.
The proposed change makes it clear thatmake_signed<T>::type must be one of the signed integer types as defined in 3.9.1. Ditto formake_unsigned<T>type and unsigned integer types. 21.3.9.4[meta.trans.sign] table 48...
Table 48: Sign modifications
Template Comments template <class T> struct make_signed;If Tnames a (possibly cv-qualified)signed integral typesigned integer type (3.9.1) then the member typedeftypeshall name the typeT; otherwise, ifTnames a (possibly cv-qualified)unsigned integral typeunsigned integer type thentypeshall name the correspondingsigned integral typesigned integer type, with the same cv-qualifiers asT; otherwise,typeshall name thesigned integral typesigned integer type with the smallest rank (4.13) for whichsizeof(T) == sizeof(type), with the same cv-qualifiers asT.Requires:Tshall be a (possibly cv-qualified) integral type or enumeration but not abooltype.template <class T> struct make_unsigned;If Tnames a (possibly cv-qualified)unsigned integral typeunsigned integer type (3.9.1) then the member typedeftypeshall name the typeT; otherwise, ifTnames a (possibly cv-qualified)signed integral typesigned integer type thentypeshall name the correspondingunsigned integral typeunsigned integer type, with the same cv-qualifiers asT; otherwise,typeshall name theunsigned integral typeunsigned integer type with the smallest rank (4.13) for whichsizeof(T) == sizeof(type), with the same cv-qualifiers asT.Requires:Tshall be a (possibly cv-qualified) integral type or enumeration but not abooltype.
Note: I believe that the basefield values should probably be prefixed withios_base:: as they are in 28.3.4.3.3.3[facet.num.put.virtuals] The listed virtuals are all overloaded on signed and unsigned integer types, the new wording just maintains consistency. 28.3.4.3.2.3[facet.num.get.virtuals] table 78...
Table 78: Integer Conversions
State stdioequivalentbasefield == oct%obasefield == hex%Xbasefield == 0%isigned integral typesigned integer type%dunsigned integral typeunsigned integer type%u
Rationale is same as above. 28.3.4.3.3.3[facet.num.put.virtuals] table 80...
Table 80: Integer Conversions
State stdioequivalentbasefield == ios_base::oct%o(basefield == ios_base::hex) && !uppercase%x(basefield == ios_base::hex)%Xbasefield == 0%ifor a signed integral typesigned integer type%dfor a unsigned integral typeunsigned integer type%u
23.2[container.requirements] table 80...
Table 89: Container requirements
expression return type operational semantics assertion/note/pre/post-condition complexity X::difference_typesigned integral typesigned integer typeis identical to the difference type of X::iteratorandX::const_iteratorcompile time X::size_typeunsigned integral typeunsigned integer typesize_typecan represent any non-negative value ofdifference_typecompile time
24.3.4[iterator.concepts] paragraph 1...
Iterators are a generalization of pointers that allow a C++ program to work with different data structures (containers) in a uniform manner. To be able to construct template algorithms that work correctly and efficiently on different types of data structures, the library formalizes not just the interfaces but also the semantics and complexity assumptions of iterators. All input iterators
isupport the expression*i, resulting in a value of some class, enumeration, or built-in typeT, called thevalue type of the iterator. All output iterators support the expression*i = owhereois a value of some type that is in the set of types that arewritable to the particular iterator type ofi. All iteratorsifor which the expression(*i).mis well-defined, support the expressioni->mwith the same semantics as(*i).m. For every iterator typeXfor which equality is defined, there is a correspondingsigned integral typesigned integer type called thedifference type of the iterator.
I'm a little unsure of this change. Previously this paragraph would allow instantiations oflinear_congruential_engine onchar,wchar_t,bool, and other types. The new wording prohibits this. 29.5.4.2[rand.eng.lcong] paragraph 2...
The template parameter
UIntTypeshall denote anunsigned integral typeunsigned integer type large enough to store values as large asm - 1. If the template parametermis 0, the modulusmused throughout this section 26.4.3.1 isnumeric_limits<result_type>::max()plus 1. [Note: The result need not be representable as a value of typeresult_type. --end note] Otherwise, the following relations shall hold:a < mandc < m.
Same rationale as the previous change. 99 [rand.adapt.xor] paragraph 6...
Both
Engine1::result_typeandEngine2::result_typeshall denote (possibly different)unsigned integral typesunsigned integer types. The memberresult_type shall denote either the typeEngine1::result_type or the typeEngine2::result_type, whichever provides the most storage according to clause 3.9.1.
29.5.8.1[rand.util.seedseq] paragraph 7...
Requires:
RandomAccessIteratorshall meet the requirements of a random access iterator (24.1.5) such thatiterator_traits<RandomAccessIterator>::value_typeshall denote anunsigned integral typeunsigned integer type capable of accomodating 32-bit quantities.
By making this change, integral types that happen to have a signed representation, but are not signed integer types, would no longer be required to use a two's complement representation. This may go against the original intent, and should be reviewed. 32.5.8.2[atomics.types.operations] paragraph 24...
Remark: For
signed integral typessigned integer types, arithmetic is defined using two's complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior.
throw() or toThrow: Nothing.Section: 16[library]Status:NADSubmitter: Martin SeborOpened: 2008-08-23Last modified: 2018-06-23
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Recent changes totheworkingdraft have introduced a gratuitous inconsistency with the C++ 2003version of the specification with respect to exception guaranteesprovided by standard functions. While the C++ 2003 standardconsistenly uses the empty exception specification,throw(),to declare functions that are guaranteed not to throw exceptions, thecurrent working draft contains a number of "Throws: Nothing."clause to specify essentially the same requirement. The differencebetween the two approaches is that the former specifies the behaviorof programs that violate the requirement (std::unexpected()is called) while the latter leaves the behavior undefined.
A survey of the working draft reveals that there are a total of 209occurrences ofthrow() in the library portion of the spec,the majority in clause 18, a couple (literally) in 19, a handful in20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
There are also 203 occurrences of "Throws: Nothing." scatteredthroughout the spec.
While sometimes there are good reasons to use the "Throws:Nothing." approach rather than making use ofthrow(), thesereasons do not apply in most of the cases where this new clause hasbeen introduced and the empty exception specification would be abetter approach.
First, functions declared with the empty exception specificationpermit compilers to generate better code for calls to suchfunctions. In some cases, the compiler might even be able to eliminatewhole chunks of user-written code when instantiating a generictemplate on a type whose operations invoked from the templatespecialization are known not to throw. The prototypical example arethestd::uninitialized_copy()andstd::uninitialized_fill() algorithms where theentirecatch(...) block can be optimized away.
For example, given the following definition ofthestd::uninitialized_copy function template and auser-defined typeSomeType:
template <class InputIterator, class ForwardIterator>ForwardIteratoruninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res){ typedef iterator_traits<ForwardIterator>::value_type ValueType; ForwardIterator start = res; try { for (; first != last; ++first, ++res) ::new (&*res) ValueType (*first); } catch (...) { for (; start != res; --start) (&*start)->~ValueType (); throw; } return res;}struct SomeType { SomeType (const SomeType&)throw ();}compilers are able to emit the following efficient specializationofstd::uninitialized_copy<const SomeType*, SomeType*>(note that thecatch block has been optimized away):
template <> SomeType*uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res){ for (; first != last; ++first, ++res) ::new (res) SomeType (*first); return res;}Another general example is default constructors which, when decoratedwiththrow(), allow the compiler to eliminate theimplicittry andcatch blocks that it otherwise mustemit around each the invocation of the constructorinnew-expressions.
For example, given the following definitions ofclassMayThrow andWontThrow and the twostatements below:
struct MayThrow { MayThrow ();};struct WontThrow { WontThrow ()throw ();};MayThrow *a = new MayThrow [N];WontThrow *b = new WontThrow [N];the compiler generates the following code for the first statement:
MayThrow *a;{ MayThrow *first = operator new[] (N * sizeof (*a)); MayThrow *last = first + N; MayThrow *next = first; try { for ( ; next != last; ++next) new (next) MayThrow; } catch (...) { for ( ; first != first; --next) next->~MayThrow (); operator delete[] (first); throw; } a = first;}but it is can generate much more compact code for the second statement:
WontThrow *b = operator new[] (N * sizeof (*b));WontThrow *last = b + N;for (WontThrow *next = b; next != last; ++next) new (next) WontThrow;
Second, in order for users to get the maximum benefit out of the newstd::has_nothrow_xxx traits when using standard library typesit will be important for implementations to decorate all non throwingcopy constructors and assignment operators withthrow(). Notethat while an optimizer may be able to tell whether a function withoutan explicit exception specification can throw or not based on itsdefinition, it can only do so when it can see the source code of thedefinition. When it can't it must assume that the function maythrow. To prevent violating the One Definition Rule,thestd::has_nothrow_xxx trait must return the mostpessimistic guess across all translation units in the program, meaningthatstd::has_nothrow_xxx<T>::value must evaluate tofalse for anyT whosexxx(wherexxx is default or copy ctor, or assignment operator)is defined out-of-line.
Counterarguments:
During the discussion of this issueonlib@lists.isocpp.org(starting with postc++std-lib-21950) the following argumentsin favor of the "Throws: Nothing." style have been made.
throw() even if they don't actually throw). This is acommon situation when the called function is a C or POSIX function.__attribute__((nothrow))or VisualC++__declspec(nothrow))that let implementers mark up non-throwing functions, often withoutthe penalty mentioned in (1) above. The C++ standard shouldn'tpreclude the use of these potentially more efficient mechanisms.throw(). Declaring such functions with the emptyexception specification will cause compilers to generate suboptimalcode when the user-defined function isn't also declared not to throw.The answer to point (1) above is that implementers can (and some have)declare functions withthrow() to indicate to the compilerthat calls to the function can safely be assumed not to throw in orderto allow it to generate efficient code at the call site without alsohaving to define the functions the same way and causing the compilerto generate suboptimal code for the function definition. That is, thefunction is declared withthrow() in a header but it'sdefined without it in the source file. Thethrow()declaration is suppressed when compiling the definition to avoidcompiler errors. This technique, while strictly speaking no permittedby the language, is safe and has been employed in practice. Forexample, the GNU C library takes this approach. Microsoft Visual C++takes a similar approach by simply assuming that no function with Clanguage linkage can throw an exception unless it's explicitlydeclared to do so using the language extensionthrow(...).
Our answer to point (2) above is that there is no existing practicewhere C++ Standard Library implementers have opted to make use of theproprietary mechanisms to declare functions that don't throw. Thelanguage provides a mechanism specifically designed for thispurpose. Avoiding its use in the specification itself in favor ofproprietary mechanisms defeats the purpose of the feature. Inaddition, making use of the empty exception specificationinconsistently, in some areas of the standard, while conspicuouslyavoiding it and making use of the "Throws: Nothing." form inothers is confusing to users.
The answer to point (3) is simply to exercise caution when declaringfunctions and especially function templates with the empty exceptionspecification. Functions that required not to throw but that may callback into user code are poor candidates for the empty exceptionspecification and should instead be specified using "Throws:Nothing." clause.
[2009-07 Frankfurt]
We need someone to do an extensive review.
NAD Future.
[2017-02 in Kona, LEWG recommends NAD]
The discussed discrepancy isn't relevant any longer: now we have noexcept and have deprecated throw(). Additionally, the guidance on narrow vs. wide contracts, Requires clauses, and noexcept/Throws meansthat the proposed resolution is more subtle even if updated in terms of noexcept().
[2017-06-02 Issues Telecon]
Resolve as NAD
Proposed resolution:
We propose two possible solutions. Our recommendation is to adoptOption 1 below.
Option 1:
Except for functions or function templates that make calls back touser-defined functions that may not be declaredthrow()replace all occurrences of the "Throws: Nothing." clause withthe empty exception specification. Functions that are required not tothrow but that make calls back to user code should be specified to"Throw: Nothing."
Option 2:
For consistency, replace all occurrences of the empty exceptionspecification with a "Throws: Nothing." clause.
Section: 32.5[atomics]Status:NAD EditorialSubmitter: Alexander ChemerisOpened: 2008-08-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withNAD Editorial status.
Discussion:
Theatomic_address type andatomic<T*> specialization provide atomicupdates to pointers. However, the current specification requiresthat the types pointer be to non-const objects. This restrictionis unnecessary and unintended.
[Summit:]
Move to review. Lawrence will first check with Peter whether thecurrent examples are sufficient, or whether they need to be expanded toinclude all cases.
[2009-07 Frankfurt]
Lawrence will handle all issues relating to atomics in a single paper.
LWG will defer discussion on atomics until that paper appears.
Move to Open.
[2009-08-17 Handled byN2925.]
[2009-10 Santa Cruz:]
NAD Editorial. Solved byN2992.
Proposed resolution:
Add const qualification to the pointer values of theatomic_addressandatomic<T*> specializations. E.g.
typedef struct atomic_address { void store(const void*, memory_order = memory_order_seq_cst) volatile; void* exchange(const void*, memory_order = memory_order_seq_cst) volatile; bool compare_exchange(const void*&,const void*, memory_order, memory_order) volatile; bool compare_exchange(const void*&,const void*, memory_order = memory_order_seq_cst ) volatile; void* operator=(const void*) volatile;} atomic_address;void atomic_store(volatile atomic_address*,const void*);void atomic_store_explicit(volatile atomic_address*,const void*, memory_order);void* atomic_exchange(volatile atomic_address*, const void*);void* atomic_exchange_explicit(volatile atomic_address*,const void*, memory_order);bool atomic_compare_exchange(volatile atomic_address*,const void**,const void*);bool atomic_compare_exchange_explicit(volatile atomic_address*,const void**,const void*, memory_order, memory_order);Section: 32.7.4[thread.condition.condvar]Status:NADSubmitter: Lawrence CrowlOpened: 2008-09-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvar].
View all issues withNAD status.
Discussion:
The Posix/C++ working group has identified an inconsistency betweenPosix and the C++ working draft in that Posix requires the clock to beidentified at creation, whereas C++ permits identifying the clock at thecall 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_untilbe 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 anotheroverload for unknown clocks which synchs to a known clock before waiting.For example:template <class Duration>boolcondition_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>boolcondition_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_clockis the only clock which the underlyingcondition variable knows how to deal with. One overload just passes that clockthrough. The second overload (approximately) converts the unknown clock intoasystem_clock time_pointprior to passing it down to the nativecondition variable.On Posix systems vendors are free to add implementation defined constructors whichtake a clock. That clock can be stored in the condition_variable, and convertedto (or not as necessary) as shown above.
If an implementation defined constructor takes a clock (for example), then partof the semantics for that implementation defined ctor might include that a
wait_untilusing a clock other than the one constructed with resultsin 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 howeverhe pleases (when the cv is constructed in an implementation defined manner).
[Post Summit:]
"POSIX people will review the proposed NAD resolution at their upcoming NYmeeting.
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 presentedby Howard that implemented one clock on top of another.Unfortunately this implementation doesn't work for the probably mostimportant case where a system has a monotonic clock and a real-timeclock (or "wall time" clock):
If the underlying "system_clock" is a monotonic clock, andthe program waits on the real-time clock, and the real-time clockis set forward, the wait will unblock too late.
If the underlying "system_clock" is a real-time clock, and theprogram waits on the monotonic clock, and the real-time clockis set back, the wait again will unblock too late.
Sorry that I didn't remember this on Friday, but it was Fridayafternoon after a busy week...
So as the decision was made on a wrong asumption, I propose to re-openthe issue.
[2009-07-26 Howard adds:]
Detlef correctly argues that
condition_variable::wait_untilcouldreturn "too late" in the context of clocks being adjusted during the wait. I agreewith his logic. But I disagree that this makes this interface unimplementableon POSIX.The POSIX spec also does not guarantee that
pthread_cond_timedwaitdoesnot return "too late" when clocks are readjusted during the wait. Indeed, thePOSIX specification lacks any requirements at all concerning how soonpthread_cond_timedwaitreturns after a time out. This is evidently aQOI issue by the POSIX standard. Here is a quote of the most relevant normativetext concerningpthread_cond_timedwaitfoundhere.The
pthread_cond_timedwait()function shall be equivalent topthread_cond_wait(), except that an error is returned if the absolutetime specified byabstimepasses (that is, system time equals or exceedsabstime) before the conditioncondis signaled or broadcasted, or if theabsolute time specified byabstimehas already been passed at the timeof the call.I.e. the POSIX specification speaks of the error code returned in case of a timeout, 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 innon-normativetext:
For cases when the system clock is advanced discontinuously by anoperator, it is expected that implementations process any timed waitexpiring at an intervening time as if that time had actually occurred.
Here is non-normative wording encouraging the implementation to ignore an advancingunderlying clock and subsequently causing an early (spurious) return. There isno wording at all which addresses Detlef's example of a "late return". With
pthread_cond_timedwaitthis would be caused by setting the system clockbackwards. It seems reasonable to assume, based on the wording that is alreadyin the POSIX spec, that again, the discontinuously changed clock would be ignoredbypthread_cond_timedwait.A noteworthy difference between
pthread_cond_timedwaitandcondition_variable::wait_untilis that the POSIX spec appears tosay thatETIMEDOUTshould be returned ifpthread_cond_timedwaitreturns because of timeout signal, whether or not the system clock was discontinuouslyadvanced during the wait. In contrastcondition_variable::wait_untilalways returns:Clock::now() < abs_timeThat is, the C++ spec requires that the clock be rechecked (detecting discontinuousadjustments during the wait) at the time of return.
condition_variable::wait_untilmay indeed return early or late. But regardless it will return a valuereflecting 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 hasa chance to read the result of the return. Thus there are no iron-clad guaranteeshere.
condition_variable::wait_until(andpthread_cond_timedwait)is little more than a convenience function for making surecondition_variable::waitdoesn't hang for an unreasonable amount oftime (where the client gets to define "unreasonable"). I do not think itis 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 ofC++, and is implementable on POSIX. The implementation technique described aboveis a reasonable approach. There may also be higher quality approaches. Thisspecification, like the POSIX specification, gives a wide latitude for QOI.
I continue to recommend NAD, but would not object to a clarifying note regardingthe behavior of
condition_variable::wait_until. At the moment, I donot have good wording for such a note, but welcome suggestions.
[2009-09-30: SeeN2969.]
[2009-10 Santa Cruz:]
The LWG is in favor of Detlef to supply revision which adopts Option 2 fromN2969but is modified by saying that
system_clockmust be available forwait_until.
[2010-02-11 Anthony provided wording.]
[2010-02-22 Anthony adds:]
I am strongly againstN2999.
Firstly, I think that the most appropriate use of a timed wait on a conditionvariable is with a monotonic clock, so it ought to be guaranteed to be availableon systems that support such a clock. Also, making the set of supported clocksimplementation defined essentially kills portability around the use ofuser-defined clocks.
I also think that
wait_foris potentially useful, and triviallyimplementable given a working templatedwait_untiland a monotonicclock.I also disagree with many of Detlef's points in the rationale. In a system withhard latency limits there is likely to be a monotonic clock, otherwise you haveno way of measuring against these latency limits since the
system_clockmay change arbitrarily. In such systems, youwant to be able to usewait_for, orwait_untilwith a monotonic clock.I disagree that the
wait_*functions cannot be implemented correctly ontop of POSIX: I have done so. The only guarantee in the working draft is thatwhen the function returns certain properties are true; there is no guaranteethat the function will returnimmediately that the properties are true.My resolution to issue 887 makes this clear. How small the latency is is QoI.On systems without a monotonic clock, you cannot measure the problem since thesystem clock can change arbitrarily so any timing calculations you make may bewrong due to clock changes.
On systems with a monotonic clock, you can choose to use it for your conditionvariables. If you are waiting against a
system_clock::time_pointthenyou can check the clock when waking, and either return as a timeout or spuriouswake depending on whethersystem_clock::now()is before or after thespecifiedtime_point.Windowsdoes provide condition variables from Vista onwards. I choosenot to use them, but they are there. If people are concerned aboutimplementation difficulty, the Boost implementation can be used for mostpurposes; the Boost license is pretty liberal in that regard.
My preferred resolution to issue 887 is currently the PR in the issues list.
[2010 Pittsburgh:]
There is no consensus for moving the related paperN2999into the WP.
There was support for moving this issue as proposed to Ready, but the supportwas insufficient to call a consensus.
There was consensus for moving this issue to NAD as opposed to leaving it open.Rationale added.
Rationale:
The standard as written is sufficiently implementable and self consistent.
Proposed resolution:
Add a new paragraph after 32.2.4[thread.req.timing]p3:
3 The resolution of timing provided by an implementation depends on bothoperating system and hardware. The finest resolution provided by animplementation is called thenative resolution.
If a function in this clause takes a timeout argument, and the time point orelapsed time specified passes before the function returns, the latency betweenthe timeout occurring and the function returning is unspecified [Note:Implementations should strive to keep such latency as small as possible, butportable code should not rely on any specific upper limits —endnote]
Section: 23.3.7.6[forward.list.ops]Status:NAD EditorialSubmitter: Ed Smith-RowlandOpened: 2008-09-15Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [forward.list.ops].
View all issues withNAD Editorial status.
Discussion:
I was looking at the latest draft onforward_list. Especially the splice methods.
The first one splices a whole list after a given iterator inthis. The name issplice_after.I think in [forwardlist.ops] paragraph 40change:
Effect: Insert the contents of
xbeforeafterposition, ...
A deeper issue involves the complexity.forward_list has nosize and wedon't know when we've reached the end except to walk up to it. Tosplice we would need to hook the end of the source list to the itemafterposition in this list. This would involve walking length of thesource list until we got to the last dereference-able element in source.There's no way we could do this in O(1) unless we stored a bogus end inforward_list.
OTOH, the last version ofsplice_after with iterator ranges we could doin O(1) because we know how to hook the end of the source range to ...
Unless I'm misconceiving the whole thing. Which is possible. I'll look at it again.
I'm pretty sure about the first part though.
[San Francisco:]
This issue is more complicated than it looks.
paragraph 47: replace each
(first, last) with (first, last]add a statement after paragraph 48 that complexity is O(1)
remove the complexity statement from the first overload of splice_after
We may have the same problems with other modifiers, like erase_after.Should it require that all iterators in the range (position, last] bedereferenceable?
We do, however, like the proposed changes and consider them Editorial.Move to NAD Editorial, Pending. Howard to open a new issue to handle theproblems with the complexity requirements.
Proposed resolution:
In [forwardlist.ops] paragraph 40change:
Effect: Insert the contents of
xbeforeafterposition, ...
Section: 16.3.2.4[structure.specifications]Status:DupSubmitter: James DennettOpened: 2008-09-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [structure.specifications].
View all otherissues in [structure.specifications].
View all issues withDup status.
Duplicate of:625
Discussion:
Per discussion, we need an issue open to cover looking at "Requires"clauses which are not constraints on user code, such as that onstd::basic_string::at.
[2009-07 Frankfurt]
Alan to address in paper.
Proposed resolution:
Section: 24.5.2.4[insert.iterator]Status:NADSubmitter: Alisdair MeredithOpened: 2008-09-24Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses UK 282
The requires clause on theconst T & overloads inback_insert_iterator/front_insert_iterator/insert_iterator mean that theassignment operator will implicitly move from lvalues of a move-only type.
Suggested resolutions are:
[Post Summit, Alisdair adds:]
Both comment and issue have been resolved by the adoption ofN2844(rvalue references safety fix) at the last meeting.
Suggest resolve as NAD Editorial with a reference to the paper.
[Batavia (2009-05):]
We agree that this has been resolved in the latest Working Draft.Move to NAD.
Proposed resolution:
Recommend NAD, addressed byN2844.
Section: 17.3.5[numeric.limits]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2008-09-24Last modified: 2017-06-15
Priority:Not Prioritized
View otheractive issues in [numeric.limits].
View all otherissues in [numeric.limits].
View all issues withNAD Concepts status.
Discussion:
Addresses FR 32 and DE 16
numeric_limits has functions specifically designed to return NaNs, whichbreak the model ofRegular (via its axioms.) While floating point typeswill be acceptible in many algorithms takingRegular values, it is notappopriate for this specific API and we need a less refined constraint.
FR 32:
The definition of
numeric_limits<>as requiring a regulartype is both conceptually wrong and operationally illogical. As wepointed before, this mistake needs to be corrected. For example, thetemplate can be left unconstrained. In fact this reflects a much moregeneral problem with concept_maps/axioms and their interpretations. Itappears that the current text heavily leans toward experimental academictype theory.
DE 16:
The class template
numeric_limitsshould not specify the Regular conceptrequirement for its template parameter, because it contains functionsreturning NaN values for floating-point types; these values violate thesemantics of EqualityComparable.
[Summit:]
Move to Open. Alisdair and Gaby will work on a solution, along with the newtreatment of axioms in clause 14.
Proposed resolution:
back_insert_iterator issueSection: 24.5.2.2[back.insert.iterator]Status:NADSubmitter: Dave AbrahamsOpened: 2008-09-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [back.insert.iterator].
View all issues withNAD status.
Discussion:
I just noticed this; don't know how far the problem(?) extends orwhether it's new or existing:back_insert_iterator'soperator* is notconst, so you can't dereference aconst one.
[Post Summit Daniel adds:]
If done, this change should be applied for
front_insert_iterator,insert_iterator,ostream_iterator, andostreambuf_iteratoras well.
[Batavia (2009-05):]
Alisdair notes that these all are output iterators.Howard points out that
++*iwould no longer work if we made this change.Move to NAD.
[2009-05-25 Daniel adds:]
OutputIterator does no longer support post increment.operator*can be added.Note that theHasDereference concept (and theHasDereference part of conceptIterator) was specifically refactored to cope with optional constqualification andto properly reflect the dual nature of built-inoperator* as of12.6[over.literal]/6.Proposed resolution:
Section: 32.6.4.2.2[thread.mutex.class]Status:DupSubmitter: Herb SutterOpened: 2008-09-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.mutex.class].
View all issues withDup status.
Duplicate of:893
Discussion:
A few questions on the current WP,N2723:
32.6.4[thread.mutex.requirements]/24 says an expressionmut.unlock() "Throws: Nothing." I'm assuming that, per 99 [res.on.required], errors that violate the precondition "Thecalling thread shall own the mutex" opens the door for throwing anexception anyway, such as to report unbalanced unlock operations andunlocking from a thread that does not have ownership. Right?
32.6.4.2.2[thread.mutex.class]/3 (actually numbered paragraph "27"in the WP; this is just a typo I think) says
The behavior of a program is undefined if:
- it destroys a
mutexobject owned by any thread,- a thread that owns a
mutexobject callslock()ortry_lock()on that object, or- a thread terminates while owning a
mutexobject.
As already discussed, I think the second bullet should be removed, andsuch alock() ortry_lock() should fail with anexception or returningfalse, respectively.
A potential addition to the list would be
mutex it does not have ownership of.but without that the status quo text endorses the technique of theprogram logically transferring ownership of a mutex to another threadwith correctness enforced by programming discipline. Was that intended?
[Summit:]
Two resolutions: "not a defect" and "duplicate", as follows:
- 32.6.4[thread.mutex.requirements]/24: NAD. If the preconditionfails the program has undefined behaviour and therefore animplementation may throw an exception already.
- 32.6.4.2.2[thread.mutex.class]/3 bullet 2: Already addressed by issue893(i).
- 32.6.4.2.2[thread.mutex.class]/3 proposed addition: NAD. This isalready covered by the mutex requirements, which have ownership as aPrecondition.
Proposed resolution:
ObjectType is the wrong concept to constraininitializer_listSection: 17.11[support.initlist]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2008-09-26Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [support.initlist].
View all otherissues in [support.initlist].
View all issues withNAD Concepts status.
Discussion:
The currently proposed constraint oninitializer_list's element typeE is that is has to meetObjectType. This is an underspecification,because both core language and library part ofinitializer_listmake clear, that it references an implicitly allocated array:
9.5.5[dcl.init.list]/4:
When an initializer list is implicitly converted to a
std::initializer_list<E>, the object passed is constructed as if theimplementation allocated an array of N elements of typeE, whereN is the number of elements in the initializer list.[..]
17.11[support.initlist]/2.
An object of type
initializer_list<E>provides access to an array ofobjects of typeconst E.[..]
Therefore,E needs to fulfill conceptValueType (thus excludingabstract class types). This stricter requirement should be addedto prevent deep instantiation errors known from the bad old times,as shown in the following example:
// Header A: (Should concept-check even in stand-alone modus)template <DefaultConstructible T>requires MoveConstructible<T>void generate_and_do_3(T a) { std::initializer_list<T> list{T(), std::move(a), T()}; ...}void do_more();void do_more_or_less();template <DefaultConstructible T>requires MoveConstructible<T>void more_generate_3() { do_more(); generate_and_do_3(T());}template <DefaultConstructible T>requires MoveConstructible<T>void something_and_generate_3() { do_more_or_less(); more_generate_3();}// Test.cpp#include "A.h"class Abstract {public: virtual ~Abstract(); virtual void foo() = 0; // abstract type Abstract(Abstract&&){} // MoveConstructible Abstract(){} // DefaultConstructible};int main() { // The restricted template *accepts* the argument, but // causes a deep instantiation error in the internal function // generate_and_do_3: something_and_generate_3<Abstract>();}The proposed stricter constraint does not minimize the aim tosupport more general containers for whichObjectType would besufficient. If such an extended container (lets assume it's still aclass template) provides a constructor that accepts aninitializer_listonlythis constructor would need to be restricted onValueType:
template<ObjectType T>class ExtContainer {public: requires ValueType<T> ExtContainer(std::initializer_list<T>); ...};[Batavia (2009-05):]
Move to Tentatively Ready.
[2009-07 Frankfurt:]
Need to look at again without concepts.
Proposed resolution:
<initializer_list> synopsis"the constraint "ObjectType" in the template parameter list by theconstraint "ValueType".Section: 16.4.4.2[utility.arg.requirements]Status:NAD ConceptsSubmitter: Alberto Ganesh BarbatiOpened: 2008-09-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility.arg.requirements].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 150
The description of the effect ofoperator= in theMoveAssignableconcept, given in paragraph 7 is:
result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&>Postconditions: the constructed
Tobject is equivalent to the value ofrvbefore the assignment. [Note: there is norequirement on the value ofrvafter the assignment.--end note]
The sentence contains a typo (what is the "constructedT object"?)probably due to a cut&paste fromMoveConstructible. Moreover, thediscussion of LWG issue675(i) shows that the postcondition is too genericand might not reflect the user expectations. An implementation of themove assignment that just callsswap() would always fulfill thepostcondition as stated, but might have surprising side-effects in casethe source rvalue refers to an object that is not going to beimmediately destroyed. See LWG issue900(i) for another example. Due tothe sometimes intangible nature of the "user expectation", it seemsdifficult to have precise normative wording that could cover all caseswithout introducing unnecessary restrictions. However a non-normativeclarification could be a very helpful warning sign that swapping is notalways 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 objectreferenced by rv must be safely destructible, and the transaction should notleak resources. Ideally it should be possible to simply assign rv a newvalid state after the call without invoking undefined behaviour, but anyother use of the referenced object would depend upon additional guaranteesmade by that type.
[2009-05-09 Howard adds:]
The intent of the rvalue reference work is that the moved from
rvisa valid object. Not one in a singular state. If, for example, the moved fromobject is avector, one should be able to do anything on that moved-fromvectorthat you can do with any othervector. However you wouldfirst have to query it to find out what its current state is. E.g. it might havecapacity,it might not. It might have a non-zerosize, it might not. But regardless,you canpush_backon to it if you want.That being said, most standard code is now conceptized. That is, the conceptslist the only operations that can be done with templated types - whether or notthe values have been moved from.
Here is user-written code which must be allowed to be legal:
#include <vector>#include <cstdio>template <class Allocator>voidinspect(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
vectoras singular. Itonly treats it as avectorwith an unknown value.I believe the current proposed wording is consistent with my view on this.
[Batavia (2009-05):]
We agree that the proposed resolutionis 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 issue1204(i),but there is to much going on in this area to be sure. Defer for now.
[2010-01-23 Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.Rationale added below.]
Rationale:
The currentMoveAssignable requirements say everything that can be saidin general. Each std-defined type has a more detailed specification of moveassignment.
Proposed resolution:
In [concept.copymove], replace the postcondition in paragraph 7 with:
Postconditions:
*thisis equivalent to the value ofrvbefore theassignment. [Note: there is no requirement on the value ofrvafter theassignment, but theeffect should be unsurprising to the user even in caservis notimmediately destroyed. This may require that resources previously ownedby*thisare released instead of transferred torv.-- end note]
Section: 26.7.3[alg.swap]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2008-10-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.swap].
View all issues withNAD Concepts status.
Discussion:
With the adaption of809(i)we have a new algorithmswap for C-arrays, which needs to be conceptualized.
[Post Summit Daniel adds:]
Recommend as NAD Editorial: The changes have already been applied to the WPN2800.
[Batavia (2009-05):]
Move to NAD; the changes have already been made.
Proposed resolution:
Replace in 26.7.3[alg.swap] before p. 3 until p. 4 by
template <classValueType T, size_t N>requires Swappable<T>void swap(T (&a)[N], T (&b)[N]);
Requires:Tshall beSwappable.Effects:
swap_ranges(a, a + N, b);
Section: 26.7.5[alg.replace]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2008-10-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.replace].
View all issues withNAD Concepts status.
Discussion:
(A) 26.7.5[alg.replace]/1:
Requires: The expression
*first = new_valueshall be valid.
(B) 26.7.5[alg.replace]/4:
Requires: The results of the expressions
*firstandnew_valueshallbe writable to the result output iterator.[..]
Since conceptualization, the quoted content of these clauses is coveredby the existing requirements
(A)OutputIterator<Iter, const T&>
and
(B)OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&>
resp, and thus should be removed.
[Batavia (2009-05):]
We agree with the proposed resolution.
Move to Tentatively Ready.
Proposed resolution:
Remove 26.7.5[alg.replace]/1.
template<ForwardIterator Iter, class T> requires OutputIterator<Iter, Iter::reference> && OutputIterator<Iter, const T&> && HasEqualTo<Iter::value_type, T> void replace(Iter first, Iter last, const T& old_value, const T& new_value); template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> requires OutputIterator<Iter, Iter::reference> && OutputIterator<Iter, const T&> && CopyConstructible<Pred> void replace_if(Iter first, Iter last, Pred pred, const T& new_value);
1Requires: The expression*first = new_valueshall be valid.
26.7.5[alg.replace]/4: Remove the sentence "The results of theexpressions*first andnew_value shall be writable to the result output iterator.".
template<InputIterator InIter, typename OutIter, class T> requires OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&> && HasEqualTo<InIter::value_type, T> OutIter replace_copy(InIter first, InIter last, OutIter result, const T& old_value, const T& new_value);template<InputIterator InIter, typename OutIter, Predicate<auto, InIter::value_type> Pred, class T> requires OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&> && CopyConstructible<Pred> OutIter replace_copy_if(InIter first, InIter last, OutIter result, Pred pred, const T& new_value);4Requires:
The results of the expressionsThe ranges*firstandnew_valueshall be writable to theresultoutputiterator.[first,last)and[result,result +(last - first))shall not overlap.
Section: 26.7.9[alg.unique]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2008-10-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.unique].
View all issues withNAD Concepts status.
Discussion:
26.7.9[alg.unique]/2: "Requires: The comparison function shall be anequivalence relation."
The essence of this is already covered by the given requirement
EquivalenceRelation<auto, Iter::value_type> Pred
and should thus be removed.
[Batavia (2009-05):]
We agree with the proposed resolution.Move to Tentatively Ready.
Proposed resolution:
Remove 26.7.9[alg.unique]/2
template<ForwardIterator Iter> requires OutputIterator<Iter, Iter::reference> && EqualityComparable<Iter::value_type> Iter unique(Iter first, Iter last);template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> && CopyConstructible<Pred> Iter unique(Iter first, Iter last, Pred pred);1Effects: ...
2Requires: The comparison function shall be an equivalence relation.
minmax withinitializer_list should returnpair ofT, notpair ofconst T&Section: 26.8.9[alg.min.max]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2008-10-04Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withNAD Editorial status.
Discussion:
It seems that the proposed changes forN2772were not clear enough inthis point:
26.8.9[alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the returntype of the
minmaxoverloads with aninitializer_listispair<const T&, const T&>,which is inconsistent with the decision for the othermin/maxoverloads which takeainitializer_listas argument and return aT, not aconst T&.Doing otherwise forminmaxwould easily lead to unexpected life-timeproblems by usingminmaxinstead ofminandmaxseparately.
[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 betweaked for concepts removal.
[2009-08-18 Daniel adds:]
Recommend NAD since the proposed changes have already been performedas part of editorial work ofN2914.
[2009-10 Santa Cruz:]
Can't find
initializer_listform ofminmaxanymore, only variadicversion. Seems like we had an editing clash with concepts. Leave Open,at least until editorial issues resolved. Bring this to Editor's attention.
[2010 Pittsburgh: Pete to reapplyN2772.]
Rationale:
Solved by reapplyingN2772.
Proposed resolution:
In 26[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 26.8.9[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:TisLessThanComparableandCopyConstructible.-21-Returns:
pair<whereconstT&,constT&>(x, y)xis thesmallest value andythe largest value in theinitializer_list.[..]
template<class T,classStrictWeakOrder<auto, T> Compare>requires CopyConstructible<T> pair<constT&,constT&> minmax(initializer_list<T> t, Compare comp);
-24-Requires: typeTisLessThanComparableandCopyConstructible.-25-Returns:
pair<whereconstT&,constT&>(x, y)xis thesmallest value andylargest value in theinitializer_list.
pair should be removedSection: 22.3[pairs]Status:NADSubmitter: Daniel KrüglerOpened: 2008-10-04Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [pairs].
View all issues withNAD status.
Discussion:
The current WP provides the following assignment operators forpairin 22.3[pairs]/1:
template<class U , class V>requires HasAssign<T1, const U&> && HasAssign<T2, const V&>pair& operator=(const pair<U , V>& p);
requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
template<class U , class V>requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type>pair& operator=(pair<U , V>&& p);
It seems that the functionality of (2) is completely covered by (3), therefore(2) should be removed.
[Batavia (2009-05):]
Bill believes the extra assignment operators are necessary for resolvingambiguities, but that does not mean it needs to be part of the specification.
Move to Open.We recommend this be looked at in the context of the ongoing workrelated to the pair templates.
[2009-07 Frankfurt:]
Leave this open pending the removal of concepts from the WD.
[2009-10 Santa Cruz:]
Proposed resolution:
In 22.3[pairs] p. 1, classpair and just before p. 13 remove the declaration:
requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
tuple should be removedSection: 22.4.4.2[tuple.cnstr]Status:NADSubmitter: Daniel KrüglerOpened: 2008-10-04Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [tuple.cnstr].
View all otherissues in [tuple.cnstr].
View all issues withNAD status.
Discussion:
N2770 (and thus now the WP) removed thenon-template move-assignment operator from tuple's class definition,but the latter individual member description does still provide thisoperator. Is this (a) an oversight and can it (b) be solved as part of aneditorial process?
[Post Summit Daniel provided wording.]
[Batavia (2009-05):]
We believe that the proposed resolution's part 1 is editorial.
Regarding part 2, we either remove the specification as proposed,or else add back the declaration to which the specification refers.Alisdair and Bill prefer the latter.It is not immediately obvious whether the function is intended to be present.
We recommend that the Project Editor restore the missing declarationand that we keep part 2 of the issue alive.
Move to Open.
[2009-07 Frankfurt:]
Leave this open pending the removal of concepts from the WD.
[2009-10 Santa Cruz:]
Proposed resolution:
In 22.4.4[tuple.tuple], classtuple just before memberswap pleasechange as indicated:
[This fixes an editorial loss between N2798 to N2800]
template <class... UTypes>requires HasAssign<Types, const UTypes&>...tuple& operator=(const pair<UTypes...>&);template <class... UTypes>requires HasAssign<Types, RvalueOf<UTypes>::type>...tuple& operator=(pair<UTypes...>&&);
In 22.4.4.2[tuple.cnstr], starting just before p. 11 please removeas indicated:
requires MoveAssignable<Types>... tuple& operator=(tuple&& u);
-11-Effects: Move-assigns each element ofuto the correspondingelement of*this.
-12-Returns:*this.
Section: 22.4.4.4[tuple.swap]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2008-10-04Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
Issue522(i) was accepted aftertuple had been conceptualized,therefore this step needs to be completed.
[Post Summit Daniel adds]
This is now NAD Editorial (addressed byN2844)except for item 3 in the proposed wording.
[2009-05-01 Daniel adds:]
As of the recent WP(N2857),this issue is now completely covered by editorial changes (including the third bullet), therefore I unconditionally recommend NAD.
[Batavia (2009-05):]
We observed that all the proposed changes have already been applied to theWorking Draft, rendering this issue moot.
Move to NAD.
Proposed resolution:
In both 22.4.1[tuple.general]/2 and 22.4.12[tuple.special] change
template <classSwappable... Types>void swap(tuple<Types...>& x, tuple<Types...>& y);
In 22.4.4[tuple.tuple], classtuple definition and in22.4.4.4[tuple.swap], change
requires Swappable<Types>...void swap(tuple&);
In 22.4.4.4[tuple.swap] remove the current requires-clause, which says:
Requires: Each type inTypesshall beSwappable
forward_)list specialized remove algorithms are over constrainedSection: 23.3.7.6[forward.list.ops], 23.3.11.5[list.ops]Status:NADSubmitter: Daniel KrüglerOpened: 2008-10-06Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [forward.list.ops].
View all issues withNAD status.
Discussion:
The signatures offorwardlist::remove andlist::removedefined in [forwardlist.ops] before 11 + 23.3.11.5[list.ops] before 15:
requires EqualityComparable<T> void remove(const T& value);
are asymmetric to their predicate variants (which only requirePredicate,notEquivalenceRelation) and with the free algorithmremove (which only requireHasEqualTo). Also, nothing in thepre-concept WPN2723implies thatEqualityComparable shouldbe the intended requirement.
[Batavia (2009-05):]
We agree with the proposed resolution,but would like additional input from concepts experts.
Move to Review.
[2009-07-21 Alisdair adds:]
Current rationale and wording for this issue is built around concepts. Isuggest the issue reverts to Open status. I believe there is enough ofan issue to review after concepts are removed from the WP to re-examinethe issue in Santa Cruz, rather than resolve as NAD Concepts.
[2009-10-10 Daniel adds:]
Recommend NAD: The concept-free wording as ofN2960has no longer theover-specified requirement
EqualityComparablefor the remove function that uses==. In fact, nowthe same test conditions existsas for the free algorithmremove(26.7.8[alg.remove]). The error wasintroduced in the process of conceptifying.
[2009-10 Santa Cruz:]
NAD, solved by the removal of concepts.
Proposed resolution:
Replace in [forwardlist.ops] before 11 and in 23.3.11.5[list.ops] before 15
requiresEqualityComparable<T>HasEqualTo<T, T> void remove(const T& value);
Section: 32.5.4[atomics.order]Status:NAD EditorialSubmitter: Anthony WilliamsOpened: 2008-10-19Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.order].
View all otherissues in [atomics.order].
View all issues withNAD Editorial status.
Discussion:
Addresses UK 313
There was an interesting issue raised over on comp.programming.threadstoday regarding the following example
// Thread 1:x.store(1, memory_order_relaxed); // SXatomic_thread_fence(memory_order_seq_cst); // F1y.store(1, memory_order_relaxed); // SY1atomic_thread_fence(memory_order_seq_cst); // F2r1 = y.load(memory_order_relaxed); // RY// Thread 2:y.store(0, memory_order_relaxed); // SY2atomic_thread_fence(memory_order_seq_cst); // F3r2 = x.load(memory_order_relaxed); // RX
is the outcomer1 == 0 andr2 == 0 possible?
I think the intent is that this is not possible, but I am not sure thewording guarantees that. Here is my analysis:
Since all the fences are SC, there must be a total order between them.F1 must be beforeF2 in that order since they are inthe same thread. ThereforeF3 is either beforeF1,betweenF1 andF2 or afterF2.
IfF3 isafterF2, then we can apply 32.5.4[atomics.order]p5 fromN2798:
For atomic operations
AandBon an atomic objectM, whereAmodifiesMandBtakesits value, if there arememory_order_seq_cstfencesXandYsuch thatAis sequenced beforeX,Yis sequenced beforeB, andXprecedesYinS, thenBobserves either the effects ofAor a later modification ofMin its modificationorder.
In this case,A isSX,B isRX, thefenceX isF2 and the fenceY isF3,soRX must see 1.
IfF3 isbeforeF2, this doesn't apply, butF3 can therefore be before or afterF1.
IfF3 isafterF1, the same logic applies, but thistime the fenceX isF1. Therefore again,RXmust see 1.
Finally we have the case thatF3 isbeforeF1in the SC ordering. There are now no guarantees aboutRX, andRX can seer2==0.
We can apply 32.5.4[atomics.order]p5 again. This time,A isSY2,B isRY,X isF3 andY isF1. ThusRY must observethe effects ofSY2 or a later modification ofy in itsmodification order.
SinceSY1 is sequenced beforeRY,RY mustobserve the effects ofSY1 or a later modification ofy in its modification order.
In order to ensure thatRY sees(r1==1), we must seethatSY1 is later in the modification order ofy thanSY2.
We're now skating on thin ice. Conceptually,SY2 happens-beforeF3,F3 is SC-ordered beforeF1,F1happens-beforeSY1, soSY1 is later in themodification orderM ofy, andRY must seethe result ofSY1 (r1==1). However, I don't think thewords are clear on that.
[Post Summit Hans adds:]
In my (Hans') view, our definition of fences will always be weaker thanwhat particular hardware will guarantee.
Memory_order_seq_cstfencesinherently don't guarantee sequential consistency anyway, for goodreasons (e.g. because they can't enforce a total order on stores). Hence I don't think the issue demonstrates a gross failure to achievewhat we intended to achieve. The example in question is a bit esoteric. Hence, in my view, living with the status quo certainly wouldn't be adisaster either.In any case, we should probably add text along the lines of thefollowing between p5 and p6 in 32.5.4[atomics.order]:
[Note:
Memory_order_seq_cstonly ensures sequential consistency for adata-race-free program that uses exclusivelymemory_order_seq_cstoperations. Any use of weaker ordering will invalidate this guaranteeunless extreme care is used. In particular,memory_order_seq_cstfencesonly ensure a total order for the fences themselves. They cannot, ingeneral, be used to restore sequential consistency for atomic operationswith weaker ordering specifications.]Also see thread beginning at c++std-lib-23271.
[Herve's correction:]
Minor point, and sorry for the knee jerk reaction: I admit to havingno knowledge of Memory_order_seq_cst, but my former boss (John Lakos)has ingrained an automatic introspection on the use of "only". Ithink you meant:
[Note:
Memory_order_seq_cstensures sequential consistency onlyfor . . . . In particular,memory_order_seq_cstfences ensure atotal order only for . . .Unless, of course,
Memory_order_seq_cstreally do nothing but ensuresequential consistency for a data-race-free program that usesexclusivelymemory_order_seq_cstoperations.
[2009-10 Santa Cruz:]
NAD Editorial. Solved byN2992.
Proposed resolution:
Add a new paragraph after 32.5.4[atomics.order]p5 that says
For atomic operations
AandBon an atomic objectM, whereAandBmodifyM, if therearememory_order_seq_cstfencesXandYsuchthatAis sequenced beforeX,Yis sequencedbeforeB, andXprecedesYinS,thenBoccurs later thanAin the modifiction order ofM.
Dereferenceable should beHasDereferenceSection: 99 [allocator.concepts]Status:NAD ConceptsSubmitter: Pablo HalpernOpened: 2008-10-23Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
99 [allocator.concepts] contains a reference to a concept namedDereferenceable. No such concept exists.
[Daniel adds 2009-02-14:]
The proposal given in the paperN2829would automatically resolve this issue.
[Batavia (2009-05):]
This particular set of changes has already been made.There are two related changes later on (and possibly also an earlier Example);these can be handled editorially.
Move to NAD Editorial.
Proposed resolution:
Change all uses of the conceptDereferenceable toHasDereference in 99 [allocator.concepts].
tuple's comparison operatorsSection: 22.4.9[tuple.rel]Status:NAD ConceptsSubmitter: Joe GottmanOpened: 2008-10-28Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [tuple.rel].
View all otherissues in [tuple.rel].
View all issues withNAD Concepts status.
Discussion:
In the latest working draft for C++0x,tuple'soperator== andoperator<are declared as
template<class... TTypes, class... UTypes> requires EqualityComparable<TTypes, UTypes>... bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
and
template<class... TTypes, class... UTypes> requires LessThanComparable<TTypes, UTypes>... bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
But the conceptsEqualityComparable andLessThanComparable only take one parameter, not two. Also, even ifLessThanComparable could take two parameters, the definition oftuple::operator<() should also require
LessThanComparable<UTypes, TTypes>... // (note the order)
since the algorithm fortuple::operator< is the following (pseudo-code)
for (size_t N = 0; N < sizeof...(TTypes); ++N) { if (get<N>(t) < get<N>(u) return true; else if ((get<N>(u) < get<N>(t)) return false; } return false;Similar problems hold fortuples's other comparison operators.
[Post Summit:]
Recommend Tentatively Ready.
Proposed resolution:
In 22.4.1[tuple.general] and 22.4.9[tuple.rel] change:
template<class... TTypes, class... UTypes> requiresEqualityComparableHasEqualTo<TTypes, UTypes>... bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&);template<class... TTypes, class... UTypes> requiresLessThanComparableHasLess<TTypes, UTypes>...&& HasLess<UTypes, TTypes>... bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&);template<class... TTypes, class... UTypes> requiresEqualityComparableHasEqualTo<TTypes, UTypes>... bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);template<class... TTypes, class... UTypes> requiresLessThanComparableHasLess<UTTypes,TUTypes>...&& HasLess<UTypes, TTypes>... bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&);template<class... TTypes, class... UTypes> requiresLessThanComparableHasLess<UTTypes,TUTypes>...&& HasLess<UTypes, TTypes>... bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&);template<class... TTypes, class... UTypes> requiresLessThanComparableHasLess<TTypes, UTypes>...&& HasLess<UTypes, TTypes>... bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&);
Section: 23.3.3[array]Status:NADSubmitter: Niels DekkerOpened: 2008-11-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [array].
View all issues withNAD status.
Discussion:
The Working Draft (N2798) allows access to the elements ofstd::array by itsdata() member function:
23.2.1.4 array::data [array.data]
T *data(); const T *data() const;
- Returns: elems.
Unfortunately, the result ofstd::array::data() cannot be boundto a reference to a built-in array of the type ofarray::elems.Andstd::array provides no other way to get a reference toarray::elems. This hampers the use ofstd::array, for example when trying topass its data to a C style API function:
// Some C style API function. void set_path( char (*)[MAX_PATH] ); std::array<char,MAX_PATH> path; set_path( path.data() ); // error set_path( &(path.data()) ); // error
Another example, trying to pass the array data to an instance of anotherC++ class:
// Represents a 3-D point in space. class three_d_point { public: explicit three_d_point(const double (&)[3]); }; const std::array<double,3> coordinates = { 0, 1, 2 }; three_d_point point1( coordinates.data() ); // error. three_d_point point2( *(coordinates.data()) ); // error.A user might be tempted to usestd::array::elems instead, butdoing so isn't recommended, becausestd::array::elems is "forexposition only". Note that Boost.Array users might already useboost::array::elems, as its documentation doesn't explicitlystate thatboost::array::elems is for exposition only:http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
I can think of three options to solve this issue:
std::array::elems, as well as the note saying that "elems isshown for exposition only."std::array::data(), so that it wouldreturn a reference to the built-in array, instead of a pointer to itsfirst element.Lawrence Crowl wrote me that it might be better to leavestd::array::elems "for exposition only", to allow alternaterepresentations to allocate the array data dynamically. This might beof interest to the embedded community, having to deal with very limitedstack sizes.
The second option, changing the return type ofstd::array::data(), would break backward compatible to currentBoost and TR1 implementations, as well as to the other contiguouscontainer (vector andstring) in a very subtle way.For example, the following call tostd::swap currently swap twolocally declared pointers(data1, data2), for any containertypeT that has adata() member function. Whenstd::array::data() is changed to return a reference, thestd::swap call may swap the container elements instead.
template <typename T> void func(T& container1, T& container2) { // Are data1 and data2 pointers or references? auto data1 = container1.data(); auto data2 = container2.data(); // Will this swap two local pointers, or all container elements? std::swap(data1, data2); }The following concept is currently satisfied by all contiguouscontainers, but it no longer is forstd::array, whenarray::data()is changed to return a reference (tested on ConceptGCC Alpha 7):
auto concept ContiguousContainerConcept<typename T> { typename value_type = typename T::value_type; const value_type * T::data() const; }Still it's worth considering havingstd::array::data() return areference, because it might be the most intuitive option, from a user'spoint of view. Nicolai Josuttis (who wroteboost::array)mailed me that he very much prefers this option.
Note that for this option, the definition ofdata() would alsoneed to be revised for zero-sized arrays, as its return type cannot be areference to a zero-sized built-in array. Regarding zero-sized array,data() could throw an exception. Or there could be a partialspecialization ofstd::array wheredata() returnsT* or gets removed.
Personally I prefer the third option, adding a new member function tostd::array, overloaded for const and non-const access,returning a reference to the built-in array, to avoid those compatibleissues. I'd propose naming the functionstd::array::c_array(),which sounds intuitive to me. Note thatboost::array alreadyhas ac_array() member, returning a pointer, but Nicolai toldme that this one is only there for historical reasons. (Otherwise a namelikestd::array::native_array() orstd::array::builtin_array() would also be fine with me.) According to my proposed resolution, a zero-sizedstd::array does not needto havec_array(), while it is still required to havedata() functions.
[Post Summit:]
Alisdair: Don't like p4 suggesting implementation-defined behaviour.
Walter: What about an explicit conversion operator, instead of addingthe new member function?
Alisdair: Noodling about:
template<size_t N, ValueType T>struct array{ T elems[N];// fantasy code starts here// crazy decltype version for grins only//requires True<(N>0)>//explict operator decltype(elems) & () { return elems; }// conversion to lvalue refrequires True<(N>0)>explict operator T(&)[N] () & { return elems; }// conversion to const lvalue refrequires True<(N>0)>explict operator const T(&)[N] () const & { return elems; }// conversion to rvalue ref using ref qualifiersrequires True<(N>0)>explict operator T(&&)[N] () && { return elems; }// fantasy code ends hereexplicit operator bool() { return true; }};This seems legal but odd. Jason Merrill says currently a CWG issue 613on the non-static data member that fixes the error that current G++gives for the non-explicit, non-conceptualized version of this. Verdictfrom human compiler: seems legal.
Some grumbling about zero-sized arrays being allowed and supported.
Walter: Would this address the issue? Are we inclined to go this route?
Alan: What would usage look like?
// 3-d point in spacestruct three_d_point{ explicit three_d_point(const double (&)[3]);};void sink(double*);const std::array<double, 3> coordinates = { 0, 1, 2 };three_d_point point1( coordinates.data() ); //errorthree_d_point point2( *(coordinates.data()) ); // errorthree_d_point point3( coordinates ); // yay!sink(cooridinates); // error, no conversionRecommended Open with new wording. Take the required clause and add theexplicit conversion operators, not have a
typedef. At issue still is usedecltypeor useT[N]. In favour of usingT[N], even though use ofdecltypeis specially clever.
[Post Summit, further discussion in the thread starting with c++std-lib-23215.]
[2009-07 post-Frankfurt (Saturday afternoon group):]
The idea to resolve the issue by adding explicit conversion operatorswas abandoned, because it would be inconvenient to use, especially whenpassing the array to a template function, as mentioned by Daniel. So wereconsidered the original proposed resolution, which appearedacceptable, except for its proposed changes to 23.3.3.5[array.zero], whichallowed
c_array_typeandc_array()to be absent for a zero-sized array.Alisdair argued that such wording would disallow certain generic usecases. New wording for 23.3.3.5[array.zero] was agreed upon (Howard: andis reflected in the proposed resolution).Move to Review
[2009-07-31 Alisdair adds:]
I will be unhappy voting the proposed resolution for 930 past reviewuntil we have implementation experience with reference qualifiers. Specifically, I want to understand the impact of the missing overloadfor
const &&(if any.)If we think the issue is important enough it might be worthwhilestripping the ref qualifiers for easy progress next meeting, and openingyet another issue to put them back with experience.
Recommend deferring any decision on splitting the issue until we get LWGfeedback next meeting - I may be the lone dissenting voice if others areprepared to proceed without it.
[2009-10 Santa Cruz:]
Mark as NAD. There was not enough consensus that this was sufficientlyuseful. There are known other ways to do this, such as small inlineconversion functions.
Proposed resolution:
Add to the template definition of array, 23.3.3[array]/3:
typedef T c_array_type[N];c_array_type & c_array() &;c_array_type && c_array() &&;const c_array_type & c_array() const &;
Add the following subsection to 23.3.3[array], after [array.data]:
23.2.1.5 array::c_array [array.c_array]
c_array_type & c_array() &;c_array_type && c_array() &&;const c_array_type & c_array() const &;Returns:
elems.
Change Zero sized arrays 23.3.3.5[array.zero]:
-2- ...
The type
c_array_typeis unspecified for a zero-sized array.-3- The effect of calling
c_array(),front(), orback()for a zero-sized array is implementation defined.
Section: 20.3.1.3.6[unique.ptr.single.modifiers]Status:NADSubmitter: Alisdair MeredithOpened: 2008-11-27Last modified: 2018-06-23
Priority:Not Prioritized
View all otherissues in [unique.ptr.single.modifiers].
View all issues withNAD status.
Discussion:
If we are supporting stateful deleters, we need an overload forreset thattakes a deleter as well.
void reset(pointer p, deleter_type d);
We probably need two overloads to support move-only deleters, andthis sounds uncomfortably like the two constructors I have been ignoringfor now...
[Batavia (2009-05):]
Howard comments that we have the functionality via move-assigment.
Move to Open.
[2009-10 Santa Cruz:]
Mark as NAD Future.
[2017-02 in Kona, LEWG recommends NAD]
Pointer-accepting overloads ofreset() are discouraged — the samefunctionality is available via move-assignment and that is more idiomatic.
[2017-06-02 Issues Telecon]
Resolve as NAD
Proposed resolution:
Section: 30.7[time.clock]Status:NADSubmitter: Beman DawesOpened: 2008-11-24Last modified: 2019-02-26
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Each of the three clocks specified in Clocks 30.7[time.clock]provides the member function:
static time_point now();
The semantics specified by Clock requirements 30.3[time.clock.req]make no mention of error handling. Thus the function may throwbad_allocor an implementation-defined exception (16.4.6.14[res.on.exception.handling]paragraph 4).
Some implementations of these functions on POSIX, Windows, andpresumably on other operating systems, may fail in ways only detectableat runtime. Some failures on Windows are due to supporting chipseterrata and can even occur after successful calls to a clock'snow()function.
These functions are used in cases where exceptions are not appropriateor where the specifics of the exception or cause of error need to beavailable to the user. SeeN2828,Library Support for hybrid errorhandling (Rev 1), for more specific discussion of use cases. Thus some change inthe interface of now is required.
The proposed resolution has been implemented in the Boost version of thechrono library. No problems were encountered.
[Batavia (2009-05):]
We recommend this issue be deferred until the next Committee Drafthas been issued and the prerequisite paper has been accepted.
Move to Open.
[2009-10 Santa Cruz:]
Mark as NAD future. Too late to make this change without having alreadyaccepted the hybrid error handling proposal.
[LEWG Kona 2017]
Recommend NAD. Needs a paper. Proposed resolution no longer applies.
Proposed resolution:
Accept the proposed wording ofN2828,Library Support for hybrid error handling (Rev 1).
ChangeClock requirements 30.3[time.clock.req] as indicated:
-2- In Table 55
C1andC2denote clock types.t1andt2are values returned byC1::now()where the call returningt1happens before (1.10) the call returningt2andboth of these calls happen beforeC1::time_point::max().ecdenotes an object of typeerror_code(19.5.4.1[syserr.errcode.overview]).
Table 55 — Clock requirements Expression Return type Operational semantics ... ... ... C1::now()C1::time_pointReturns a time_pointobject representing the current point in time.C1::now(ec)C1::time_pointReturns a time_pointobject representing the current point in time.
Change classsystem_clock 30.7.2[time.clock.system] as indicated:
static time_point now(error_code& ec=throws());
Change classmonotonic_clock 99 [time.clock.monotonic] as indicated:
static time_point now(error_code& ec=throws());
Change classhigh_resolution_clock 30.7.8[time.clock.hires] as indicated:
static time_point now(error_code& ec=throws());
Section: 32.5[atomics]Status:NAD EditorialSubmitter: Clark NelsonOpened: 2008-12-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withNAD Editorial status.
Discussion:
Addresses US 89
The types in the table "Atomics for standard typedef types" should betypedefs, not classes. These semantics are necessary for compatibilitywith C.
Change the classes to typedefs.
N2427specified different requirements for atomic analogs of fundamentalinteger types (such asatomic_int) and for atomic analogs of<cstdint>typedefs (such asatomic_size_t). Specifically,atomic_int et al. werespecified to be distinct classes, whereasatomic_size_t et al. werespecified to be typedefs. Unfortunately, in applyingN2427to the WD, that distinction was erased, and the atomic analog of every<cstdint>typedef is required to be a distinct class.
It shouldn't be required that the atomic analog of every<cstdint>typedef be a typedef for some fundamental integer type. After all,<cstdint> is supposed to provide standard names for extended integertypes. So there was a problem inN2427,which certainly could have beeninterpreted to require that. But the status quo in the WD is even worse,because it's unambiguously wrong.
What is needed are words to require the existence of a bunch of typenames, without specifying whether they are class names or typedef names.
[Summit:]
Change status to NAD, editorial. See US 89 comment notes above.
Direct the editor to turn the types into typedefs as proposed in thecomment. Paper approved by committee used typedefs, this appears to havebeen introduced as an editorial change. Rationale: for compatibilitywith C.
Proposed resolution:
Section: 16[library]Status:NADSubmitter: Niels DekkerOpened: 2008-12-18Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
The assignment and equality operators= and== are easily confused, justbecause of their visual similarity, and in this case a simple typo can causea serious bug. When the left side of anoperator= is an rvalue, it'shighly unlikely that the assignment was intended by the programmer:
if ( func() = value ) // Typical typo: == intended!
Built-in types don't support assignment to an rvalue, but unfortunately,a lot of types provided by the Standard Library do.
Fortunately the language now offers a syntax to prevent a certain memberfunction from having an rvalue as*this: by adding a ref-qualifier (&)to the member function declaration. Assignment operators are explicitlymentioned as a use case of ref-qualifiers, in "Extending Move SemanticsTo*this (Revision 1)",N1821 by DaveedVandevoorde and Bronek Kozicki
Hereby I would like to propose adding ref-qualifiers to all appropriateassignment operators in the library.
[Batavia (2009-05):]
Move to Open.We recommend this be deferred until after the next Committee Draft.
[Frankfurt 2009-07:]
The LWG declined to move forward withN2819.
Moved to NAD.
Proposed resolution:
A proposed resolution is provided by the paper on this subject,N2819,Ref-qualifiers for assignment operators of the Standard Library
Section: 32.5[atomics]Status:DupSubmitter: Holger GrundOpened: 2008-12-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withDup status.
Duplicate of:880
Discussion:
I'm looking at 32.5[atomics] and can't really make sense of a couple of things.
Firstly, there appears to be a typo in the<cstdatomic> synopsis:
The
atomic_exchangeoverload taking anatomic_addressis missing the second parameter:void* atomic_exchange(volatile atomic_address*);should be
void* atomic_exchange(volatile atomic_address*, void*);Note, that this isnot covered by880(i) "Missing atomic exchange parameter",which only talks about the
atomic_bool.
Proposed resolution:
Change the synopsis in 32.5[atomics]/2:
void* atomic_exchange(volatile atomic_address*, void*);
system_clock::rep not specifiedSection: 30.7.2[time.clock.system]Status:NAD EditorialSubmitter: Pete BeckerOpened: 2008-12-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time.clock.system].
View all issues withNAD Editorial status.
Discussion:
In 30.7.2[time.clock.system], the declaration ofsystem_clock::rep says "seebelow", but there is nothing below that describes it.
[Howard adds:]
This note refers to:
-2-
system_clock::duration::min() < system_clock::duration::zero()shall betrue.I.e. this is standardeze for "
system_clock::repis signed".Perhaps an editorial note along the lines of:-2-
system_clock::duration::min() < system_clock::duration::zero()shall betrue.[Note:system_clock::repshall be signed.-- end note].?
[Batavia (2009-05):]
We agree with the direction of the proposed resolution.Move to NAD Editorial.
Proposed resolution:
Add a note to 30.7.2[time.clock.system], p2:
-2-
system_clock::duration::min() < system_clock::duration::zero()shall betrue.[Note:system_clock::repshall be signed.-- end note].
duration_cast improperly specifiedSection: 30.5.8[time.duration.cast]Status:NADSubmitter: Pete BeckerOpened: 2008-12-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time.duration.cast].
View all issues withNAD status.
Discussion:
30.5.8[time.duration.cast]/3:
.... All intermediate computations shall becarried out in the widest possible representation... .
So ignoring floating-point types for the moment, all this arithmetic has to be doneusing the implementation's largest integral type, even if both argumentsuseint for their representation. This seems excessive. And it's not atall clear what this means if we don't ignore floating-point types.
This issue is related to952(i).
[Howard adds:]
The intent of this remark is that intermediate computations are carried outusing:
common_type<typename ToDuration::rep, Rep, intmax_t>::typeThe Remark was intended to be clarifying prose supporting the rather algorithmic descriptionof the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph3 (Remarks) would be better dropped?
[Batavia (2009-05):]
We view this as a specific case of issue952(i),and should be resolved when that issue is resolved.
Move to NAD.
Proposed resolution:
Section: 30.5.8[time.duration.cast]Status:NAD EditorialSubmitter: Pete BeckerOpened: 2009-01-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time.duration.cast].
View all issues withNAD Editorial status.
Discussion:
30.5.8[time.duration.cast] specifies an implementation and imposesrequirements in text (and the implementation doesn't satisfy all of thetext requirements). Pick one.
This issue is related to946(i).
[2009-05-10 Howard adds:]
TheRemarks paragraph is an English re-statement of the preceedingReturns clause. It was meant to be clarifying and motivating, notconfusing. I'm not aware with how theRemarks contradicts theReturns clausebut I'm ok with simply removing theRemarks.
[Batavia (2009-05):]
Pete suggests that this could be resolvedby rephrasing the Remarks to Notes.
Move to NAD Editorial.
Proposed resolution:
Section: 30.3[time.clock.req]Status:NADSubmitter: Pete BeckerOpened: 2009-01-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time.clock.req].
View all issues withNAD status.
Discussion:
30.3[time.clock.req] requires that a clock type have a membertypedef namedtime_point that names an instantiation of thetemplatetime_point, and a member namedduration thatnames an instantiation of the templateduration. This mixing oflevels is confusing. The typedef names should be different from thetemplate names.
[Post Summit, Anthony provided proposed wording.]
[2009-05-04 Howard adds:]
The reason that the typedef names were given the same name as the class templateswas so that clients would not have to stop and think about whether they wereusing the clock's native
time_point/durationor the classtemplate directly. In this case, one person's confusion is another person'sencapsulation. The detail that sometimes one is referring to the clock'snative types, and sometimes one is referring to an independent type ispurposefully "hidden" because it is supposed to be an unimportantdetail. It can be confusing to have to remember when to typedurationand when to typeduration_type, and there is no need to require theclient to remember something like that.For example, here is code that I once wrote in testing out the usability ofthis facility:
template <class Clock, class Duration>void do_until(const std::chrono::time_point<Clock, Duration>& t){ typename Clock::time_point now = Clock::now(); if (t > now) { typedef typename std::common_type < Duration, typename std::chrono::system_clock::duration >::type CD; typedef std::chrono::duration<double, std::nano> ID; CD d = t - now; ID us = duration_cast<ID>(d); if (us < d) ++us; ... }}I see no rationale to require the client to append
_typetosomeof those declarations. It seems overly burdensome on the author ofdo_until:template <class Clock, class Duration>void do_until(const std::chrono::time_point<Clock, Duration>& t){ typename Clock::time_point_type now = Clock::now(); if (t > now) { typedef typename std::common_type < Duration, typename std::chrono::system_clock::duration_type >::type CD; typedef std::chrono::duration<double, std::nano> ID; CD d = t - now; ID us = duration_cast<ID>(d); if (us < d) ++us; ... }}Additionally I'm fairly certain that this suggestion hasn't been implemented.If it had, it would have been discovered that it is incomplete.
time_pointalso has a nested type (purposefully) namedduration.That is, the current proposed wording would put the WP into an inconsistent state.
In contrast,the current WP has been implemented and I've received very favorable feedbackfrom people using this interface in real-world code.
[Batavia (2009-05):]
Bill agrees that distinct names should be used for distinct kinds of entities.
Walter would prefer not to suffix type names,especially for such well-understood terms as "duration".
Howard reminds us that the proposed resolution is incomplete, per his commentin the issue.
Move to Open.
[2009-06-07 Howard adds:]
Not meaning to be argumentative, but we have a decade of positive experiencewith the precedent of using the same name for the nested type as an externalclass representing an identical concept.
template<class Category, class T, class Distance = ptrdiff_t, class Pointer = T*, class Reference = T&>structiterator{ ...};template <BidirectionalIterator Iter>classreverse_iterator{ ...};template <ValueType T, Allocator Alloc = allocator<T> > requires NothrowDestructible<T>class list{public: typedefimplementation-definediterator; ... typedef reverse_iterator<iterator>reverse_iterator; ...};I am aware ofzero complaints regarding the use of
iteratorandreverse_iteratoras nested types of the containers despite thesenames also having related meaning at namespace std scope.Would we really be doing programmers a favor by renaming these nested types?
template <ValueType T, Allocator Alloc = allocator<T> > requires NothrowDestructible<T>class list{public: typedefimplementation-definediterator_type; ... typedef reverse_iterator<iterator>reverse_iterator_type; ...};I submit that such design contributes to needless verbosity which ends upreducing readability.
[2009-10 Santa Cruz:]
Mark as NAD. No concensus for changing the WP.
Proposed resolution:
Change 30[time]:
...template <class Clock, class Duration = typename Clock::duration_type> class time_point;...
Change 30.3[time.clock.req]:
Table 45 -- Clock requirements Expression Return type Operational semantics ... ... ... C1::duration_typechrono::duration<C1::rep, C1::period>The native durationtype of the clock.C1::time_point_typechrono::time_point<C1>orchrono::time_point<C2, C1::duration_type<The native time_pointtype of the clock. Different clocks may share atime_point_typedefinition if it is valid to compare theirtime_point_types by comparing their respectiveduration_types.C1andC2shall refer to the same epoch.... ... ... C1::now()C1::time_point_typeReturns a time_point_typeobject representing the current point in time.
Change 30.7.2[time.clock.system]:
-1- Objects of class
system_clockrepresent wall clock time from the system-wide realtime clock.class system_clock { public: typedefsee below rep; typedef ratio<unspecified,unspecified> period; typedef chrono::duration<rep, period> duration_type; typedef chrono::time_point<system_clock> time_point_type; static const bool is_monotonic =unspecified ; static time_point_type now(); // Map to C API static time_t to_time_t (const time_point_type& t); static time_point_type from_time_t(time_t t); };-2-
system_clock::duration_type::min() < system_clock::duration_type::zero()shall betrue.time_t to_time_t(const time_point_type& t);-3-Returns: A
time_tobject that represents the samepoint in time astwhen both values are truncated to thecoarser of the precisions oftime_tandtime_point_type.time_point_typefrom_time_t(time_t t);-4-Returns: A
time_point_typeobject that represents the same pointin time astwhen both values are truncated to the coarser of theprecisions oftime_tandtime_point_type.
Change 99 [time.clock.monotonic]:
class monotonic_clock { public: typedefunspecified rep; typedef ratio<unspecified ,unspecified> period; typedef chrono::duration<rep, period> duration_type; typedef chrono::time_point<unspecified , duration_type> time_point_type; static const bool is_monotonic = true; static time_point_type now();};Change 30.7.8[time.clock.hires]:
class high_resolution_clock { public: typedefunspecified rep; typedef ratio<unspecified ,unspecified> period; typedef chrono::duration<rep, period> duration_type; typedef chrono::time_point<unspecified , duration_type> time_point_type; static const bool is_monotonic = true; static time_point_type now();};Section: 32.7.4[thread.condition.condvar]Status:NADSubmitter: Pete BeckerOpened: 2009-01-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvar].
View all issues withNAD status.
Discussion:
32.7.4[thread.condition.condvar]:condition_variable::wait_foris required to compute the absolute time by adding the duration value tochrono::monotonic_clock::now(), butmonotonic_clock is not required toexist.
[Summit:]
Move to open. Associate with LWG859(i) and any other monotonic-clockrelated issues.
[2009-08-01 Howard adds:]
I believe that859(i) (currently Ready) addresses this issue, andthat this issue should be marked NAD, solved by859(i) (assumingit moves to WP).
[2009-10 Santa Cruz:]
Leave open, but expect to be fixed by N2969 revision that Detlef is writing.
[2009-11-18 Moved to Tentatively NAD after 5 positive votes on c++std-lib.Rationale added below.]
Proposed resolution:
Rationale:
condition_variable::wait_for no longer refers tomonotonic_clock, so this issue is moot.
Section: 26.6.5[alg.foreach]Status:NAD EditorialSubmitter: Stephan T. LavavejOpened: 2009-01-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.foreach].
View all otherissues in [alg.foreach].
View all issues withNAD Editorial status.
Discussion:
Library Issue475(i) has CD1 status, but the non-normative note inN2723was removed inN2798(26.6.5[alg.foreach] in both drafts).
[Batavia (2009-05):]
Move to NAD Editorial.
Proposed resolution:
Restore the non-normative note. It might need to be expressed in terms of concepts.
Section: 19.5.4.5[syserr.errcode.nonmembers]Status:NADSubmitter: Beman DawesOpened: 2009-01-19Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Anthony Williams raised the question in c++std-lib-22987 "why is therestd::make_error_code(std::errc)? What purpose does this serve?"
The functionmake_error_code(errc e) is not required, sincemake_error_condition(errc e) is the function that is needed forerrcconversions.make_error_code(errc e) appears to be a holdover from myinitial confusion over the distinction between POSIX and operatingsystems that conform to the POSIX spec.
[Post Summit:]
Recommend Review.
[Batavia (2009-05):]
The designer of the facility (Christopher Kohlhoff)strongly disagrees that there is an issue here,and especially disagrees with the proposed resolution.Bill would prefer to be conservative and not apply this proposed resolution.Move to Open, and recommend strong consideration for NAD status.
[2009-05-21 Beman adds:]
My mistake. Christopher and Bill are correct and the issue should beNAD. The function is needed by users.
[2009-07-21 Christopher Kohlhoff adds rationale formake_error_code:]
Users (and indeed library implementers) may need to use the
errccodes in portable code. For example:void do_foo(error_code& ec){#if defined(_WIN32) // Windows implementation ...#elif defined(linux) // Linux implementation ...#else // do_foo not supported on this platform ec = make_error_code(errc::not_supported);#endif}
[2009 Santa Cruz:]
Moved to NAD.
Proposed resolution:
Change System error support 19.5[syserr], Header<system_error>synopsis, as indicated:
error_code make_error_code(errc e);error_condition make_error_condition(errc e);
Delete from Class error_code non-member functions19.5.4.5[syserr.errcode.nonmembers]:
error_code make_error_code(errc e);
Returns:error_code(static_cast<int>(e),generic_category).
Section: 16[library]Status:NAD EditorialSubmitter: Niels DekkerOpened: 2009-01-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD Editorial status.
Discussion:
Previous versions of the Draft had a table, defining the Assignable requirement. For exampleN2134Table 79, "Assignable requirements". But I guess the term "Assignable" is outdated by now, because the current Committee Draft providesMoveAssignable,CopyAssignable, andTriviallyCopyAssignable concepts instead. And as far as I can see, it no longer has a definition ofAssignable. (Please correct me if I'm wrong.) Still the word "Assignable" is used in eight places in the Draft,N2800.
Are all of those instances of "Assignable" to be replaced by "CopyAssignable"?
[Batavia (2009-05):]
Move to NAD Editorial.
Proposed resolution:
Change Exception Propagation 17.9.7[propagation]:
exception_ptrshall beDefaultConstructible,CopyConstructible,CopyAssignableandEqualityComparable.
Change Class template reference_wrapper 22.10.6[refwrap]:
reference_wrapper<T>is aCopyConstructibleandCopyAssignablewrapper around a reference to an object of typeT.
Change Placeholders 22.10.15.5[func.bind.place]:
It is implementation defined whether placeholder types are
CopyAssignable.CopyAssignableplaceholders' copy assignment operators shall not throw exceptions.
Change Class template shared_ptr 20.3.2.2[util.smartptr.shared]:
Specializations of
shared_ptrshall beCopyConstructible,CopyAssignable, andLessThanComparable...
Change Class template weak_ptr 20.3.2.3[util.smartptr.weak]:
Specializations of
weak_ptrshall beCopyConstructible,CopyAssignable, andLessThanComparable...
Change traits typedefs 27.2.3[char.traits.typedefs] (note: including deletion of reference to 23.1!):
Requires:
state_typeshall meet the requirements ofCopyAssignable(23.1),CopyConstructible(20.1.8), andDefaultConstructibletypes.
Change Class seed_seq 29.5.8.1[rand.util.seedseq] (note again: including deletion of reference to 23.1!):
In addition to the requirements set forth below, instances of
seed_seqshall meet the requirements ofCopyConstructible(20.1.8) and ofCopyAssignable(23.1).
Note: The proposed resolution of this issue does not deal with theinstance of the term "Assignable" in 99 [auto.ptr], as this is dealtwith more specifically by LWG973(i), "auto_ptr characteristics", submittedby Maarten Hilferink.
Section: 99 [auto.ptr]Status:NAD EditorialSubmitter: Maarten HilferinkOpened: 2009-01-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [auto.ptr].
View all issues withNAD Editorial status.
Discussion:
I think that the Note of 99 [auto.ptr], paragraph 3 needs a rewrite since "Assignable" is no longer defined as a concept. The relationship ofauto_ptr with the newCopyAssignable,MoveAssignable, andMoveConstructible concepts should be clarified.Furthermore, since the use ofauto_ptr is depreciated anyway, we can also omit a description of its intended use.
[Batavia (2009-05):]
We agree with the intent of the proposed resolution.Move to NAD Editorial.
Proposed resolution:
Change 99 [auto.ptr], paragraph 3:
The
Instances ofauto_ptrprovides a semantics of strict ownership. Anauto_ptrowns the ob ject it holds a pointer to. Copying anauto_ptrcopies the pointer and transfers ownership to thedestination. If more than oneauto_ptrowns the same ob ject atthe same time the behavior of the program is undefined. [Note:The uses ofauto_ptrinclude providing temporaryexception-safety for dynamically allocated memory, passing ownership ofdynamically allocated memory to a function, and returning dynamicallyallocated memory from a function.auto_ptrdoes not meet theCopyConstructibleandAssignablerequirements forstandard library container elements and thus instantiating a standardlibrary container with anauto_ptrresults in undefinedbehavior.auto_ptrshallmeet theMoveConstructibleandMoveAssignablerequirements, but do not meet theCopyConstructibleandCopyAssignablerequirements.--end note]
Section: 24.5.2[insert.iterators]Status:NADSubmitter: Howard HinnantOpened: 2009-02-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [insert.iterators].
View all issues withNAD status.
Discussion:
The new concepts for the insert iterators mandate an extra copy wheninserting an lvalue:
requires CopyConstructible<Cont::value_type> back_insert_iterator<Cont>& operator=(const Cont::value_type& value);-1-Effects:
push_back(*container,Cont::value_type(value));
The reason is to convertvalue into an rvalue because the currentBackInsertionContainer concept only handlespush_back-ingrvalues:
concept BackInsertionContainer<typename C> : Container<C> { void push_back(C&, value_type&&); }Without the conversion ofvalue to an rvalue, the assignment operatorfails to concept check.
A solution is to modify theBackInsertionContainer concept so thatthe client can pass in the parameter type forpush_back similar towhat is already done for theOutputIterator concept:
concept BackInsertionContainer<typename C, typename Value = C::value_type&&> : Container<C> { void push_back(C&, Value); }This allows the assignment operator to be adjusted appropriately:
requires BackInsertionContainer<Cont, Cont::value_type const&> && CopyConstructible<Cont::value_type> back_insert_iterator<Cont>& operator=(const Cont::value_type& value);-1-Effects:
push_back(*container, value);
[We may want to propagate this fix to other concepts such asStackLikeContainer.]
[Solution and wording collaborated on by Doug and Howard.]
[Batavia (2009-05):]
Howard notes that "these operations behaved efficiently until concepts were added."
Alisdair is uncertain that the proposed resolution is syntactically correct.
Move to Open, and recommend the issue be deferred until after the nextCommittee Draft is issued.
[2009-10 Santa Cruz:]
NAD, solved by the removal of concepts.
Proposed resolution:
Change [container.concepts.free]:
concept FrontInsertionContainer<typename C, typename Value = C::value_type&&> : Container<C> { void push_front(C&,value_type&&Value); axiom FrontInsertion(C c,value_typeValue x) { x == (push_front(c, x), front(c)); } }...
concept BackInsertionContainer<typename C, typename Value = C::value_type&&> : Container<C> { void push_back(C&,value_type&&Value); }...
concept InsertionContainer<typename C, typename Value = C::value_type&&> : Container<C> { iterator insert(C&, const_iterator,value_type&&Value); axiom Insertion(C c, const_iterator position,value_typeValue v) { v == *insert(c, position, v); } }
Change [container.concepts.member]:
auto concept MemberFrontInsertionContainer<typename C, typename Value = C::value_type&&> : MemberContainer<C> { void C::push_front(value_type&&Value); axiom MemberFrontInsertion(C c,value_typeValue x) { x == (c.push_front(x), c.front()); } }...
auto concept MemberBackInsertionContainer<typename C, typename Value = C::value_type&&> : MemberContainer<C> { void C::push_back(value_type&&Value); }...
auto concept MemberInsertionContainer<typename C, typename Value = C::value_type&&> : MemberContainer<C> { iterator C::insert(const_iterator,value_type&&Value); axiom MemberInsertion(C c, const_iterator position,value_typeValue v) { v == *c.insert(position, v); } }
Change [container.concepts.maps]:
template <MemberFrontInsertionContainer C, typename Value = C::value_type&&> concept_map FrontInsertionContainer<C, Value> { typedef Container<C>::value_type value_type; void push_front(C& c,value_type&&Value v) { c.push_front(static_cast<value_type&&Value>(v)); } }...
template <MemberBackInsertionContainer C, typename Value = C::value_type&&> concept_map BackInsertionContainer<C, Value> { typedef Container<C>::value_type value_type; void push_back(C& c,value_type&&Value v) { c.push_back(static_cast<value_type&&Value>(v)); } }...
template <MemberInsertionContainer C, typename Value = C::value_type&&> concept_map InsertionContainer<C, Value> { typedef Container<C>::value_type value_type; Container<C>::iterator insert(C& c, Container<C>::const_iterator i,value_type&&Value v) { return c.insert(i, static_cast<value_type&&Value>(v)); } }
Change 24.5.2.2[back.insert.iterator]:
template <BackInsertionContainer Cont> class back_insert_iterator { ... requiresBackInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type> back_insert_iterator<Cont>& operator=(const Cont::value_type& value); ...Change [back.insert.iter.op=]:
requiresBackInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type>back_insert_iterator<Cont>& operator=(const Cont::value_type& value);-1-Effects:
push_back(*container,Cont::value_type(value));
Change 24.5.2.3[front.insert.iterator]:
template <FrontInsertionContainer Cont> class front_insert_iterator { ... requiresFrontInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type> front_insert_iterator<Cont>& operator=(const Cont::value_type& value); ...Change [front.insert.iter.op=]:
requiresFrontInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type>front_insert_iterator<Cont>& operator=(const Cont::value_type& value);-1-Effects:
push_front(*container,Cont::value_type(value));
Change 24.5.2.4[insert.iterator]:
template <InsertionContainer Cont> class insert_iterator { ... requiresInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type> insert_iterator<Cont>& operator=(const Cont::value_type& value); ...Change [insert.iter.op=]:
requiresInsertionContainer<Cont, const Cont::value_type&>CopyConstructible<Cont::value_type>insert_iterator<Cont>& operator=(const Cont::value_type& value);-1-Effects:
iter = insert(*container, iter,Cont::value_type(value)); ++iter;
Section: 24.5.4[move.iterators]Status:NAD EditorialSubmitter: Howard HinnantOpened: 2009-02-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [move.iterators].
View all issues withNAD Editorial status.
Discussion:
24.5.4[move.iterators] has an incorrect example:
-2- [Example:
set<string> s; // populate the set s vector<string> v1(s.begin(), s.end()); // copies strings into v1 vector<string> v2(make_move_iterator(s.begin()), make_move_iterator(s.end())); // moves strings into v2-- end example]
One can not move from aset because the iterators returnconstreferences.
[Batavia (2009-05):]
We agree with the proposed resolution. Move to NAD Editorial.
Proposed resolution:
Change 24.5.4[move.iterators]/2:
-2- [Example:
setlist<string> s; // populate thesetlist s vector<string> v1(s.begin(), s.end()); // copies strings into v1 vector<string> v2(make_move_iterator(s.begin()), make_move_iterator(s.end())); // moves strings into v2-- end example]
mutex lock() missing error conditionsSection: 32.6.4[thread.mutex.requirements]Status:NADSubmitter: Ion GaztañagaOpened: 2009-02-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [thread.mutex.requirements].
View all otherissues in [thread.mutex.requirements].
View all issues withNAD status.
Discussion:
POSIX 2008 adds two return values forpthread_mutex_xxxlock():EOWNERDEAD (owner_dead) andENOTRECOVERABLE(state_not_recoverable). In the first case the mutex is locked,in the second case the mutex is not locked.
Throwing an exception in the first case can be incompatible with the useof Locks, since theLock::owns_lock() will befalse when the lock isbeing destroyed.
Consider:
//Suppose mutex.lock() throws "owner_dead"unique_lock ul(&mutex);//mutex left locked if "owner_dead" is thrown
Throwing an exception withowner_dead might be also undesirable ifrobust-mutex support is added to C++ and the user has the equivalent ofpthread_mutex_consistent() to notify the user has fixed the corrupteddata and the mutex state should be marked consistent.
state_not_recoverable add it to the list of Error conditions:owner_dead, no proposed resolution.[Summit:]
Not a defect. Handling these error conditions is an implementationdetail and must be handled below the C++ interface.
Proposed resolution:
Add to 32.6.4[thread.mutex.requirements], p12:
-12-Error conditions:
operation_not_permitted-- if the thread does not have the necessary permission to change the state of the mutex.resource_deadlock_would_occur-- if the current thread already owns the mutex and is able to detect it.device_or_resource_busy-- if the mutex is already locked and blocking is not possible.state_not_recoverable-- if the state protected by the mutex is not recoverable.
Reflexivity meaningless?Section: 99 [concept.comparison]Status:NADSubmitter: Alisdair MeredithOpened: 2009-02-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [concept.comparison].
View all issues withNAD status.
Discussion:
99 [concept.comparison] p2:
Due to the subtle meaning of== inside axioms, theReflexivity axiom doesnot do anything as written. It merely states that a value is substitutablewith itself, rather than asserting a property of the== operator.
Original proposed resolution:
Change the definition ofReflexivity in 99 [concept.comparison]:
axiom Reflexivity(T a) {(a == a) == true; }[Post Summit:]
Alisdair: I was wrong.
Recommend NAD.
Proposed resolution:
NAD.
Section: 16[library]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-02-24Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD Concepts status.
Discussion:
The example in 6.9p2 shows how late_check blocks inhibit concept_map lookupinside a constrained context, and so inhibit concept map adaption by usersto meet template requirements.
Do we need some text in clause 17 prohibitting use of late_check in librarytemplate definitions unless otherwise documented?
[Doug adds:]
We need something like this, but it should be a more general statementabout implementations respecting the concept maps provided by theuser. Use of late_check is one way in which implementations cansubvert the concept maps provided by the user, but there are otherways as well ("pattern-based" overloading, tricks with "auto" conceptmaps and defaulted associated type arguments).
[Batavia (2009-05):]
Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
Proposed resolution:
Section: 16.4.2.2[contents]Status:NADSubmitter: P.J. PlaugerOpened: 2009-03-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [contents].
View all issues withNAD status.
Discussion:
Addresses UK-169 [CD1]
This phrasing contradicts later freedom to implement the C standardlibrary portions in the global namespace as well as std. (17.6.2.3p4)
[Batavia (2009-05):]
The proposed wording seems to go too far.Move back to Open.
[2009-07 Frankfurt:]
Howard to add NB reference to the description of this issue.
Move to NAD. This comment is informative and not normative by the use ofthe word "are" instead of the word "shall."
A note linking to Annex D would help clarify the intention, here.
Robert to Open a separate issue proposing that the standard C headers beundeprecated, for the purpose of clarifying the standard.
[2009-07-22 Bill modified the proposed wording with a clarifying footnote.]
Proposed resolution:
Add a footnote to 16.4.2.2[contents], p2:
-2- All library entities except macros,
operator newandoperatordeleteare defined within the namespacestdor namespacesnested within namespacestd*.*The C standard library headers [depr.c.headers] also definenames within the global namespace, while the C++ headers forC library facilities 16.4.2.3[headers] may also define names withinthe global namespace.
Section: 16.3.2.3[structure.requirements]Status:NADSubmitter: David AbrahamsOpened: 2009-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [structure.requirements].
View all issues withNAD status.
Discussion:
As a practical matter there's disagreement on the meaning ofoperationalsemantics. If the text in 16.3.2.3[structure.requirements]p4 isn'tclear, it should be clarified. However, it's not clear whether thedisagreement is merely due to people not being aware of the text.
[Batavia (2009-05):]
Agree with the recommended NAD resolution.
Proposed resolution:
Recommend NAD. The text in 16.3.2.3[structure.requirements] isperfectly clear.
Section: 16[library]Status:NADSubmitter: David AbrahamsOpened: 2009-03-06Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
There are lots of places in the standard where we talk about "the moveconstructor" but where we mean "the move operation," i.e.T( move( x ) ).
We also don't account for whether that operation modifiesx or not, andwe need to.
[Batavia (2009-05):]
Move to Open, pending proposed wording from Dave for furtherreview.
[2010 Rapperswil:]
Move to NAD. We define what we expect from a moved-from object in Table 34 [movesconstructible].
Proposed resolution:
Section: 26.6.10[alg.adjacent.find]Status:NAD ConceptsSubmitter: Chris JeffersonOpened: 2009-03-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.adjacent.find].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 296
adjacent_find in C++03 allows an arbitrary predicate, but in C++0xEqualityComparable/EquivalenceRelation is required. This forbids anumber of use cases, including:
adjacent_find(begin, end, less<double>)Find the firstplace where a range is not ordered in decreasing order - in use to checkfor sorted ranges. adjacent_find(begin, end, DistanceBiggerThan(6) ) )Find the firstplace in a range where values differ by more than a given value - in useto check an algorithm which produces points in space does not generatepoints too far apart.
A number of books use predicate which are not equivalence relations inexamples, including "Thinking in C++" and "C++ Primer".
Adding the requirement that the predicate is anEquivalenceRelationdoes not appear to open up any possibility for a more optimised algorithm.
Proposed resolution:
Change the definition of adjacent_find in the synopsis of 26[algorithms]and 26.6.10[alg.adjacent.find] to:
template<ForwardIterator Iter> requiresEqualityComparableHasEqualTo<Iter::value_type, Iter::value_type> Iter adjacent_find(Iter first, Iter last);template<ForwardIterator Iter,EquivalenceRelationPredicate<auto, Iter::value_type, Iter::value_type> Pred> requires CopyConstructible<Pred> Iter adjacent_find(Iter first, Iter last, Pred pred);
Section: 16[library]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 78
This is effectively an extension of LWG issue343(i).
We know there is an increasing trend (encouraged by conformance testers andsome users) that each library header should supply no more than required tosatisfy the synopsis in the standard. This is typically achieved bybreaking larger headers into smaller subsets, and judicious use of forwarddeclarations.
If we apply this policy to C++0x (perN2800)it will be very surprising forpeople using library algorithms over ranges defined by pointers that theymust#include <iterator_concepts> for their code to compile again. That isbecause pointers do not satisfy any of the iterator concepts without theconcept_map supplied in this header.
Therefore, I suggest we should require all library headers that make use ofiterator concepts are specifically required to#include <iterator_concepts>.
At a minimum, the list of headers would be: (assuming all are constrained byconcepts)
algorithmarraydequeforward_listinitializer_listiteratorlocalelistmapmemory // if1029(i) is adoptedmemory_conceptsnumericrandomregexsetstringtupleunordered_mapunordered_setutilityvector
[Ganesh adds:]
The same problems exists for
<memory_concepts>and<container_concepts>.In order to compile
<vector>you just need thedefinitions of the concepts in<memory_concepts>, theconcept maps defined there are not necessary. Yet, from the user pointof view, if the concept map template forAllocatableElementarenot in scope,<vector>is pretty useless. Same for<tuple>andConstructibleWithAllocator.Similarly,
<queue>is not very useful if the concept maptemplate forQueueLikeContaineris not in scope, although thedefinition of concept alone is theoretically sufficient.There's a pattern here: if a concept has concept maps "attached", theyshould never be separated.
[Beman provided the proposed resolution for the May 2009 mailing. He comments:]
Initially I tried to specify exactly what header should include what other headers. This was verbose, error prone, hard to maintain, and appeared to add little value compared to just stating the general rule.
[Batavia (2009-05):]
Pete believes the proposed wording overconstrains implementers.Instead of specifying the mechanism,he prefers a solution that spells out what needs to be declared,rather than how those declarations are to be provided,e.g.,
A C++ header shall provide the namesthat are required to be defined in that header.
Bill suggests approaching the wording from a programmer's perspective.We may want to consider promising that certain widely-used headers(e.g., the concept headers) are included when needed by other headers.He feels, however, there is nothing broken now,although we may want to consider "something nicer."
Move to Open status.
[2009-06-16 Beman updated the proposed resolution:]
- The mechanism is no longer specified, as requested in Batavia.
- The footnote has been removed since it specified mechanism and also did not reflect existing practice.
- A sentence was added that makes it clear that the existing practice is permitted.
[2009-07-15 Beman updated the proposed resolution:]
[2009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt:]
- Strike two pieces of text considered unnecessary.
- Change "definitions" to "declarations and definitions" in two places.
- Wording tightened slightly.
[2009-07 Frankfurt:]
Revised Proposed Resolution:
A C++ header may include other C++ headers. A C++ header shall providethe declarations and definitions that appear in its synopsis (3.2[basic.def.odr]). A C++ header shown in its synopsis as including otherC++ headers shall provide the declarations and definitions that appearin the synopses of those other headers.
Alisdair: Does this address the BSI comment?
Beman: There were several overlapping comments. I tried to handle themall with one resolution.Alisdair: I'd prefer to see this closed as NAD and have this resolutionbe the subject of some other, new issue.Move to NAD Concepts. Howard to open a new issue (1178(i)) in Ready state with theProposed Resolution above. Beman will write up a discussion for the newissue.
Proposed resolution:
Change 16.4.6.2[res.on.headers], Headers, paragraph 1, as indicated:
A C++ header may include other C++headers.
[footnote]A C++ header shall providethe declarations and definitions that appear in its synopsis(6.3[basic.def.odr]). A C++ header shown in its synopsis as including other C++ headers shall provide the same declarations and definitions asif those other headers were included.
[footnote] C++ headers must include a C++ header that contains any needed definition (3.2).
Section: 16.4.2.3[headers]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [headers].
View all issues withNAD status.
Discussion:
Addresses UK-170 [CD1]
One of goals of C++0x is to make language easier to teach and for'incidental' programmers. The fine-grained headers of the C++ libraryare valuable in large scale systems for managing dependencies andoptimising build times, but overcomplicated for simple development andtutorials. Add additional headers to support the whole library through asingle include statement.
[Batavia (2009-05):]
We do not all agree that this is an issue,but we agree that if it needs solving this is the right way to do it.Move to Tentatively Ready.
[2009-07-06 Beman notes:]
This issueadds a header
<std>.There is a paper to be looked at,N2905Aggregation headers, that addsa header
<std-all>that is the same thing except it excludesdeprecated headers.N2905also proposes a second aggregation header.Seems like this issue should be held in abeyance until the LWG has hada chance to look atN2905.
[2009-07-06 Howard: I've pulled this issue back to Review.]
[2009-07 Frankfurt]
No consensus for change.
Proposed resolution:
Insert a new paragraph in 16.4.2.3[headers] between p4 and p5
An additional header
<std>shall have the effect ofsupplying the entire standard library. [Note: for example, itmight be implemented as a file with an#includestatement for each of theheaders listed in tables 13 and 14.-- end note]
Section: 16.4.2.5[compliance]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [compliance].
View all issues withNAD status.
Discussion:
Addresses JP 23 [CD1]
There is a freestanding implementation including<type_traits>,<array>,<ratio>, lately added to Table 13, C++ library headers.Programmers think them useful and hope that these headers are also addedto Table 15, C++ headers for freestanding implementations, that showsthe set of headers which a freestanding implementation shall include atleast.
Original proposed resolution
Add<type_traits>,<array>,<ratio> to Table 15.
[Summit:]
The
<array>header has far too many dependencies to require for afree-standing implementation.The
<ratio>header would be useful, has no dependencies, but is notstrictly necessary.The
<type_traits>header is fundamentally a core language facility with alibrary interface, so should be supported.(it is anticipated the resolution will come via an update to paperN2814)(see also LWG833(i))
[Batavia (2009-05):]
Leave in Review status pending a paper on freestanding implementationsby Martin Tasker.
[2009-07 Frankfurt:]
Move this to NAD.
We considered all of the listed headers, and found a compelling caseonly for the inclusion of
<type_traits>in the list of headers requiredof a freestanding implementation.See Martin Tasker's paperFixing Freestandingwhich provides the wording to include
<type_traits>into freestandingimplementations.
Proposed resolution:
Add<type_traits> to Table 15.
numeric_limits partial specializations not concept enabledSection: 17.3.5[numeric.limits]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [numeric.limits].
View all otherissues in [numeric.limits].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 26
numeric_limits [partial specializations] does not use concept.
[Summit:]
Alisdair will provide a solution as part of treatment of axioms and LWG902(i).
[Post Summit:]
Alisdair recommends NAD as the partial specializations are alreadyconstrained by requirements on the primary template.
[Batavia (2009-05):]
The Working Draft does not in general repeat a primary template's constraintsin any specializations.Move to NAD.
[2009-05-25 Howard adds:]
A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is thecorrect resolution of this issue. Indeed the discussion also casts doubt thatthe current proposed wording is the correct resolution as well. Personally I'minclined to reset the status to Open. However I'm reverting the status to that which it had prior to the Batavia recommendation. I'm setting back to Review.
Proposed resolution:
Change 17.3.5[numeric.limits]:
template<classRegular T> class numeric_limits<const T>;template<classRegular T> class numeric_limits<volatile T>;template<classRegular T> class numeric_limits<const volatile T>;
throw_with_nested not concept enabledSection: 17.9.8[except.nested]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [except.nested].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 29
throw_with_nested does not use concept.
[Summit:]
Agreed.
Proposed resolution:
Alisdair initially proposed wording inN2619.
We are awaiting an updated paper based on feedback from the San Franciscoreview.
nested_exception wording unclearSection: 17.9.8[except.nested]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [except.nested].
View all issues withNAD status.
Discussion:
Addresses JP 31
It is difficult to understand in which casenested_exception is applied.
[Summit:]
Alisdair will add an example in an update toN2619.
[2009-10 Santa Cruz:]
It doesn't appear that N2619 really addresses this. Alisdair to propose wording.
[2010 Pittsburgh:]
Mark issue 1008 as NAD, the type is adequately described.
Rationale:
nested_exception is intended to be inherited from by exception classesthat are to be thrown during the handling of another exception, i.e.when translating from one exception type to another. nested_exceptionallows the originally thrown exception to be easily retained in thatscenario.
Proposed resolution:
InputIterator post-increment dangerousSection: 24.3.5.2[iterator.iterators]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.iterators].
View all issues withNAD status.
Discussion:
Addresses UK 251
The post-increment operator is dangerous for a general InputIterator.The multi-pass guarantees that make it meaningful are defined as part ofthe ForwardIterator refinement. Any change will affect only constrainedtemplates that have not yet been written, so should not break existinguser iterators which remain free to add these operations. This changewill also affect the generalised OutputIterator, although there is nopercieved need for the post-increment operator in this case either.
[2009-07-28 Alisdair adds:]
We still think the issue is relevant, but needs totally rewording innon-concept language. We would like to see the issue retained as Open,rather than deferred as NAD Concepts. Review status is no longerappropriate.
[2009-10 Santa Cruz:]
NAD. Without concepts we do not feel that input iterator post incrementis broken.
Proposed resolution:
Change 24.3.5.2[iterator.iterators]:
concept Iterator<typename X> : Semiregular<X> { MoveConstructible reference = typename X::reference;MoveConstructible postincrement_result;requires HasDereference<postincrement_result>;reference operator*(X&&); X& operator++(X&);postincrement_result operator++(X&, int);}...
postincrement_result operator++(X& r, int);
-3-Effects: equivalent to{ X tmp = r; ++r; return tmp; }.
Change 24.3.5.3[input.iterators]:
concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> { ObjectType value_type = typename X::value_type; MoveConstructible pointer = typename X::pointer; SignedIntegralLike difference_type = typename X::difference_type; requires IntegralType<difference_type> && Convertible<reference, const value_type &>; && Convertible<pointer, const value_type*>;requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; pointer operator->(const X&); }Change 24.3.5.4[output.iterators]:
auto concept OutputIterator<typename X, typename Value> { requires Iterator<X>; typename reference = Iterator<X>::reference;typename postincrement_result = Iterator<X>::postincrement_result; requires SameType<reference, Iterator<X>::reference>&& SameType<postincrement_result, Iterator<X>::postincrement_result>&& Convertible<postincrement_result, const X&> && HasAssign<reference, Value>&& HasAssign<HasDereference<postincrement_result>::result_type, Value>;}Change 24.3.5.5[forward.iterators]:
[See1084(i) which is attempting to change this same area in a compatibleway.]
concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {requires Convertible<postincrement_result, const X&>;MoveConstructible postincrement_result;requires HasDereference<postincrement_result> && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;postincrement_result operator++(X&, int); axiom MultiPass(X a, X b) { if (a == b) *a == *b; if (a == b) ++a == ++b; } }-4- ...
postincrement_result operator++(X& r, int);-5-Effects: equivalent to
{ X tmp = r; ++r; return tmp; }.
operator-= should use default in conceptSection: 24.3.5.7[random.access.iterators]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [random.access.iterators].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 263
This requirement onoperator-= would be better expressed as a defaultimplementation in the concept, with a matching axiom.
[Batavia (2009-05):]
The proposed resolution should also removeparagraph 5 and the declaration that precedes it.Further, we should provide an axiomthat captures the desired semantics.This may be a broader policy to be applied.Move to Open.
Proposed resolution:
Change 24.3.5.7[random.access.iterators]:
concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> { ... X& operator-=(X&x, difference_typen) { return x += -n; } ...}IsSameType hold-over constraintsSection: 26.8.9[alg.min.max]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withNAD Editorial status.
Discussion:
Addresses UK 305
The negative requirement onIsSameType is a hold-over from an earlierdraught with a variadic template form ofmin/max algorith. It is nolonger necessary.
[Batavia (2009-05):]
We agree with the proposed resolution.Move to Tentatively Ready.
[2009-07 Frankfurt]
We believe this is NAD, but this needs to be reviewed against thepost-remove-concepts draft.
Proposed resolution:
Change 26[algorithms]:
template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>const T& min(const T& a, const T& b, Compare comp);...template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>const T& max(const T& a, const T& b, Compare comp);...template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
Change 26.8.9[alg.min.max], p1, p9 and p17:
template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>const T& min(const T& a, const T& b, Compare comp);...template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>const T& max(const T& a, const T& b, Compare comp);...template<class T, StrictWeakOrder<auto, T> Compare>requires !SameType<T, Compare> && CopyConstructible<Compare>pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
concept_mapsSection: 99 [concept.transform]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [concept.transform].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 199
The requirement that programs do not supplyconcept_maps shouldprobably be users do not supply their ownconcept_mapspecializations. The program will almost certainly supplyconcept_maps - the standard itself supplies a specializationforRvalueOf references. Note that the termprogram isdefined in 6.7[basic.link]p1 and makes no account of thestandard library being treated differently to user written code.
[2009-05-09 Alisdair adds:]
The same problem is present in the words added for the
LvalueReference/RvalueReferenceconcepts last meeting.With three subsections requiring the same constraint, I'm wondering if thereis a better way to organise this section.Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in [concept.support]? While they can be implemented purely as alibrary feature without additional compiler support, they are prettyfundamental and we want the same restriction on user-concept maps as ismandated there.
[Batavia (2009-05):]
We agree with the issue,but believe the wording needs further improvement.We want to investigate current definitions for nomenclature such as"user" and "program."Move to Open pending the recommended investigation.
Proposed resolution:
Change 99 [concept.transform] p2:
-2- A
programuser shall not provide concept maps forany concept in 20.1.1.
Change [concept.true] p2:
-2-Requires: a
programuser shall notprovide a concept map for theTrueconcept.
Change [concept.classify] p2:
-2-Requires: a
programuser shall not provide conceptmaps for any concept in this section.
LessThanComparable andEqualityComparable forFloatingPointTypeSection: 99 [concept.comparison]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [concept.comparison].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 33
LessThanComparable andEqualityComparable don't correspond to NaN.
Original proposed resolution:
Applyconcept_map to these concepts atFloatingPointType.
[Post Summit, Alisdair adds:]
I don't understand the proposed resolution - there is no such thing as a'negative' concept_map, and these concepts are auto concepts that matchfloat/double etc. Also not clear how we are supposed to match values toconcepts.
Proposed resolution:
Recommend NAD.
RegularSection: 99 [concept.regular]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
Addresses US 66
Application of theRegular concept to floating-point types appears to becontroversial (see long discussion on std-lib reflector).
Original proposed resolution:
State that theRegular concept does not apply to floating-point types.
[Summit:]
[Post Summit, Alisdair adds:]
Recommend Open, and review after resolution of902(i) and revised axiomfeature.
Proposed resolution:
Section: 21[meta]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta].
View all otherissues in [meta].
View all issues withNAD Concepts status.
Discussion:
Addresses US 70 [CD1]
Specifications now expressed via narrative text are more accurately andclearly expressed via executable code.
Wherever concepts are available that directly match this section's typetraits, express the traits in terms of the concepts instead of vianarrative text. Where the type traits do not quite match thecorresponding concepts, bring the two into alignment so as to avoid twonearly-identical notions.
[Summit:]
We think that this is a good idea, but it requires a lot of work. If someonesubmits a paper proposing specific changes, we would be happy to review itat the next meeting.
Proposed resolution:
aligned_unionSection: 21.3.9.7[meta.trans.other]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [meta.trans.other].
View all issues withNAD status.
Discussion:
Addresses UK 204 [CD1]
It is not possible to create a variant union based on a parameter packexpansion, e.g. to implement a classic discriminated union template.
Original proposed resolutuion:
Restorealigned_union template that was removed by LWG issue856(i).
[Summit:]
Agree. The need for
aligned_unionis compelling enough to reinstate.
[Post Summit, Alisdair adds:]
PaperN2843proposes an extension to the
[[align]]attributethat further diminishes the need for this template. Recommend NAD.
[2009-10 Santa Cruz:]
Mark NAD as suggested.
Proposed resolution:
Section: 99 [util.dynamic.safety]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [util.dynamic.safety].
View all issues withNAD Editorial status.
Discussion:
Addresses UK 212 [CD1]
The pointer-safety API is nothing to do with smart pointers, so does notbelong in [util.smartptr]. In fact it is a set of languagesupport features are really belongs in clause [language.support], with the contents declared in a header that deals with language-support of memory management.
[Summit:]
Agree in principle, but not with the proposed resolution. We believe itbelongs either a subsection of either 22[utilities] or 20.2[memory] as part of the general reorganization of 22[utilities]. The declaration should stay in
<memory>.
Proposed resolution:
std::functionSection: 22.10.17.3[func.wrap.func]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.wrap.func].
View all issues withNAD Editorial status.
Discussion:
Addresses DE 22 [CD1]
The conditions for deriving fromstd::unary_function andstd::binary_function are unclear: The condition would also be satisfied ifArgTypes werestd::vector<T1>, because it (arguably)"contains"T1.
[Summit:]
Agree.
std::reference_wrapperhas the same structure, and wesuggest thatstd::functionbe presented in the same way asstd::reference_wrapper.
[2009-05-09 Alisdair adds:]
Phrasing should be "publicly and unambiguously derived from" and probably back in
reference_wrappertoo. Updated wording supplied.
[Batavia (2009-05):]
We agree with the proposed wording.Move to NAD Editorial.
Proposed resolution:
(no changes to<functional> synopsis required)
Change synopsis in Class template function 22.10.17.3[func.wrap.func]:
template<Returnable R, CopyConstructible... ArgTypes> class function<R(ArgTypes...)> : public unary_function<T1, R> //iff sizeof...(ArgTypes) == 1andsee below// ArgTypescontains T1: public binary_function<T1, T2, R> //iff sizeof...(ArgTypes) == 2andsee below// ArgTypescontains T1and T2{ ...
Add new p1/p2 before 22.10.17.3.2[func.wrap.func.con]:
The template instantiation
function<R(T1)>shall be publicly andunambiguously derived fromstd::unary_function<T1,R>if and only if the template type parameteris a function type taking one argument of typeT1and returningR.The template instantiation
function<R(T1,T2)>shall be publicly andunambiguously derived fromstd::binary_function<T1,T2,R>if and only if the template typeparameter is a function type taking two arguments of typeT1andT2andreturningR.explicit function();
std::function constructors overly generousSection: 22.10.17.3[func.wrap.func]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.wrap.func].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 39 [CD1]
There are no requires corresponding toF ofstd::function.
[2009-05-01 Daniel adds:]
[Batavia (2009-05):]
We agree with the proposed resolution.Move to Tentatively Ready.If issue1070(i) is accepted,the changes to the second constructorin this issue are moot.
[2009-07 Frankfurt:]
Constructors have no definition.
Proposed resolution:
Correct as follows in 22.10.17.3[func.wrap.func] (class definition)
template<class F, Allocator Alloc>requires ConstructibleWithAllocator<F, Alloc> && call=Callable<F, ArgTypes...> && Convertible<call::result_type, R> function(allocator_arg_t, const Alloc&, F); template<class F, Allocator Alloc>requires ConstructibleWithAllocator<F,Alloc> && call=Callable<F, ArgTypes...> && Convertible<call::result_type, R> function(allocator_arg_t, const Alloc&, F&&);
std::hashSection: 22.10.19[unord.hash]Status:NAD FutureSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2020-08-21
Priority:Not Prioritized
View all otherissues in [unord.hash].
View all issues withNAD Future status.
Discussion:
Addresses UK 208 [CD1]
std::hash should be implemented for much more of the standardlibrary. In particular forpair,tuple and all thestandard containers.
[2020-05-28; LEWG issue reviewing]
At the Kona 2017 LEWG issue processing session, this issue was marked as NAD. The formatting of theLWGissuesInLEWGStatus page ran 1025 into other text. A search of the page yields:
1025 20.14.15 [unord.hash] The library should provide more specializations for std::hashNAD: We don't want to do this before solving LEWG21.
Status change to Open.
[2020-08-21 Issue processing telecon: follow LEWG recommendation. Status changed: Open → NAD Future.]
Proposed resolution:
Section: 20.2[memory]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [memory].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 209 [CD1]
Smart pointers cannot be used in constrained templates.
[Summit:]
We look forward to a paper on this topic. We recommend no action until apaper is available. We understand that a paper is forthcoming.
[Peter Dimov adds:]
shared_ptr<T>andweak_ptr<T>support alltypesTfor whichT*is valid. In other words, apossible (partial) resolution is to change classTtoPointeeType Tforshared_ptr,weak_ptrandpossiblyenable_shared_from_this.
Proposed resolution:
std::allocator needs to be a concept-constrained templateSection: 20.2.10[default.allocator]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [default.allocator].
View all otherissues in [default.allocator].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 213 [CD1]
std::allocator should be constrained to simplify its use on constrainedcontexts. This library component models allocation from free store via thenew operator so choose constraints to match. The Allocator concept allows for a wider variety of allocators thatusers may choose to supply if their allocation model does not requireoperator new, without impacting the requirements of this template.
Suggested direction:
The primary allocator template should be constrained to requireObjectType<T> andFreeStoreAllocatable<T>.Further operations to be constrained as required.
[Summit:]
Agree as stated. A future paper will address additional related issues.
Proposed resolution:
raw_storage_iterator needs to be a concept-constrained templateSection: 99 [depr.storage.iterator]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2017-06-15
Priority:Not Prioritized
View all otherissues in [depr.storage.iterator].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 214 [CD1]
raw_storage_iterator needs constraining as an iterator adaptor to be safelyused in constrained templates
[Summit:]
We look forward to a paper on this topic. We recommend no action until apaper is available.
[Post Summit Alisdair provided wording and rationale.]
Proposed resolution:
20.2[memory] p2
Update the synopsis for<memory>
// 20.7.8, raw storage iterator:template <classForwardIterator OutputIterator,classObjectType T>requires OutputIterator< OutIter, T > class raw_storage_iterator;template <ForwardIterator OutIter, ObjectType T> requires OutputIterator< OutIter, T > concept_map Iterator<raw_storage_iterator< OutIter, T > > { }
[storage.iterator] p1
Replace class template definition with:
namespace std { template <classForwardIterator OutputIterator,classObjectType T>requires OutputIterator< OutIter, T > class raw_storage_iterator : public iterator<output_iterator_tag,void,void,void,void> { public: explicit raw_storage_iterator(OutputIterator x); raw_storage_iterator<OutputIterator,T>& operator*(); raw_storage_iterator<OutputIterator,T>& operator=(const T& element); raw_storage_iterator<OutputIterator,T>& operator++(); raw_storage_iterator<OutputIterator,T> operator++(int); };template <ForwardIterator OutIter, ObjectType T> requires OutputIterator< OutIter, T > concept_map Iterator<raw_storage_iterator< OutIter, T > > { }}Rationale:
raw_storage_iterator has to adapt aForwardIterator,rather than just anInputIterator for two reasons:
Section: 26.11[specialized.algorithms]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [specialized.algorithms].
View all otherissues in [specialized.algorithms].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 210 [CD1]
Specialized algorithms for memory management need requirements to beeasily usable in constrained templates.
[Summit:]
We look forward to a paper on this topic. We recommend no action until apaper is available.
[Post Summit Alisdair provided wording.]
[Post Summit:]
Daniel adds:
- I suggest
Sizeshould requireIntegralLikeand notUnsignedIntegralLike,because otherwise simple int-literals could not be provided as argumentsand it would conflict with other algorithms that only requireIntegralLike.The current for-loop-test relies on evaluation in boolean context which isnot provided by
ArithmeticLikeand it's refinements. I propose to change thecorresponding for-loop-headers to:
- for
uninitialized_copy_n:for ( ; n > Size(0); ++result, ++first, --n) {- for
uninitialized_fill_n:for (; n > Size(0); ++first, --n) {Alisdair adds:
For the record I agree with Daniel's suggestion.
Proposed resolution:
20.2[memory] p2
Update the synopsis for<memory>
template <classInputIteratorInIter,class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter>requires ForwardIterator<OutIter>ForwardIteratorOutIter uninitialized_copy(InputIteratorInIter first,InputIteratorInIter last,ForwardIteratorOutIter result);template <classInputIteratorInIter,classIntegralLike Size,class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter>requires ForwardIterator<OutIter>ForwardIteratorOutIter uninitialized_copy_n(InputIteratorInIter first, Size n,ForwardIteratorOutIter result);template <classForwardIteratorIter,classObjectType T>requires Constructible< Iter::value_type, const T& > void uninitialized_fill(ForwardIteratorIter first,ForwardIteratorIter last, const T& x);template <classForwardIteratorIter,classIntegralLike Size,classObjectType T>requires Constructible< Iter::value_type, const T& > void uninitialized_fill_n(ForwardIteratorIter first, Size n, const T& x);
Update as follows:
uninitialized_copy 26.11.5[uninitialized.copy]
template <classInputIteratorInIter,class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter>requires ForwardIterator<OutIter>ForwardIteratorOutIter uninitialized_copy(InputIteratorInIter first,InputIteratorInIter last,ForwardIteratorOutIter result);-1-Effects:
for (; first != last; ++result, ++first) { new (static_cast<void*>(&*result))typename iterator_traits<ForwardIterator>OutIter::value_type(*first);}-2-Returns:
resulttemplate <classInputIteratorInIter,classIntegralLike Size,class ForwardIteratorOutputIterator<auto, InIter::reference> OutIter>requires ForwardIterator<OutIter>ForwardIteratorOutIter uninitialized_copy_n(InputIteratorInIter first, Size n,ForwardIteratorOutIter result);-3- Effects:
for ( ; n >Size(0); ++result, ++first, --n) { new (static_cast<void*>(&*result))typename iterator_traits<ForwardIterator>OutIter::value_type(*first);}-4-Returns: result
uninitialized_fill 26.11.7[uninitialized.fill]
template <classForwardIteratorIter,classObjectType T>requires Constructible< Iter::value_type, const T& > void uninitialized_fill(ForwardIteratorIter first,ForwardIteratorIter last, const T& x);-1-Effects:
for (; first != last; ++first) { new ( static_cast<void*>( &*first) )typename iterator_traits<ForwardIterator>Iter::value_type(x);}
uninitialized_fill_n [uninitialized.fill.n]
template <classForwardIteratorIter,classIntegralLike Size,classObjectType T>requires Constructible< Iter::value_type, const T& > void uninitialized_fill_n(ForwardIteratorIter first, Size n, const T& x);-1-Effects:
for (; n--> Size(0); ++first, --n) { new ( static_cast<void*>( &*first) )typename iterator_traits<ForwardIterator>Iter::value_type(x);}
shared_ptr conversion to aunique_ptrSection: 20.3.2.2[util.smartptr.shared]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2018-06-23
Priority:Not Prioritized
View all otherissues in [util.smartptr.shared].
View all issues withNAD status.
Discussion:
Addresses US 78 [CD1]
There is presently no way to convert directly from ashared_ptr to aunique_ptr. Add an interface that performs the conversion.
[Summit:]
We look forward to a paper on this topic. We recommend no action until apaper is available. We believe that the shared pointer must use the defaultdeleter for the conversion to succeed.
[Peter Dimov adds:]
This is basically a request for
shared_ptr<>::releaseindisguise, with all the associated problems. Not a good idea.
[2009-07 post-Frankfurt:]
The rationale for the omission of a release() member function from shared_ptr is given in:http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm
The implementation of such a member is non-trivial (and maybeimpossible), because it would need to account for the deleter.
[2009-07-26 Howard sets to Tentatively NAD Future.]
I took an online poll and got 3 votes for NAD and 3 for NAD Future. PersonallyI prefer NAD Future as this does refer to an extension that could conceivably beconsidered beyond C++0X.
However such an extension would need to solve a couple of problems:
- What is the interface for such a conversion when the
shared_ptrdoesnot have unique ownership? Throw an exception? Create a nullunique_ptr?Undefined behavior?How does one handle custom deleters given to the
shared_ptrconstructor?I do not believe it is possible to implement a general answer to this question.The
shared_ptrdeleter is a run time (or construction time) characteristic.Theunique_ptrdeleter is a compile time characteristic. In general onecan not know to what type ofunqiue_ptryou are converting to.One answer is for the user of the conversion to specify the deleter type and perhapsthrow an exception if the specification turns out to be incorrect.
Another answer is for the conversion to only be valid when the underlying deleteris
default_delete. We would probalby need to specify that this is indeed theunderlying deleter of ashared_ptrwhen a custom deleter is not given inthe constructor.At any rate, there are non-trivial design issues which would need to be implementedand tested in the field for usability prior to standardization.
[2009 Santa Cruz:]
Moved to NAD Future.
[2017-02 in Kona, LEWG recommends NAD]
We just removedstd::shared_ptr<>::unique() because it's misleading at best(especially in the face ofweak_ptr). Resolving this is far larger than issues-processing — it would require significant design discussion and potentially an ABI break (stashing a mutex in theshared_ptr control block).
[2017-06-02 Issues Telecon]
Resolve as NAD
Proposed resolution:
Section: 30[time]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 45 [CD1]
Rep,Period,Clock andDurationdon't correspond to concept.
template <class Rep, class Period = ratio<1>> class duration; template <class Clock, class Duration = typename Clock::duration> class time_point;
Make concept forRep,Period,Clock andDuration.Fix 30[time] andwait_untilandwait_for's template parameter at 32[thread].
[Summit:]
We agree that this section needs concepts. We look forward to a paper onthis topic. We recommend no action until a paper is available.
Proposed resolution:
<array>::swap can invalidate references, pointers, and iteratorsSection: 23.2.2[container.requirements.general]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [container.requirements.general].
View all otherissues in [container.requirements.general].
View all issues withNAD status.
Discussion:
Addresses UK 226 [CD1]
<array> must be added to this list. In particular itdoesn't satisfy: - noswap() function invalidates anyreferences, pointers, or iterators referring to the elements of thecontainers being swapped. and probably doesn't satisfy: - noswap() function throws an exception.
If<array> remains a container, this will have to alsoreferencearray, which will then have to say which of thesepoints it satisfies.
[Summit:]
Agree. The proposed resolution is incomplete. Further work required.
[2009-05-01 Daniel adds:]
[2009-07 post-Frankfurt:]
Howard is to draft a note that explains what happens to references.
[2009-10 Santa Cruz:]
Mark as NAD. No consensus for change.
[2009-08-01 Howard provided wording.]
Proposed resolution:
Add a paragraph to 23.3.3.4[array.special]:
template <Swappable T, size_t N> void swap(array<T,N>& x, array<T,N>& y);Effects:
swap_ranges(x.begin(), x.end(), y.begin());[Note:Outstanding iterators, references and pointers may be invalidated.—end note]
Section: 23.2.4[sequence.reqmts]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 231 [CD1]
p9-p11 are redundant now that Concepts define what it means to be anIterator and guide overload resolution accordingly.
[Summit:]
Agree with issue and change to 23.2.4[sequence.reqmts]. Thechanges required to 27[strings] will be part of the generalconcept support for that clause.
Proposed resolution:
Strike 23.2.4[sequence.reqmts]p9-11. Make surestd::basic_stringhas constraints similar tostd::vector to meet this old guarantee.
ContiguousStorage concept and apply it to corresponding containersSection: 23.3[sequences]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [sequences].
View all issues withNAD status.
Discussion:
Addresses UK 244 [CD1]
The validity of the expression&a[n] == &a[0] + n is contingent onoperator& doing the "right thing" (as captured by theCopyConstructiblerequirements in table 30 in C++2003). However this constraint has beenlost in the Concepts of C++0x. This applies tovector andarray (itactually applies tostring also, but that's a different chapter, so I'llfile a separate comment there and cross-reference).
Suggested solution:
Define aContiguousStorage and apply it tovector,array andstring.
[Summit:]
Agree with the issue but not the details of the proposed solution. Walter toprovide wording for the new concept.
[Post Summit Alisdair adds:]
Another LWG subgroup wondered if this concept should extend to
complex<T>, and so not be built on the container concept at all?
[2009-07 post-Frankfurt:]
Leave Open, pending a post-Concepts Working Draft.
[2009-10 Santa Cruz:]
Mark issue 1042 as NAD, in rationale state that this was solved by removal of concepts.
Proposed resolution:
Add to<container_concepts> synopsis in [container.concepts]
concept< typename C > ContiguousStorageContainersee below;
Add a new section to the end of [container.concepts]
23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
concept ContiguousStorageContainer< typename C > : Container<C>{ value_type* data(C&); axiom Contiguity(C& c, size_type i) { if( i < size(c) ) { addressof( * (data(c) + i) ) == addressof( * advance(data(c), i) ); } }}The
ContiguousStorageContainerconcept describes a container whose elementsare allocated in a single region of memory, and are stored sequentiallywithout intervening padding other than to meet alignment requirements.For example, the elements may be stored in asingle array of suitable length.value_type * data( C& );Returns: a pointer to the first element in the region of storage.Result is unspecified for an empty container.
Change 23.3.3[array] p1:
-1- The header
<array>defines a class template forstoring fixed-size sequences of objects. Anarraysupportsrandom access iterators. An instance ofarray<T, N>storesNelements of typeT, so thatsize() ==Nis an invariant. The elements of anarrayare storedcontiguously, meaning thatifanaisarray<T, N>then it obeys the identitysatisfies the concept&a[n]== &a[0] + nfor all0 <= n < NContiguousStorageContainer< array<T,N>>.
Add to the synopsis in 23.3.3[array]:
... T * data(); const T * data() const; };template< typename T, size_t N >concept_map ContiguousStorageContainer< array<T, N>> {};}Change 23.3.13[vector] p1:
A
vectoris a sequence container that supports random accessiterators. In addition, it supports (amortized) constant time insert anderase operations at the end; insert and erase in the middle take lineartime. Storage management is handled automatically, though hints can begiven to improve efficiency. The elements of a vector are storedcontiguously, meaning thatifavisvector<T, Alloc>(whereTis sometype other thanbool), then it obeys theidentitysatisfies the concept&v[n] == &v[0] + nfor all0 <= n <v.size()ContiguousStorageContainer<vector< T, Alloc>>.
Add at the end of the synopsis in 23.3.13[vector] p2:
template< typename T, typename A > requires !SameType< T, bool > concept_map ContiguousStorageContainer< vector<T, A>> {};Rationale:
Solved by removal of concepts.
reverse_iterator andmove_iteratorSection: 24.5.1.6[reverse.iter.elem], 24.5.4.6[move.iter.elem]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [reverse.iter.elem].
View all issues withNAD status.
Discussion:
Addresses UK 279 [CD1]
The reason the return type became unspecified is LWG issue386(i). Thisreasoning no longer applies as there are at least two ways to get the rightreturn type with the new language facilities added since the previousstandard.
Proposal: Specify the return type using either decltype or the Iter concept_map.
[Summit:]
Under discussion. This is a general question about all iteratoradapters.
[Howard adds post Summit:]
I am requesting test cases to demonstrate a position.
[2009-07-24 Daniel adds:]
I recommend NAD. Without concepts we can no longerrestrict this member in a trivial way. Using
decltypethedeclaration would be along the lines ofstatic const Iter& __base(); // not definedauto operator[](difference_type n) const -> decltype(__base()[-n-1]);but once
reverse_iteratoris instantiated for some given typeIterwhich cannot form a well-formed expression__base()[-n-1]this would cause an ill-formed function declaration, diagnosticrequired, and no silent SFINAE elimination.
[2009-10 Santa Cruz:]
Moved to NAD.
[2009-10-22 Daniel adds:]
IMO, my original comment regarding ill-formedness of the describedconstruction is still correct, but I must add that I should weaken myassertion "Without concepts we can no longer restrict this member ina trivial way".
In fact with the existence of default template arguments for functiontemplates it is not too hard to implement this like as follows, whichshows that we can indeed simulate to some sense constrainedmember functions in C++0x.
My example does not really proof that the specification is easy, butit should be possible. I assume that the implementation would notbe ABI compatible, though.
It is now your own decision how to proceed ;-)
#include <type_traits>#include <cstddef>template<class T>typename std::add_rvalue_reference<T>::type declval();template<class It>struct reverse_iterator { It base; typedef std::ptrdiff_t difference_type; template<class U = It, class Res = decltype(declval<const U&>()[declval<difference_type>()]) > Res operator[](difference_type n) const { return base[-n-1]; }};struct MyIter {};int main() { reverse_iterator<int*> ri; ri[0] = 2; reverse_iterator<MyIter> ri2;}The above declaration could be simplified, but the ideal solution
template<class U = It> decltype(declval<const U&>()[declval<difference_type>()]) operator[](difference_type n) const;does not work yet on gcc 4.4.1.
Proposed resolution:
Section: 26[algorithms]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2017-06-05
Priority:Not Prioritized
View otheractive issues in [algorithms].
View all otherissues in [algorithms].
View all issues withNAD status.
Discussion:
Addresses UK 295 [CD1]
There is a level of redundancy in the library specification for manyalgorithms that can be eliminated with the combination of concepts anddefault parameters for function templates. Eliminating redundancy simplifiedspecification and reduces the risk of introducing accidentalinconsistencies.
Proposed resolution: AdoptN2743.
[Summit:]
NAD, this change would break code that takes the address of an algorithm.
[Post Summit Alisdair adds:]
Request 'Open'. The issues in the paper go beyond just reducingthe number of signatures, but cover unifying the idea of the orderingoperation used by algorithms, containers and other library components. Atleast, it takes a first pass at the problem.
For me (personally) that was the more important part of the paper, and notclearly addressed by the Summit resolution.
[2009-10 Santa Cruz:]
Too inventive, too late, would really need a paper. Moved to NAD Future.
[2017-02 in Kona, LEWG recommends NAD (NAD-ABI)]
Concept specific, might be solved by Ranges. Get it right in STD2 or with the next big ABI break.
[2017-06-02 Issues Telecon]
Resolve as NAD
Proposed resolution:
Section: 29.5[rand]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand].
View all issues withNAD status.
Discussion:
Both the conceptsRandomNumberEngine andRandomNumberDistribution haverequirements to beInputStreamable andOutputStreamable.
I have no problems leaving the WP in an inconsistent state on the best-faithassumption these concepts will be provided later, however disagree with theproposers that these constraints are not separable, orthogonal to the basicconcepts of generating random number distributions.
These constraints should be dropped, and applied to specific algorithms asneeded.
If a more refined concept (certainly deemed useful by the proposers) isproposed there is no objection, but the basic concept should not requirepersistence via streaming.
[Batavia (2009-05):]
Move to Open.
[2009-05-31 Alisdair adds:]
Working on constraining the stream iterators, I have a few more observationsto make on the concepts proposed while constraining the random numberfacility.
While I still believe the concerns are orthogonal, I don't believe theexisting constraints go far enough either! The goal we want to achieve isnot that a
RandomNumberEngine/RandomNumberDistributionsupports the streamoperators, but that it isSerializable. I.e. there is a relationshipbetween the insert and extract operations that guarantees to restore thestate of the original object. This implies a coupling of the conceptstogether in a broader concept (Serializable) with at least one axiom toassert the semantics.One problem is that
istreamandostreammay be fundamentally differenttypes, although we can hook a relation if we are prepared to drop down tothechartype andchar_traitstemplate parameters. Doing so ties us to aform of serialization that demands implementation via the std iostreamsframework, which seems overly prescriptive. I believe the goal is generallyto support serialization without regard to how it is expressed - althoughthis is getting even more inventive in terms of concepts we do not havetoday.
[2009-11-03 Alisdair adds:]
I can't find the record in the wiki minutes, but it was agreed at bothFrankfurt and Santa Cruz that this issue is NAD.
The agreement in SC was that I would provide you with the rationale (seebelow) to include when moving to NAD.
[2009-11-03 Howard adds:]
Moved to Tentatively NAD after 5 positive votes on c++std-lib.
Proposed resolution:
Rationale:
The issue suggests a more refined concept should be used if we want torequire streaming, to separate concerns from the basicRandomNumberEngine behaviour. In Frankfurt it was observedthatRandomNumberEngineis that more refined concept,and the basic concept used in the framework isUniformRandomNumberGenerator, which it refines.
We concur, and expect this to have no repurcussions re-writing thisclause now concepts are removed.
RandomNumberEngineAdaptorSection: 29.5[rand]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand].
View all issues withNAD Concepts status.
Discussion:
TheRandomNumberEngineAdaptor concept breaks precedent in theway the library has been specified by grouping requirements into aconcept that is never actually used in the library.
This is undoubtedly a very helpful device for documentation, but we are notcomfortable with the precedent - especially as we have rejected nationalbody comments on the same grounds.
Suggest either removing the concept, or providing an algorithm/type thatrequires this concept in their definition (such as a factory function tocreate new engines).
The preference is to create a single new algorithm and retain the value ofthe existing documentation.
[Batavia (2009-05):]
Walter points out that it is unlikely that any algorithm would everrequire this concept, but that the concept nonetheless is useful asdocumentation, and (via concept maps) as a means of checking specific adapters.
Alisdair disagrees as to the concept's value as documentation.
Marc points out that the
RandomNumberDistributionis also a concept not used elsewhere in the Standard.Pete agrees that a policy of not inventing conceptsthat aren't used in the Standard is a good starting point,but should not be used as a criterion for rejecting a concept.
Move to Open.
Proposed resolution:
Section: 23.2.4[sequence.reqmts]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD Editorial status.
Discussion:
Sequence containers 23.2.4[sequence.reqmts]:
The return value of new calls added to table 83 are not specified.
[Batavia (2009-05):]
We agree with the proposed resolution.
Move to NAD Editorial.
Proposed resolution:
Add after p6 23.2.4[sequence.reqmts]:
-6- ...
The iterator returned from
a.insert(p,rv)points to the copy ofrvinserted intoa.The iterator returned from
a.emplace(p, args)points to the newelement constructed fromargsinserted intoa.
Section: 22.10.17.3[func.wrap.func]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2009-03-13Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.wrap.func].
View all issues withNAD Concepts status.
Discussion:
Due to a deliberate core language decision, the earlier called"foundation" conceptstd::FunctionType had been removed inN2773shortlybefore the first "conceptualized" version of the WP(N2798)had beenprepared. This caused a break of the library, which already used thisconcept in the adapted definition ofstd::function(22.10[function.objects]/2, header<functional> synopsis and22.10.17.3[func.wrap.func]).
A simple fix would be to either (a) makestd::function's primary templateunconstrained or to (b) add constraints based on existing (support) concepts.A more advanced fix would (c) introduce a new library concept.
The big disadvantage of (a) is, that users can define templates whichcause compiler errors during instantiation time because of under-constrainednessand would thus violate the basic advantage of constrainedcode.
For (b), the ideal constraints forstd::function's template parameter wouldbe one which excludes everything else but the single provided partialspecialization that matches every "free function" type (i.e. any functiontype w/o cv-qualifier-seq and w/o ref-qualifier).Expressing such a type as as single requirement would be written as
template<typename T>requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq // or ref-qual (depending on core issue #749) && PointeeType<T> // Eliminate reference types && !ObjectType<T> // Eliminate object types
Just for completeness approach (c), which would make sense, if thelibrary has more reasons to constrain for free function types:
auto concept FreeFunctionType<typename T> : ReferentType<T>, PointeeType<T>, MemberPointeeType<T>{ requires !ObjectType<T>;}I mention that approach because I expect that free function types belongto the most natural type categories for every days coders. Potentialcandidates in the library areaddressof and class templatepackaged_task.
[Batavia (2009-05):]
Alisdair would prefer to have a core-supported
FunctionTypeconceptin order that any future changes be automatically correctwithout need for a library solution to catch up;he points to type traits as a precedent.Further, he believes that a published concept can't in the futurebe changed.Bill feels this category of entity would change sufficiently slowlythat he would be willing to take the risk.
Of the discussed solutions, we tend toward option (c).We like the idea of having a complete taxonomy of native types,and perhaps erred in trimming the set.
We would like to have this issue reviewed by Core and would liketheir feedback. Move to Open.
Proposed resolution:
Change in 22.10[function.objects]/2, Header<functional> synopsis:
// 20.6.16 polymorphic function wrappers:class bad_function_call;template<FunctionTypeReferentType F>requires PointeeType<F> && !ObjectType<F>class function; // undefined
Change in 22.10.17.3[func.wrap.func]:
namespace std {template<FunctionTypeReferentType F>requires PointeeType<F> && !ObjectType<F>class function; // undefinedSection: 16.3.3.3.4.2[byte.strings]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-13Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Definition of null-terminated sequences allow for embedded nulls. This issurprising, and probably not supportable with the intended use cases.
[Batavia (2009-05):]
We agree with the issue, but believe this can be handled editorially.Move to NAD Editorial.
Proposed resolution:
Section: 22.3.4[pair.astuple]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-03-13Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [pair.astuple].
View all issues withNAD Editorial status.
Discussion:
The definition ofget implies thatget must return the second element ifgiven a negative integer.
[Batavia (2009-05):]
Move to NAD Editorial.
Proposed resolution:
22.3.4[pair.astuple] p5:
template<intsize_t I, class T1, class T2> requires True<(I < 2)> const P& get(const pair<T1, T2>&);
Section: 24.5.2[insert.iterators]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-13Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [insert.iterators].
View all issues withNAD status.
Discussion:
It is odd that we have an iterator to insert into avector, but not aniterator to insert into avector that is adapted as astack. The standardcontainer adapters all have a common interface topush andpop so it shouldbe simple to create an iterator adapter to complete the library support.
We should provide anAdaptedContainer concept supportingpush andpopoperations. Create a new insert iterator and factory function that insertsvalues into the container by callingpush.
[Batavia (2009-05):]
Walter recommends NAD Future.
Move to Open, and recommend deferring the issue until after the nextCommittee Draft is issued.
[2009-07-29 Howard moves to Tentatively NAD Future.]
A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
[2009 Santa Cruz:]
Moved to NAD. The intent of these adapters are to restrict the interfaces.
Proposed resolution:
Section: 99 [iterator.backward]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-15Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
Which header must a user#include to obtain the library-suppliedconcept_maps declared in this paragraph?
This is important information, as existing user code will break if thisheader is not included, and we should make a point of mandating this headeris#include-d by library headers likely to make use of it, notably<algorithm>. See issue1001(i) for more details.
[Batavia (2009-05):]
We agree with the direction of the proposed resolution.Move to Tentatively Ready.
[2009-07 Frankfurt]
We believe this is NAD Concepts, but this needs to be reviewed against thepost-remove-concepts draft.
Proposed resolution:
Change [depr.lib.iterator.primitives], Iterator primitives, asindicated:
To simplify the use of iterators and provide backward compatibility with previous C++ Standard Libraries, the library provides several classes and functions.Unless otherwise specified, these classes and functions shall be defined in header
<iterator>.
Change 99 [iterator.backward], Iterator backward compatibility, asindicated:
The library provides concept maps that allow iterators specified with
iterator_traitsto interoperate with algorithms that require iterator concepts.These concept maps shall be defined in the same header that defines the iterator. [Example:
Section: 99 [defns.obj.state]Status:NADSubmitter: Howard HinnantOpened: 2009-03-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [defns.obj.state].
View all issues withNAD status.
Discussion:
Addresses UK 152 [CD1]
Object state is using a definition of object (instance of a class) fromoutside the standard, rather than the 'region of storage' definiton in6.8.2[intro.object]p1
[Summit:]
We think we're removing this; See 99 [func.referenceclosure.cons].
[2009-10 Santa Cruz:]
Mark as NAD. This will not affect user or implementer code
Proposed resolution:
Section: 26.10[numeric.ops]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numeric.ops].
View all issues withNAD Concepts status.
Discussion:
One of the motivating examples for introducing requirements-aliases was tosimplify the wording of theinner_product requirements. As the paperadopting the feature and constrained wording for the library went through inthe same meeting, it was not possible to make the change at the time. Thesimpler form should be adopted now though. Similarly, most the othernumerical algorithms can benefit from a minor cleanup.
Note that in each case, the second more generalised form of the algorithmdoes not benefit, as there are already named constraints supplied by thetemplate type parameters.
[2009-05-02 Daniel adds:]
one part of the suggested resolution suggests the removal of the
MoveConstructible<T>requirement frominner_product. According to 26.10.5[inner.product]Computes its result by initializing the accumulator
accwith theinitial valueinitthis step requires at least
MoveConstructible.Therefore I strongly suggest to take this removal back (Note alsothat the corresponding overload with a functor argument still hasthe same
MoveConstructible<T>requirement).
[Batavia (2009-05):]
We agree with the proposed resolution as amended by Daniel's suggestionto restore
MoveConstructible,reflected in the updated proposed resolution below.Move to Tentatively Ready.
Proposed resolution:
Change in 26.10[numeric.ops] and 26.10.3[accumulate]:
template <InputIterator Iter, MoveConstructible T> requiresadd = HasPlus<T, Iter::reference> && HasAssign<T,HasPlus<T, Iter::reference>add::result_type> T accumulate(Iter first, Iter last, T init);
Change in 26.10[numeric.ops] and 26.10.5[inner.product]:
template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T> requiresmult = HasMultiply<Iter1::reference, Iter2::reference> &&add = HasPlus<T,HasMultiply<Iter1::reference, Iter2::reference>mult::result_type> && HasAssign< T,HasPlus<T, HasMultiply<Iter1::reference, Iter2::reference>::result_type>add::result_type> T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
Change in 26.10[numeric.ops] and 26.10.7[partial.sum]:
template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> requiresadd = HasPlus<InIter::value_type, InIter::reference> && HasAssign<InIter::value_type,HasPlus<InIter::value_type, InIter::reference>add::result_type> && Constructible<InIter::value_type, InIter::reference> OutIter partial_sum(InIter first, InIter last, OutIter result);
Change in 26.10[numeric.ops] and 26.10.12[adjacent.difference]:
template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> requiressub = HasMinus<InIter::value_type, InIter::value_type> && Constructible<InIter::value_type, InIter::reference> && OutputIterator<OutIter,HasMinus<InIter::value_type, InIter::value_type>sub::result_type> && MoveAssignable<InIter::value_type> OutIter adjacent_difference(InIter first, InIter last, OutIter result);
random_device should be movableSection: 29.5.7[rand.device]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.device].
View all issues withNAD status.
Discussion:
classrandom_device should be movable.
[Batavia (2009-05):]
Move to Open, and recommend this issue be deferred until after the nextCommittee Draft is issued.
[2009-10 post-Santa Cruz:]
Leave open. Walter to provide drafting as part of his planned paper.
[2010 Pittsburgh: Moved to NAD.]
Rationale:
WP is correct as written.
Proposed resolution:
seed_seq should support efficient move operationsSection: 29.5.8.1[rand.util.seedseq]Status:NADSubmitter: Alisdair MeredithOpened: 2009-03-18Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.util.seedseq].
View all issues withNAD status.
Discussion:
classseed_seq should support efficient move operations.
[Batavia (2009-05):]
Move to Open, and recommend this issue be deferred until after the nextCommittee Draft is issued.
[2009-10 post-Santa Cruz:]
Leave open. Walter to provide drafting as part of his planned paper.
[2010 Pittsburgh:]
seed_seqis explicitly not copyable, so, much like LWG issue1068(i), LWG issue 1069 could be marked NAD to be consistentwith this.
Proposed resolution:
std::hash a constrained template or not?Section: 22.10.19[unord.hash]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-19Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [unord.hash].
View all issues withNAD Concepts status.
Discussion:
Isstd::hash a constrained template or not?
According to class templatehash 22.10.19[unord.hash], the definition is:
template <class T>struct hash : public std::unary_function<T, std::size_t> { std::size_t operator()(T val) const;};And so unconstrained.
According to the<functional> synopsis in p2 Function objects22.10[function.objects] the template is declared as:
template <ReferentType T> struct hash;
which would make hash a constrained template.
[2009-03-22 Daniel provided wording.]
[Batavia (2009-05):]
Alisdair is not certain that Daniel's proposed resolution is sufficient,and recommends we leave the hash template unconstrained for now.
Recommend that the Project Editor make the constrained declaration consistentwith the definition in order to make the Working Paper internally consistent,and that the issue then be revisited.
Move to Open.
Proposed resolution:
[To the editor: This resolution is merge-compatible to theresolution of1078(i)]
In 22.10[function.objects]/2, header<functional> synopsis, change as indicated:
// 20.6.17, hash function base template:template <ReferentType T> struct hash;// undefined
In 22.10.19[unord.hash]/1 change as indicated:
namespace std {template <class T> struct hash : public std::unary_function<T, std::size_t> { std::size_t operator()(T val) const; };template <ReferentType T> struct hash; // undefined}In 22.10.19[unord.hash]/2 change as indicated:
-2-For all library-provided specializations, the templateinstantiation
hash<T>shall provide a publicoperator()with return typestd::size_ttosatisfy the concept requirementCallable<const hash<T>, const T&>. IfTis an objecttype or reference to object,hash<T>shall be publicly derived fromstd::unary_function<T, std::size_t>. The return value ofoperator()is unspecified, except thatequal arguments shall yield the same result.operator()shall not throw exceptions.
In 17.7[support.rtti]/1, header<typeinfo> synopsis change as indicated:
namespace std { class type_info; class type_index; template <classReferentType T> struct hash;Section: 99 [allocator.element.concepts]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-19Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
p7 Allocator-related element concepts 99 [allocator.element.concepts]
The changes to theAllocatableElement concept mean thisconcept_mapspecialization no longer matches the original concept:
template <Allocator Alloc, class T, class ... Args> requires HasConstructor<T, Args...> concept_map AllocatableElement<Alloc, T, Args&&...> { void construct_element(Alloc& a, T* t, Args&&... args) { Alloc::rebind<T>(a).construct(t, forward(args)...); } }[2009-03-23 Pablo adds:]
Actually, this is incorrect,N2840says. "In section 99 [allocator.element.concepts] paragraph 8, modify the definition of the
AllocatableElementconcept and eliminate the related concept map:" butthen neglects to include the red-lined text of the concept map that wasto be eliminated. Pete also missed this, but I caught it he asked me toreview his edits. Pete's updated WP removes the concept map entirely,which was the original intent. The issue is, therefore, moot. Note, asper my presentation ofN2840in summit,construct()no longer has adefault implementation. This regrettable fact was deemed (by DavidAbrahams, Doug, and myself) to be preferable to the complexity ofproviding a default implementation that would not under-constrain a morerestrictive allocator (like the scoped allocators).
[2009-05-01 Daniel adds:]
it seems to me that #1074 should be resolved as a NAD, because thecurrent WP has already removed the previous AllocatableElement concept map.It introduced auto concept AllocatableElement instead, but as of99 [allocator.element.concepts]/7 this guy contains now
requires FreeStoreAllocatable<T>;void Alloc::construct(T*, Args&&...);
[Batavia (2009-05):]
The affected code is no longer part of the Working Draft.
Move to NAD.
Proposed resolution:
Change 99 [allocator.element.concepts]:
template <Allocator Alloc, class T, class ... Args> requires HasConstructor<T, Args...> concept_map AllocatableElement<Alloc, T, Args&&...> { void construct_element(Alloc& a, T* t, Args&&... args) { Alloc::rebind<T>(a).construct(t, forward(args)...); } }Section: 99 [depr.negators]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-03-20Last modified: 2017-06-15
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
The class templatesunary/binary_negate need constraining and move support.
Ideally these classes would be deprecated, allowingunary/binary_function toalso be deprecated. However, until a generic negate adaptor is introducedthat can negate anyCallable type, they must be supported so should beconstrained. Likewise, they should be movable, and support adopting amove-only predicate type.
In order to preserve ABI compatibility, new rvalue overloads are supplied inpreference to changing the existing pass-by-const-ref to pass-by-value.
Do not consider the issue of forwarding mutable lvalues at this point,although remain open to another issue on the topic.
[2009-05-01 Daniel adds:]
IMO the currently proposed resolution needs some updatesbecause it is ill-formed at several places:
In concept AdaptableUnaryFunction change
typename X::result_type;typename X::argument_type;to
Returnable result_type = typename X::result_type;typename argument_type = typename X::argument_type;[The replacement "Returnable result_type" instead of "typenameresult_type" is non-editorial, but maybe you prefer that as well]
In concept AdaptableBinaryFunction change
typename X::result_type;typename X::first_argument_type;typename X::second_argument_type;to
Returnable result_type = typename X::result_type;typename first_argument_type = typename X::first_argument_type;typename second_argument_type = typename X::second_argument_type;[The replacement "Returnable result_type" instead of "typenameresult_type" is non-editorial, but maybe you prefer that as well.]
In class unary/binary_function
- I suggest to change "ReturnType" to "Returnable" in both cases.
- I think you want to replace the remaining occurrences of "Predicate" by "P"(in both classes in copy/move from a predicate)
I think you need to change the proposed signatures of not1 and not2, becausethey would still remain unconstrained: To make them constrained at least asingle requirement needs to be added to enable requirement implication. Thiscould be done via a dummy ("requires True<true>") or just explicit as follows:
-3- Returns: unary_negate<P>(pred).
[Don't we want a move call for the second overload as in
unary_negate<P>(std::move(pred))in the Returns clause ?]
-5- Returns: binary_negate<P>(pred).
[Don't we want a move call for the second overload as in
binary_negate<P>(std::move(pred))in the Returns clause ?]
[Batavia (2009-05):]
There is concern that complicating the solutionto preserve the ABI seems unnecessary,since we're not in general preserving the ABI.
We would prefer a separate paper consolidating all Clause 20issues that are for the purpose of providing constrained versionsof the existing facilities.
Move to Open.
[2009-10 post-Santa Cruz:]
Leave open pending the potential move constructor paper. Note thatwe consider the "constraining" part NAD Concepts.
[2010-01-31 Alisdair removes the current proposed wording from the proposedwording section because it is based on concepts. That wording is proposed here:]
Add new concepts where appropriate::
auto concept AdaptableUnaryFunction< typename X > { typename X::result_type; typename X::argument_type;}auto concept AdaptableBinaryFunction< typename X > { typename X::result_type; typename X::first_argument_type; typename X::second_argument_type;}Revise as follows:
Base [base] (Only change is constrained Result)
-1- The following classes are provided to simplify the typedefs of theargument and result types:
namespace std { template <class Arg,classReturnType Result> struct unary_function { typedef Arg argument_type; typedef Result result_type; }; template <class Arg1, class Arg2,classReturnType Result> struct binary_function { typedef Arg1 first_argument_type; typedef Arg2 second_argument_type; typedef Result result_type; };}Negators [negators]:
-1- Negators
not1andnot2take a unary and a binary predicate,respectively, and return their complements (5.3.1).template <classAdaptableUnaryFunction Predicate>requires Predicate< P, P::argument_type > class unary_negate : public unary_function<typenamePredicate::argument_type,bool> { public:unary_negate(const unary_negate & ) = default;unary_negate(unary_negate && );requires CopyConstructible< P > explicit unary_negate(const Predicate& pred);requires MoveConstructible< P > explicit unary_negate(Predicate && pred); bool operator()(consttypenamePredicate::argument_type& x) const; };-2
operator()returns!pred(x).template <class Predicate> unary_negate<Predicate> not1(const Predicate& pred);template <class Predicate> unary_negate<Predicate> not1(Predicate&& pred);-3-Returns:
unary_negate<Predicate>(pred).template <classAdaptableBinaryFunction Predicate>requires Predicate< P, P::first_argument_type, P::second_argument_type > class binary_negate : public binary_function<typenamePredicate::first_argument_type,typenamePredicate::second_argument_type, bool> { public:biary_negate(const binary_negate & ) = default;binary_negate(binary_negate && );requires CopyConstructible< P > explicit binary_negate(const Predicate& pred);requires MoveConstructible< P > explicit binary_negate(const Predicate& pred); bool operator()(consttypenamePredicate::first_argument_type& x, consttypenamePredicate::second_argument_type& y) const; };-4-
operator()returns!pred(x,y).template <class Predicate> binary_negate<Predicate> not2(const Predicate& pred);template <class Predicate> binary_negate<Predicate> not2(Predicate&& pred);-5-Returns:
binary_negate<Predicate>(pred).
[2010 Rapperswil:]
Move to NAD Concepts. The move-semantic part has been addressed by a core language change, which implicitly generates appropriate move constructors and move-assignment operators.
Proposed resolution:
tuple declarationsSection: 22.4.4[tuple.tuple]Status:NAD EditorialSubmitter: Pete BeckerOpened: 2009-03-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [tuple.tuple].
View all issues withNAD Editorial status.
Discussion:
Class template tuple 22.4.4[tuple.tuple]:
template <class... UTypes> requires Constructible<Types, const UTypes&>...template <class... UTypes> requires Constructible<Types, RvalueOf<UTypes>::type>...
Somebody needs to look at this and say what it should be.
[2009-03-21 Daniel provided wording.]
[Batavia (2009-05):]
The resolution looks correct; move to NAD Editorial.
Proposed resolution:
In 22.4.4[tuple.tuple], classtuple, change as indicated:
template <class... UTypes> requires Constructible<Types, const UTypes&>...tuple(const pair<UTypes...>&);template <class... UTypes> requires Constructible<Types, RvalueOf<UTypes>::type>...tuple(pair<UTypes...>&&);
[NB.: The corresponding prototypes do already exist in 22.4.4.2[tuple.cnstr]/7+8]
Section: 17.7.7[type.index]Status:NAD ConceptsSubmitter: Doug GregorOpened: 2009-03-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [type.index].
View all issues withNAD Concepts status.
Discussion:
Addresses DE 17
DE-17:
The classtype_index should be removed; it provides no additionalfunctionality beyond providing appropriate concept maps.
[2009-03-31 Peter adds:]
It is not true, in principle, that
std::type_indexprovides no utilitycompared to barestd::type_info*.
std::type_indexcan avoid the lifetime issues withtype_infowhen theDLL that has produced thetype_infoobject is unloaded. A rawtype_info*does not, and cannot, provide any protection in this case.Atype_indexcan (if the implementor so chooses) because it can wrap asmart (counted or even cloning) pointer to thetype_infodata that isneeded forname()andbefore()to work.
Proposed resolution:
Modify the header <typeinfo> synopsis in 17.7[support.rtti]p1 as follows:
namespace std { class type_info;class type_index; template <class T> struct hash; template<> struct hash<type_indexconst type_info *> : public std::unary_function<type_indexconst type_info *, size_t> { size_t operator()(type_indexconst type_info *indext) const; };concept_map LessThanComparable<const type_info *>see below class bad_cast; class bad_typeid;}Add the following new subsection
18.7.1.1 Template specialization
hash<const type_info *>[type.info.hash]size_t operator()(const type_info *x) const;
- Returns:
x->hash_code()
Add the following new subsection
18.7.1.2
type_infoconcept map [type.info.concepts]concept_map LessThanComparable<const type_info *> {bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }}
- Note: provides a well-defined ordering among
type_info constpointers, which makes such pointers usable in associative containers (23.4).
Remove section 17.7.7[type.index]
Section: 99 [concept.arithmetic]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2009-03-21Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
Astonishingly, the current concept ArithmeticLike as specified in99 [concept.arithmetic] does not provide explicit conversiontobool although this is a common property of arithmetic types(7.3.15[conv.bool]). Recent proposals that introduced such types(integers of arbitrary precision,n2143,decimalsn2732indirectlyvia conversion tolong long) also took care of such a feature.
Adding such an explicit conversion associated function would alsopartly solve a currently invalid effects clause in library, which baseson this property, 24.3.5.7[random.access.iterators]/2:
{ difference_type m = n; if (m >= 0) while (m--) ++r; else while (m++) --r; return r; }Both while-loops take advantage of a contextual conversion tobool(Another problem is that the >= comparison uses the nolonger supported existing implicit conversion fromint toIntegralLike).
Original proposed resolution:
In 99 [concept.arithmetic], add to the list of less refinedconcepts one further concept:
concept ArithmeticLike<typename T> : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, HasPostdecrement<T>, HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, HasMultiplyAssign<T, const T&>, HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {In 24.3.5.7[random.access.iterators]/2 change the current effects clauseas indicated [The proposed insertion fixes the problem that the previousimplicit construction from integrals has been changed to an explicitconstructor]:
{ difference_type m = n; if (m >=difference_type(0)) while (m--) ++r; else while (m++) --r; return r; }[Batavia (2009-05):]
We agree that arithmetic types ought be convertible to
bool,and we therefore agree with the proposed resolution's paragraph 1.We do not agree that the cited effects clause is invalid,as it expresses intent rather than specific code.
Move to Review, pending input from concepts experts.
Proposed resolution:
In 99 [concept.arithmetic], add to the list of less refinedconcepts one further concept:
concept ArithmeticLike<typename T> : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, HasPostdecrement<T>, HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, HasMultiplyAssign<T, const T&>, HasDivideAssign<T, const T&>, ExplicitlyConvertible<T, bool> {basic_string needs to be a concept-constrained templateSection: 27[strings]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [strings].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 216, JP 46, JP 48 [CD1]
All the containers use concepts for their iterator usage, exect forbasic_string. This needs fixing.
Use concepts for iterator template parameters throughout the chapter.
[Summit:]
NB comments to be handled by Dave Abrahams and Howard Hinnant withadvice from PJP: UK216 (which duplicates) JP46, JP48. JP46 suppliesextensive proposed wording; start there.
Proposed resolution:
codecvt needs to be a concept-constrained templateSection: 28.3[localization]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [localization].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 49 [CD1]
codecvt does not use concept. For example, createCodeConvertconcept and change as follows.
template<CodeConvert Codecvt, class Elem = wchar_t> class wstring_convert {[Summit:]
To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
Proposed resolution:
InputIterator andOutputIterator template parameters need to be concept constraintsSection: 28.3[localization]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [localization].
View all issues withNAD Concepts status.
Discussion:
Addresses JP 52, JP 53 [CD1]
InputIterator does not use concept.
OutputIterator does not use concept.
Comments include proposed wording.
[Summit:]
To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
Proposed resolution:
ForwardIterator should provide default implementation for post-incrementSection: 24.3.5.5[forward.iterators]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [forward.iterators].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 250 [CD1]
A default implementation should be supplied for the post-incrementoperator to simplify implementation of iterators by users.
Copy the Effects clause into the concept description as the defaultimplementation. Assumes a default value forpostincrement_result.
[Summit:]
Howard will open an issue.
[2009-06-07 Daniel adds:]
This issue cannot currently be resolved as suggested, becausethat would render auto-detection of the return type
postincrement_resultinvalid, see [concept.map.assoc]/4+5. Thebest fix would be to add a default type to that associated type, butunfortunately any default type will prevent auto-deduction of types ofassociated functions as quoted above. A corresponding core issueis in preparation.
Proposed resolution:
[This wording assumes the acceptance of UK 251 /1009(i). Bothwordings change the same paragraphs.]
Change 24.3.5.5[forward.iterators]:
concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { MoveConstructible postincrement_result; requires HasDereference<postincrement_result> && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; postincrement_result operator++(X& r, int);{ X tmp = r; ++r; return tmp; } axiom MultiPass(X a, X b) { if (a == b) *a == *b; if (a == b) ++a == ++b; } }BidirectionalIterator concept should provide default implementation for post-decrementSection: 24.3.5.6[bidirectional.iterators]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [bidirectional.iterators].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 258 [CD1]
A default implementation should be supplied for the post-decrementoperator to simplify implementation of iterators by users.
Copy the Effects clause into the concept description as the defaultimplementation. Assumes a default value forpostincrement_result.
[Summit:]
Howard will open an issue.
[2009-06-07 Daniel adds:]
This issue cannot currently be resolved as suggested, becausethat would render auto-detection of the return type
postdecrement_resultinvalid, see1084(i).
Proposed resolution:
Change 24.3.5.6[bidirectional.iterators]:
concept BidirectionalIterator<typename X> : ForwardIterator<X> { MoveConstructible postdecrement_result; requires HasDereference<postdecrement_result> && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&> && Convertible<postdecrement_result, const X&>; X& operator--(X&); postdecrement_result operator--(X&r, int);{ X tmp = r; --r; return tmp; }}Section: 24.6[stream.iterators]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [stream.iterators].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 284 [CD1]
The stream iterators need constraining with concepts/requrires clauses.
[Summit:]
We agree. To be handled by Howard, Martin and PJ.
Proposed resolution:
OutputIterator concept requirements forreplace algorithmsSection: 26.7.5[alg.replace]Status:NAD ConceptsSubmitter: Howard HinnantOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.replace].
View all issues withNAD Concepts status.
Discussion:
Addresses UK 301 [CD1]
replace andreplace_if have the requirement:OutputIterator<Iter,Iter::reference> Which implies they need to copy some values in therange the algorithm is iterating over. This is not however the case, theonly thing that happens isconst T&s might be copied over existingelements (hence theOutputIterator<Iter, const T&>.
RemoveOutputIterator<Iter, Iter::reference> fromreplaceandreplace_if.
[Summit:]
We agree. To be handled by Howard.
Proposed resolution:
Change in [algorithms.syn] and 26.7.5[alg.replace]:
template<ForwardIterator Iter, class T> requiresOutputIterator<Iter, Iter::reference> &&OutputIterator<Iter, const T&> && HasEqualTo<Iter::value_type, T> void replace(Iter first, Iter last, const T& old_value, const T& new_value); template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> requiresOutputIterator<Iter, Iter::reference> &&OutputIterator<Iter, const T&> && CopyConstructible<Pred> void replace_if(Iter first, Iter last, Pred pred, const T& new_value);
Section: 23.4.4.3[multimap.modifiers]Status:NADSubmitter: LWGOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses UK 246
The content of this sub-clause is purely trying to describe in words theeffect of the requires clauses on these operations, now that we haveConcepts. As such, the description is more confusing than the signatureitself. The semantic for these functions is adequately covered in therequirements tables in 23.2.7[associative.reqmts].
[Beman adds:]
Pete is clearly right thatthis one is technical rather than editorial.
[Batavia (2009-05):]
We agree with the proposed resolution.
Move to Review.
[2009-10 Santa Cruz:]
Mark as NAD, solved by removing concepts.
Proposed resolution:
Strike 23.4.4.3[multimap.modifiers] entirely(but do NOT strike these signatures from the class template definition!).
integral_constant should be a constrained templateSection: 21.3.4[meta.help]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2009-03-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [meta.help].
View all issues withNAD Concepts status.
Discussion:
A first step to change the type traits predicates to constrained templates is toconstrain their common base templateintegral_constant. This can be done,without enforcing depending classes to be constrained as well, but notvice versawithout brute forcelate_check usages. The following proposed resolution dependson the resolution of LWG issue1019(i).
[Batavia (2009-05):]
Move to Open, pending a paper that looks at constraintsfor the entirety of the type traitsand their relationship to the foundation concepts.We recommend this be deferreduntil after the next Committee Draft is issued.
Proposed resolution:
In 21.3.3[meta.type.synop], Header<type_traits>synopsis change as indicated:
namespace std {// 20.5.3, helper class:template <classIntegralConstantExpressionType T, T v> struct integral_constant;In 21.3.4[meta.help] change as indicated:
template <classIntegralConstantExpressionType T, T v>struct integral_constant { static constexpr T value = v; typedef T value_type; typedef integral_constant<T,v> type; constexpr operator value_type() { return value; }};
Section: 16[library]Status:NAD ConceptsSubmitter: David AbrahamsOpened: 2009-03-21Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD Concepts status.
Discussion:
TODO: Look at all cases of unconstrained rvalue ref parameters and checkthat concept req'ts work whenT deduced as reference.
We found some instances where that was not done correctly and we figure the possibility of deducingT to be an lvalue reference was probably overlooked elsewhere.
[Batavia (2009-05):]
Move to Open, pending proposed wording from Dave for further review.
Proposed resolution:
Section: 16[library]Status:NADSubmitter: David AbrahamsOpened: 2009-03-21Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Notes
[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tupleon 550
CD-1 reads:
template <MoveConstructible T1, MoveConstructible T2> pair<V1, V2> make_pair(T1&&, T2&&);Actually I'm guessing we need something like
MoveConstructible<V1,T1>,i.e. "V1can be constructed from an rvalue of typeT1."Ditto for
make_tuple[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way totalk about "copiable from generalized rvalue ref argument" for caseswhere we're going to forward and copy.
This issue may well be quite large. Language in para 4 about "if an lvalue" is wrong because types aren't expressions.
Maybe we should define the term "move" so we can just say in theeffects, "
fis moved into the newly-created thread" or something, andagree (and ideally document) that saying "fis moved" impliesF x(move(f))is required to work. That would cover both ctors at once.
p1199, call_once has all the same issues.
[2009-03-21 Sat] p869 InputIterator pointer type should not be requiredto be convertible to const value_type*, rather it needs to have aoperator-> of its own that can be used for the value type.
This one is serious and unrelated to the move issue.
[2009-03-21 Sat] p818 stack has the same problem with default ctor.
[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
requires MoveConstructible<Cont> explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont());Don't require MoveConstructible when default constructing Cont. Also missing semantics for move ctor.
[2009-03-21 Sat] Why are Allocators required to be CopyConstructible as opposed to MoveConstructible?
[2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't be MoveConstructible). No documented semantics for move c'tor. Or *any* of its 7 ctors!
[2009-03-21 Sat] std::array should have constructors for C++0x, consequently must consider move construction.
[2009-05-01 Daniel adds:]
This could be done as part of1035(i), which already handlesdeviation of
std::arrayfrom container tables.[2009-03-21 Sat] p622 all messed up.
para 8 "implementation-defined" is the wrong term; should be "see below" or something.
para 12 "will be selected" doesn't make any sense because we're not talking about actual arg types. paras 9-13 need to be totally rewritten for concepts.[2009-03-21 Sat] Null pointer comparisons (p587) have all become unconstrained. Need to fix that
[2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration. We think CopyConstructible is the right reqt. make_pair needs Constructible<V1, T1&&> requirements! make_tuple needs something similar tuple bug in synopsis:template <class... UTypes> requires Constructible<Types, const UTypes&>... template <class... UTypes> requires Constructible<Types, RvalueOf<UTypes>::type>...Note: removal of MoveConstructible requirements in std::function makes these routines unconstrained!
[2009-05-02 Daniel adds:]
these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
unique_ptr(pointer p, implementation-defined d); unique_ptr(pointer p, implementation-defined d);multimap range constructor should not have MoveConstructible<value_type> requirement.
same with
insert(..., P&&);multisethas the same issue, as dounordered_multisetandunordered_multimap. Review these!
[Batavia (2009-05):]
Move to Open, pending proposed wording from Dave for further review.
[2009-10 post-Santa Cruz:]
Tentatively NAD. We are not sure what has been addressed and what hasn't.Recommend closing unless someone sorts this out into something more readable.
Rationale:
The issue(s) at hand not adequately communicated.
Proposed resolution:
unique requirementsSection: 26.7.9[alg.unique]Status:NAD EditorialSubmitter: Howard HinnantOpened: 2009-04-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.unique].
View all issues withNAD Editorial status.
Discussion:
From Message c++std-core-14160 Howard wrote:
It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:N1860.
And Pete replied:
That was overridden by the subsequent changes made for concepts inN2573,which reimposed the C++03 requirements.
My impression is that this overwrite was a simple (unintentional) mistake.Wording below to correct it.
[Batavia (2009-05):]
Howard notes this issue resolves a discrepancy between the synopsisand the description.
Move to NAD Editorial.
Proposed resolution:
Change 26.7.9[alg.unique]:
template<ForwardIterator Iter> requires OutputIterator<Iter,RvalueOf<Iter::reference>::type> && EqualityComparable<Iter::value_type> Iter unique(Iter first, Iter last); template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> && CopyConstructible<Pred> Iter unique(Iter first, Iter last, Pred pred);
Note that the synopsis in [algorithms.syn] is already correct.
Range be anauto conceptSection: 99 [iterator.concepts.range]Status:NAD ConceptsSubmitter: David AbrahamsOpened: 2009-04-23Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
[2009-04-26 Herb adds:]
Here's a common example: We have many ISV customers who have built lots ofin-house STL-like containers. Imagine that, for the past ten years, the userhas been happily using his
XYZCorpContainer<T>that hasbegin()andend()and an iterator typedef, and indeed satisfies nearly all ofContainer,though maybe not quite all just likevalarray. The user upgrades to arange-enabled version of a library, and nowlib_algo( xyz.begin(), xyz.end());no longer works -- compiler error.Even though
XYZCorpContainermatches the pre-conceptized version of thealgorithm, and has been working for years, it appears the user has to writeat least this:template<class T> concept_map Range<XYZCorpContainer<T>> {};template<class T> concept_map Range<const XYZCorpContainer<T>> {};Is that correct?
But he may actually have to write this as we do for initializer list:
template<class T>concept_map Range<XYZCorpContainer<T>> { typedef T* iterator; iterator begin(XYZCorpContainer<T> c) { return c.begin(); } iterator end(XYZCorpContainer<T> c) { return c.end(); }};template<class T>concept_map Range<const XYZCorpContainer<T>> { typedef T* iterator; iterator begin(XYZCorpContainer<T> c) { return c.begin(); } iterator end(XYZCorpContainer<T> c) { return c.end(); }};
[2009-04-28 Alisdair adds:]
I recommend NAD, although remain concerned about header organisation.
A user container will satisfy the
MemberContainerconcept, which IS auto.There is a concept_map for allMemberContainerstoContainer, and then afurther concept_map for allContainertoRange, so the stated problem is notactually true. User defined containers will automatically match theRangeconcept without explicitly declaring a concept_map.The problem is that they should now provide an additional two headers,
<iterator_concepts>and<container_concepts>. The only difference frommakingRangean auto concept would be this reduces to a single header,<iterator_concepts>.I am strongly in favour of any resolution that tackles the issue ofexplicitly requiring concept headers to make these concept maps available.
[Batavia (2009-05):]
We observe there is a recent paper by Bjarne that overlaps this issue.
Alisdair continues to recommend NAD.
Move to Open, and recommend the issue be deferred until after the nextCommittee Draft is issued.
Proposed resolution:
shared_future(unique_future) by value?Section: 32.10.8[futures.shared.future]Status:NAD EditorialSubmitter: Thomas J. GritzanOpened: 2009-04-03Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [futures.shared.future].
View all issues withNAD Editorial status.
Discussion:
In theshared_future class definition in [futures.shared_future]the move constructorthat constructs ashared_future from anunique_future receives theparameter by value. In paragraph 3, the same constructor receives it asconst value.
I think that is a mistake and the constructor should take a r-valuereference:
shared_future(unique_future<R>&& rhs);
[Batavia (2009-05):]
We agree with the proposed resolution.
Move to Tentatively Ready.
[2009-07-05 Daniel notes:]
The proposed change has already been incorported into the current working draftN2914.
Proposed resolution:
Change the synopsis in [futures.shared_future]:
shared_future(unique_future<R>&& rhs);
Change the definition of the constructor in [futures.shared_future]:
shared_future(constunique_future<R>&& rhs);
std::includes should requireCopyConstructible predicateSection: 26.8.7.2[includes]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-04-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [includes].
View all issues withNAD Concepts status.
Discussion:
All the set operation algorithms require aCopyConstructible predicate, withthe exception ofstd::includes. This looks like a typo as much as anything,given the general library requirement that predicates are copyconstructible, and wording style of other set-like operations.
[Batavia (2009-05):]
We agree with the proposed resolution.Move to NAD Editorial.
Proposed resolution:
Change [algorithms.syn] and 26.8.7.2[includes]:
template<InputIterator Iter1, InputIterator Iter2,typenameCopyConstructible Compare> requires Predicate<Compare, Iter1::value_type, Iter2::value_type> && Predicate<Compare, Iter2::value_type, Iter1::value_type> bool includes(Iter1 first1, Iter1 last1, Iter2 first2, Iter2 last2, Compare comp);
Section: 23.4[associative]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-04-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [associative].
View all issues withNAD Concepts status.
Discussion:
According to table 87 (n2857) the expressionX::key_equal for an unorderedcontainer shall return a value of typePred, wherePred is an equivalencerelation.
However, all 4 containers constrainPred to be merely aPredicate,and notEquivalenceRelation.
[Batavia (2009-05):]
We agree with the proposed resolution.
Move to Review.
Proposed resolution:
For ordered containers, replace
Predicate<auto, Key, Key> Compare = less<Key>
with
StrictWeakOrder<auto, Key, Key> Compare = less<Key>
For unordered containers, replace
Predicate<auto, Key, Key> Compare = less<Key>
with
EquivalenceRelation<auto, Key, Key> Compare = less<Key>
As in the following declarations:
Associative containers 23.4[associative]
1 Headers
<map>and<set>:Header
<map>synopsisnamespace std { template <ValueType Key, ValueType T,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class map; ... template <ValueType Key, ValueType T,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class multimap; ... }Header <set> synopsis
namespace std { template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<Key> > requires NothrowDestructible<Key> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class set; ... template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<Key> > requires NothrowDestructible<Key> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class multiset; ... }23.4.1p2 Class template map [map]
namespace std { template <ValueType Key, ValueType T,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class map { ... }; }23.4.2p2 Class template multimap [multimap]
namespace std { template <ValueType Key, ValueType T,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class multimap { ... }; }23.4.3p2 Class template set [set]
namespace std { template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<Key> > requires NothrowDestructible<Key> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class set { ... }; }23.4.4p2 Class template multiset [multiset]
namespace std { template <ValueType Key,PredicateStrictWeakOrder<auto, Key, Key> Compare = less<Key>, Allocator Alloc = allocator<Key> > requires NothrowDestructible<Key> && CopyConstructible<Compare> && AllocatableElement<Alloc, Compare, const Compare&> && AllocatableElement<Alloc, Compare, Compare&&> class multiset { ... }; }23.5 Unordered associative containers [unord]
1 Headers <unordered_map> and <unordered_set>:
Header <unordered_map> synopsis
namespace std { // 23.5.1, class template unordered_map: template <ValueType Key, ValueType T, Callable<auto, const Key&> Hash = hash<Key>,PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_map; // 23.5.2, class template unordered_multimap: template <ValueType Key, ValueType T, Callable<auto, const Key&> Hash = hash<Key>,PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_multimap; ... }Header <unordered_set> synopsis
namespace std { // 23.5.3, class template unordered_set: template <ValueType Value, Callable<auto, const Value&> Hash = hash<Value>,PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, Allocator Alloc = allocator<Value> > requires NothrowDestructible<Value> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_set; // 23.5.4, class template unordered_multiset: template <ValueType Value, Callable<auto, const Value&> Hash = hash<Value>,PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, Allocator Alloc = allocator<Value> > requires NothrowDestructible<Value> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_multiset; ... }23.5.1p3 Class template unordered_map [unord.map]
namespace std { template <ValueType Key, ValueType T, Callable<auto, const Key&> Hash = hash<Key>,PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_map { ... }; }23.5.2p3 Class template unordered_multimap [unord.multimap]
namespace std { template <ValueType Key, ValueType T, Callable<auto, const Key&> Hash = hash<Key>,PredicateEquivalenceRelation<auto, Key, Key> Pred = equal_to<Key>, Allocator Alloc = allocator<pair<const Key, T> > > requires NothrowDestructible<Key> && NothrowDestructible<T> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_multimap { ... }; }23.5.3p3 Class template unordered_set [unord.set]
namespace std { template <ValueType Value, Callable<auto, const Value&> Hash = hash<Value>,PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, Allocator Alloc = allocator<Value> > requires NothrowDestructible<Value> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_set { ... }; }23.5.4p3 Class template unordered_multiset [unord.multiset]
namespace std { template <ValueType Value, Callable<auto, const Value&> Hash = hash<Value>,PredicateEquivalenceRelation<auto, Value, Value> class Pred = equal_to<Value>, Allocator Alloc = allocator<Value> > requires NothrowDestructible<Value> && SameType<Hash::result_type, size_t> && CopyConstructible<Hash> && CopyConstructible<Pred> && AllocatableElement<Alloc, Pred, const Pred&> && AllocatableElement<Alloc, Pred, Pred&&> && AllocatableElement<Alloc, Hash, const Hash&> && AllocatableElement<Alloc, Hash, Hash&&> class unordered_multiset { ... }; }
Section: 22.9.2[template.bitset]Status:NADSubmitter: Alisdair MeredithOpened: 2009-05-06Last modified: 2018-06-23
Priority:Not Prioritized
View all otherissues in [template.bitset].
View all issues withNAD status.
Discussion:
std::bitset is a homogeneous container-like sequence of bits, yet it doesnot model the Range concept so cannot be used with the new for-loop syntax.It is the only such type in the library that does NOT support the new forloop.
The obvious reason is that bitset does not support iterators.
At least two reasonable solutions are available:
bitset, bringing its interface close to thatofstd::arrayRange<bitset>.The latter will still need some kind of iterator-like adapter forbitset,but gives implementers greater freedom on the details. E.g. begin/end returnsome type that simply invokesoperator[] on the object it wraps, andincrements its index onoperator++. A vendor can settle forInputIteratorsupport, rather than wrapping up a fullRandomAccessIterator.
I have a mild preference for option (ii) as I think it is less work tospecify at this stage of the process, although (i) is probably more usefulin the long run.
Hmm, my wording looks a little woolly, as it does not say what the elementtype of the range is. Do I get a range ofbool,bitset<N>::reference, orsomething else entirely?
I guess most users will assume the behaviour of reference, but expect towork withbool.Bool is OK for read-only traversal, but you really need totake a reference to abitset::reference if you want to write back.
[Batavia (2009-05):]
Move to Open.We further recommend this be deferred until after the next Committee Draft.
[2009-05-25 Alisdair adds:]
I just stumbled over the
Range concept_mapforvalarrayand this shouldprobably set the precedent on how to write the wording.[Howard: I've replaced the proposed wording with Alisdair's suggestion.]
[2009-07-24 Daniel modifies the proposed wording for non-concepts.]
[2009-10 post-Santa Cruz:]
Mark as Tentatively NAD Future due to the loss of concepts.
[2017-02 in Kona, LEWG recommends NAD]
There are better APIs for bits coming, and seems to be consensusin LEWG not to polish bitset any further.
[2017-06-02 Issues Telecon]
Resolve as NAD
Rationale:
All concepts-related text has been removed from the draft.
Proposed resolution:
Modify the section 22.9.2[template.bitset]<bitset> synopsis by addingthe following at the end of the synopsis:
// XX.X.X bitset range access [bitset.range]template<size_t N>unspecified-1 begin(bitset<N>&);template<size_t N>unspecified-2 begin(const bitset<N>&);template<size_t N>unspecified-1 end(bitset<N>&);template<size_t N>unspecified-2 end(const bitset<N>&);
Add a new section"bitset range access" [bitset.range]after the current section 22.9.4[bitset.operators] with the following series ofparagraphs:
1. In the
beginandendfunction templates that follow,unspecified-1is a type that meets the requirements of a mutable random accessiterator (24.3.5.7[random.access.iterators]) whosevalue_typeisboolandwhose reference type isbitset<N>::reference.unspecified-2 is a type that meets the requirements of a constantrandom access iterator (24.3.5.7[random.access.iterators]) whosevalue_typeisbooland whose reference type isbool.template<size_t N>unspecified-1 begin(bitset<N>&);template<size_t N>unspecified-2 begin(const bitset<N>&);2. Returns: an iterator referencing the first bit in the bitset.
template<size_t N>unspecified-1 end(bitset<N>&);template<size_t N>unspecified-2 end(const bitset<N>&);3. Returns: an iterator referencing one past the last bit in thebitset.
va_copy missing from Standard macros tableSection: C.8[diff.library]Status:NAD EditorialSubmitter: Miles ZhaoOpened: 2009-05-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [diff.library].
View all issues withNAD Editorial status.
Discussion:
In "Table 122 — Standard macros" of C.8[diff.library], which lists the 56 macrosinherited from C library,va_copy seems to be missing. But in"Table 21 — Header<cstdarg> synopsis" (17.14[support.runtime]), there is.
[2009-10 post-Santa Cruz:]
Mark as Tentatively NAD Editorial, if Pete disagrees, Howardwill move to Tentatively Ready
Proposed resolution:
Addva_copy to Table 122 -- Standard macros in C.8[diff.library].
Section: 22.4.7[tuple.helper]Status:NADSubmitter: Alisdair MeredithOpened: 2009-05-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [tuple.helper].
View all issues withNAD status.
Discussion:
Thetuple query APIstuple_size andtuple_element do not support references-to-tuples. This can beannoying when a template deduced a parameter type to be a reference,which must be explicitly stripped withremove_reference before callingthese APIs.
I am not proposing a resolution at this point, as there is acombinatorial explosion with lvalue/rvalue references andcv-qualification (see previous issue) that suggests some higherrefactoring is in order. This might be something to kick back over toCore/Evolution.
Note that we have the same problem in numeric_limits.
[2009-10 post-Santa Cruz:]
Move to Open. Alisdair to provide wording.
[2010 Rapperswil:]
Move to NAD. This is an extension after the FCD, without a clear motivation. May consider as NAD Future if motivating examples come forward.
Proposed resolution:
remove_allSection: 21[meta]Status:NADSubmitter: Alisdair MeredithOpened: 2009-05-23Last modified: 2020-09-06
Priority:Not Prioritized
View otheractive issues in [meta].
View all otherissues in [meta].
View all issues withNAD status.
Discussion:
Sometimes it is necessary to remove all qualifiers from a type beforepassing on to a further API. A good example would be calling thetuple query APIstuple_size ortuple_elementwith a deduced type inside a function template. If the deduced type iscv-qualified or a reference then the call will fail. The solution is tochain calls toremove_cv<remove_reference<T>::type>::type, andnote that the order matters.
Suggest it would be helpful to add a new type trait,remove_all, that removes all top-level qualifiers from a typei.e. cv-qualification and any references. Define the term in such a waythat if additional qualifiers are added to the language, thenremove_all is defined as stripping those as well.
[2009-10-14 Daniel adds:]
remove_allseems too generic, a possible alternative matchingthe current naming style could beremove_cv_referenceorremove_reference_cv. It should also be considered whether thistrait should also remove 'extents', or pointer 'decorations'. Especiallyif the latter situations are considered as well, it might be easier tochose the name not in terms of what itremoves (which might bea lot), but in terms of itcreates. In this case I could thinkof e.g.extract_value_type.
[2009-10 Santa Cruz:]
NAD Future.
[2017-02 in Kona, LEWG recommends NAD]
Send a paper to reopen: we'll need to bikeshed names if we decide topursue such a design. It'll need to discuss difference between thisand decay, and make choices about array types, and discuss why referencesare removed but not pointers.
[2017-06-02 Issues Telecon]
Resolve as NAD; note thatP0550 addresses this
Proposed resolution:
Section: 21.5.4[ratio.arithmetic]Status:NADSubmitter: Alisdair MeredithOpened: 2009-05-25Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [ratio.arithmetic].
View all issues withNAD status.
Discussion:
Both add and multiply could sensibly be called with more than two arguments.The variadic template facility makes such declarations simple, and is likelyto be frequently wrapped by end users if we do not supply the variantourselves.
We deliberately ignore divide at this point as it is not transitive.Likewise, subtract places special meaning on the first argument so I do notsuggest extending that immediately. Both could be supported with analogouswording to that for add/multiply below.
Note that the proposed resolution is potentially incompatible with thatproposed for921(i), although the addition of the typedef to ratio would beequally useful.
[2009-10-30 Alisdair adds:]
The consensus of the group when we reviewed this in Santa Cruz was that921(i) would proceed to Ready as planned, and themulti-paramater add/multiply templates should be renamed as
ratio_sumandratio_productto avoid the problemmixing template aliases with partial specializations.It was also suggested to close this issue as NAD Future as it does notcorrespond directly to any NB comment. NBs are free to submit aspecific comment (and re-open) in CD2 though.
Walter Brown also had concerns on better directing the order ofevaluation to avoid overflows if we do proceed for 0x rather than TR1,so wording may not be complete yet.
[Alisdair updates wording.]
[2009-10-30 Howard:]
Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.
[LEWG Kona 2017]
PR for
ratio_productis wrong, usesratio_addinstead ofratio_multiply.Recommend NAD: Doesn't meet the bar for standardization: hasn't been requested again in 7 years, easy to implement yourself.
Rationale:
Does not have sufficient support at this time. May wish to reconsider for a future standard.
Proposed resolution:
Add the following type traits to p3 21.5[ratio]
// ratio arithmetictemplate <class R1, class R2> struct ratio_add;template <class R1, class R2> struct ratio_subtract;template <class R1, class R2> struct ratio_multiply;template <class R1, class R2> struct ratio_divide;template <class R1, class ... RList> struct ratio_sum;template <class R1, class ... RList> struct ratio_product;
after 21.5.4[ratio.arithmetic] p1: add
template <class R1, class ... RList> struct ratio_sum; // declared, never definedtemplate <class R1> struct ratio_sum<R1> : R1 {};Requires:
R1is a specialization of class templateratiotemplate <class R1, class R2, class ... RList> struct ratio_sum<R1, R2, RList...> : ratio_add< R1, ratio_sum<R2, RList...>> {};Requires:
R1and each element in parmater packRListis a specialization of class templateratio
after 21.5.4[ratio.arithmetic] p3: add
template <class R1, class ... RList> struct ratio_product; // declared, never definedtemplate <class R1> struct ratio_product<R1> : R1 {};Requires:
R1is a specialization of class templateratiotemplate <class R1, class R2, class ... RList> struct ratio_sum<R1, R2, RList...> : ratio_add< R1, ratio_product<R2, RList...>> {};Requires:
R1and each element in parmater packRListis a specialization of class templateratio
Section: 99 [concept.transform]Status:NAD ConceptsSubmitter: Daniel KrüglerOpened: 2009-05-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [concept.transform].
View all issues withNAD Concepts status.
Discussion:
A recent news grouparticlepoints to several defects in thespecification of reference-related concepts.
One problem of the conceptRvalueOf as currently defined in99 [concept.transform]:
concept RvalueOf<typename T> { typename type = T&&; requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>;}template<typename T> concept_map RvalueOf<T&> { typedef T&& type;}is that ifT is an lvalue-reference, the requirementConvertible<T&&,type> isn't satisfied forlvalue-references, because after reference-collapsing in the conceptdefinition we haveConvertible<T&,type> in this case,which isn't satisfied in the concept map template and also is not theright constraint either. I think that the reporter is right thatSameType requirements should do the job and that we also shoulduse the newRvalueReference concept to specify a best matchingtype requirement.
Proposed resolution:
In 99 [concept.transform] before p. 4 change as indicated:
auto concept RvalueOf<typename T> {typenameRvalueReference type = T&&; requiresExplicitlyConvertible<T&, type> && Convertible<T&&, type>SameType<T&, type&>;}Section: 24.6.3.3[ostream.iterator.ops]Status:NADSubmitter: Alisdair MeredithOpened: 2009-05-28Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
ostream_iterator has not been updated to support moveable types, in asimilar manner to the insert iterators.Note that this is not a problem forostreambuf_iterator, as the types it isrestricted to dealing with do not support extra-efficient moving.
[2009-11-10 Howard adds:]
Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationaleadded below.
Proposed resolution:
Add secondoperator= overload to classtemplate ostream_iteratorin 24.6.3[ostream.iterator], para 2:
ostream_iterator<T,charT,traits>& operator=(const T& value);ostream_iterator<T,charT,traits>& operator=(T&& value);
Add a new paragraph: in 24.6.3.3[ostream.iterator.ops]:
ostream_iterator& operator=(T&& value);-2-Effects:
*out_stream << std::move(value);if(delim != 0) *out_stream << delim;return (*this);
Rationale:
Several objections to move forward with this issue were voiced in the threadstarting with c++std-lib-25438. Among them is that we know of no motivatinguse case to make streaming rvalues behave differently than streaming constlvalues.
Section: 24.3.2.3[iterator.traits]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-05-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.traits].
View all issues withNAD Concepts status.
Discussion:
The deprecated support foriterator_traits and legacy (unconstrained)iterators features the (exposition only) concept:
concept IsReference<typename T> { } // exposition onlytemplate<typename T> concept_map IsReference<T&> { }Now this looks exactly like theLvalueReference concept recently added toclause 20, so I wonder if we should use that instead?Then I consider the lack of rvalue-reference support, which means thatmove_iterator would always flag as merely supporting theinput_iterator_tagcategory. This suggests we retain the exposition concept, but add a secondconcept_map to support rvalue references.
I would suggest adding the extra concept_map is the right way forward, butstill wonder if the two exposition-only concepts in this clause might beworth promoting to clause 20. That question might better be answered with afuller investigation of type_trait/concept unification though.
Proposed resolution:
In Iterator traits 24.3.2.3[iterator.traits] para 4 add:
concept IsReference<typename T> { } // exposition onlytemplate<typename T> concept_map IsReference<T&> { }template<typename T> concept_map IsReference<T&&> { }iterator_traits<T*>Section: 24.2[iterator.synopsis]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-05-28Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [iterator.synopsis].
View all issues withNAD Concepts status.
Discussion:
The<iterator> header synopsis declares a partial specialization ofiterator_traits to support pointers, [iterator.syn]. The implicationis that specialization will be described in D10, yet it did not follow therest of the deprecated material into this clause.
However, this is not as bad as it first seems!There are partial specializations ofiterator_traits for types that satisfythe various Iterator concepts, and there are concept_maps for pointers toexplicitly support theRandomAccessIterator concept, so the requiredtemplate will be present - just not in the manner advertised.
I can see two obvious solutions:
iterator_traits<T*> partial specialization in D.10iterator_traits<T*> from 24.3 synopsisI recommend option (ii) in the wording below
Option (ii) could be extended to strike all the declarations of deprecatedmaterial from the synopsis, as it is effectively duplicating D.10 anyway.This is the approach taken for deprecated library components in the 98/03standards. This is probably a matter best left to the Editor though.
Proposed resolution:
In [iterator.syn] strike:
template<class T> struct iterator_traits<T*>;
Section: 17.9.8[except.nested]Status:NADSubmitter: Seiji HayashidaOpened: 2009-06-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [except.nested].
View all issues withNAD status.
Discussion:
Addresses JP 30
C++0xnested_exception cannot handle a structured exception well. Thefollowing codes show two types of tree structured exception handling.
The first one is based onnested_exception in C++0x,while the second one is based on my librarytrickerr.h (in Japanese).http://tricklib.com/cxx/dagger/trickerr.h
Assume that FunctionA() calls two sub functionsA_a() andA_b(), both mightthrow tree structured exceptions, andA_b() must be called even ifA_a()throws an exception.
List A (code of tree structured exception handling based on nested_exceptionin C++0x)
void A(){ try { std::vector<exception_ptr> exception_list; try { // A_a() does a similar processing as A(). A_a(); } catch(...) { exception_list.push_back(current_exception()); } // ***The processing A() has to do even when A_a() fails. *** try { // A_b() does a similar processing as A(). A_b(); } catch(...) { exception_list.push_back(current_exception()); } if (!exception_list.empty()) { throw exception_list; } } catch(...) { throw_with_nested(A_exception("someone error")); }}void print_tree_exception(exception_ptr e, const std::string & indent =""){ const char * indent_unit = " "; const char * mark = "- "; try { rethow_exception(e); } catch(const std::vector<exception_ptr> e) { for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i) { print_tree_exception(i, indent); } } catch(const std::nested_exception e) { print_tree_exception(evil_i(e), indent +indent_unit); } catch(const std::exception e) { std::cout << indent << mark << e.what() << std::endl; } catch(...) { std::cout << indent << mark << "unknown exception" << std::endl; }}int main(int, char * []){ try { A(); } catch() { print_tree_exception(current_exception()); } return EXIT_SUCCESS;}List B ( code of tree structured exception handling based ontrickerr.h. )"trickerr.h" (in Japanese), refer to:http://tricklib.com/cxx/dagger/trickerr.h.
void A(){ tricklib::error_listener_type error_listener; // A_a() is like A(). A_a() can throw tree structured exception. A_a(); // *** It must do process so that A_a() throws exception in A(). *** // A_b() is like A(). A_b() can throw tree structured exception. A_b(); if (error_listener.has_error()) // You can write this "if block" in destructor // of class derived from error_listener_type. { throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error())); }}void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = ""){ const char * indent_unit = " "; const char * mark = "- "; tricklib::error_type error = a_error; while(error) { std::cout << indent << mark << error->message << std::endl; if (error->children) { print_tree_error(error->children, indent +indent_unit); } error = error->next; }}int main(int, char * []){ tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread. try { A(); } catch(error_type error) { print_tree_error(error); } catch(...) { std::cout << "- unknown exception" << std::endl; } return EXIT_SUCCESS;}Prospect
We will focus on the method A() since the other methods, also main(), occuronly once respectively.
According to the above observation, we cannot help concluding that it is notso easy to use the nested_exception handling as a tree structured exceptionhandling mechanism in a practical sense.
This text is based on the web page below (in Japanese).http://d.hatena.ne.jp/wraith13/20081231/1230715424
[2009-10 Santa Cruz:]
Mark as NAD. The committee agrees that
nested_exceptionis not a goodmatch for this usage model. The committee did not see a way of improvingthis within the timeframe allowed.
Proposed resolution:
Section: 32[thread]Status:NAD ConceptsSubmitter: LWGOpened: 2009-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread].
View all issues withNAD Concepts status.
Discussion:
Addresses US 93, JP 79, UK 333, JP 81
The thread chapter is not concept enabled.
Proposed resolution:
Section: 29[numerics]Status:NAD ConceptsSubmitter: LWGOpened: 2009-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [numerics].
View all issues withNAD Concepts status.
Discussion:
Addresses US 84
The numerics chapter is not concept enabled.
The portion of this comment dealing with random numbers was resolved byN2836,which was accepted in Summit.
Proposed resolution:
Section: 31[input.output]Status:NAD ConceptsSubmitter: LWGOpened: 2009-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [input.output].
View all issues withNAD Concepts status.
Discussion:
Addresses US 85, JP 67, JP 68, JP 69, JP 72, UK 308
The input/output chapter is not concept enabled.
Proposed resolution:
Section: 28.6[re]Status:NAD ConceptsSubmitter: LWGOpened: 2009-06-15Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [re].
View all otherissues in [re].
View all issues withNAD Concepts status.
Discussion:
Addresses US 86, UK 309, UK 310
The regular expressions chapter is not concept enabled.
Proposed resolution:
setprecision()andsetw()Section: 31.7[iostream.format]Status:NADSubmitter: Marc SteinbachOpened: 2009-06-20Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iostream.format].
View all issues withNAD status.
Discussion:
The header<iomanip> synopsis in 31.7[iostream.format] specifies
T5 setprecision(int n);T6 setw(int n);
The argument types should be streamsize, as in classios_base(see 31.5.2[ios.base]):
streamsize precision() const;streamsize precision(streamsize prec);streamsize width() const;streamsize width(streamsize wide);
(Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
[2009-07-29 Daniel clarified wording.]
[2009 Santa Cruz:]
No concensus for this change. There was some interest in doing the oppositefix: Change the
streamsizein<ios>toint.But ultimately there was no concensus for that change either.
Proposed resolution:
In 31.7[iostream.format], header<iomanip> synopsis change as indicated:
T5 setprecision(intstreamsize n);T6 setw(intstreamsize n);
In 31.7.7[std.manip], just before p. 6 change as indicated:
unspecified setprecision(intstreamsize n);
In 31.7.7[std.manip], just before p. 7 change as indicated:
unspecified setw(intstreamsize n);
Section: 99 [rand.concept.urng]Status:NAD ConceptsSubmitter: Walter BrownOpened: 2009-06-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Concepts status.
Discussion:
In 99 [rand.concept.urng], we have the following:
concept UniformRandomNumberGenerator<typename G> : Callable<G> { ... axiom NonemptyRange(G& g) { G::min() < G::max(); } ...}Since the parameterG is in scope throughout the concept, there is noneed for the axiom to be further parameterized, and so the axiom can beslightly simplified as:
axiom NonemptyRange() { G::min() < G::max();}We can further reformulate so as to avoid any axiom machinery as:
requires True< G::min() < G::max() >;
This is not only a simpler statement of the same requirement, but alsoforces the requirement to be checked.
[Post-Rapperswil:]
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
Proposed resolution:
In 99 [rand.concept.urng], replace theNonemptyRange axiom by:
axiom NonemptyRange(G& g) { G::min() < G::max(); }requires True< G::min() < G::max() >;
Section: 16[library], 32[thread], D[depr]Status:NADSubmitter: LWGOpened: 2009-06-28Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Addresses DE 2
Description
Marking a constructor withexplicit has semantics even for a constructor with zero or several parameters: Such a constructor cannot be used with list-initialization in a copy-initialization context, see 12.2.2.8[over.match.list]. The standard library apparently has not been reviewed for marking non-single-parameter constructors asexplicit.
Suggestion
Consider marking zero-parameter and multi-parameter constructorsexplicit in classes that have at least one constructor markedexplicit and that do not have an initializer-list constructor.
Notes
Robert Klarer to address this one.
[2009 Santa Cruz:]
Move to "Open". Robert Klarer has promised to provide wording.
[2010 Pittsburgh: Moved to NAD, rationale added below.]
Rationale:
We are unaware of any cases where initializer lists cause problem in thiscontext, but if problems arise in the future the issue can be reopened.
Proposed resolution:
complex should accept integral typesSection: 29.4[complex.numbers]Status:NADSubmitter: LWGOpened: 2009-06-28Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [complex.numbers].
View all issues withNAD status.
Discussion:
Addresses FR 35
Description
Instantiations of the class templatecomplex<> have to be allowed for integral types, to reflect existing practice and ISO standards (LIA-III).
Suggestion
[2009-10-26 Proposed wording inN3002.]
[2010 Pittsburgh:]
Moved to NAD Future. Rationale added.
[LEWG Kona 2017]
Recommend SG6
[2017-03-03, Kona]
SG6 suggests this issue is a new feature, not a problem with the existingstandard, and should therefore be closed NAD. However, SG6 invites papers that bringthe proposal up to date with the current standard.
Rationale:
There is no consensus for making this change at this time.
Proposed resolution:
AdoptN3002.
Section: C.8[diff.library]Status:NAD EditorialSubmitter: LWGOpened: 2009-06-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [diff.library].
View all issues withNAD Editorial status.
Discussion:
Addresses FR 38
Description
What is ISO/IEC 1990:9899/DAM 1? My guess is that's a typo for ISO/IEC 9899/Amd.1:1995 which I'd have expected to be referenced here (the tables make reference to things which were introduced by Amd.1).
Suggestion
One need probably a reference to the document which introducechar16_t andchar32_t in C (ISO/IEC TR 19769:2004?).
Notes
Create issue. Document in question should be C99, not C90+amendment1. The rest of the section requires careful review for completeness. Example <cstdint> 17.4.1[cstdint.syn]. Assign to C liasons.
[2009-10 Santa Cruz:]
NAD Editorial. Already fixed.
Proposed resolution:
Section: 16.3.3.3.2[enumerated.types], 16.3.3.3.3[bitmask.types]Status:NADSubmitter: LWGOpened: 2009-06-28Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses UK 165
Description
Constraints on bitmask and enumeration types were supposed to be tightened up as part of the motivation for theconstexpr feature - see paperN2235 for details
Suggestion
Adopt wording in line with the motivation described inN2235
Notes
Robert Klarer to review
[2009 Santa Cruz:]
Move to Open. Ping Robert Klarer to provide wording, using N2235 as guidance.
[2010 Pittsburgh:]
Moved to NAD. Rationale added.
Rationale:
UK NB did not sufficiently describe how to resolve their comment, andtherefore we cannot make a change for the FCD. If a resolution wereprovided in the future, we would be happy to apply it.
Proposed resolution:
promise::swap should pass by rvalue referenceSection: 32.10.6[futures.promise]Status:NADSubmitter: LWGOpened: 2009-06-28Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.promise].
View all issues withNAD status.
Discussion:
Addresses UK 341
Description
promise::swap accepts its parameter by lvalue reference. This isinconsistent with other types that provide a swap member function,where those swap functions accept an rvalue reference
Suggestion
Changepromise::swap to take an rvalue reference.
Notes
Create an issue. Detlef will look into it. Probably ready as it.
[2009-07 Frankfurt]
NAD, by virtue of the changed rvalue rules and swap signatures from Summit.
Proposed resolution:
pair<T,U> doesn't modelLessThanComparable in unconstrained code even ifT andU do.Section: 22.3[pairs]Status:NAD ConceptsSubmitter: Dave AbrahamsOpened: 2009-07-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [pairs].
View all issues withNAD Concepts status.
Discussion:
LessThanComparable requires (and provides default implementations for) <=,>, and >=. However, the defaults don't take effect in unconstrained code.
Still, it's a problem to have types acting one way inconstrained code and another in unconstrained code, except in cases ofsyntax adaptation. It's also inconsistent with the containers, whichsupply all those operators.
Totally UnbiasedSuggested Resolution:
accept the exported concept maps proposal and change the way this stuff is handled to use an explicit exported concept map rather than nested function templates
e.g., remove from the body ofstd::list
template <LessThanComparable T, class Allocator> bool operator< (const list<T,Allocator>& x, const list<T,Allocator>& y); template <LessThanComparable T, class Allocator> bool operator> (const list<T,Allocator>& x, const list<T,Allocator>& y); template <LessThanComparable T, class Allocator> bool operator>=(const list<T,Allocator>& x, const list<T,Allocator>& y); template <LessThanComparable T, class Allocator> bool operator<=(const list<T,Allocator>& x, const list<T,Allocator>& y);
and add this concept_map afterwards:
template <LessThanComparable T, class Allocator> export concept_map LessThanComparable<list<T,Allocator> >{ bool operator<(const list<T,Allocator>& x, const list<T,Allocator>& y);}do similarly forstd::pair. While you're at it, do the same foroperator== and!= everywhere, and seek out other such opportunities.
Alternative Resolution: keep the ugly, complex specification and add the missing operators tostd::pair.
Proposed resolution:
Section: 22.9.2.3[bitset.members]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2009-07-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [bitset.members].
View all issues withNAD Editorial status.
Discussion:
The following wording seems a little unusual to me:
p42/43 22.9.2.3[bitset.members]
bool operator==(const bitset<N>& rhs) const;-42-Returns: A nonzero value if the value of each bit in
*thisequals the value of the corresponding bit inrhs.bool operator!=(const bitset<N>& rhs) const;-43-Returns: A nonzero value if
!(*this == rhs).
"A nonzero value" may be well defined as equivalent to the literal 'true'for Booleans, but the wording is clumsy. I suggest replacing "A nonzero value"with the literal 'true' (in appropriate font) in each case.
[2009-07-24 Alisdair recommends NAD Editorial.]
[2009-07-27 Pete adds:]
It's obviously editorial. There's no need for further discussion.
[2009-07-27 Howard sets to NAD Editorial.]
Proposed resolution:
Change 22.9.2.3[bitset.members] p42-43:
bool operator==(const bitset<N>& rhs) const;-42-Returns:
A nonzero valuetrueif the value of each bit in*thisequals the value of the corresponding bit inrhs.bool operator!=(const bitset<N>& rhs) const;-43-Returns:
A nonzero valuetrueif!(*this == rhs).
Section: 16[library]Status:NADSubmitter: David AbrahamsOpened: 2009-07-14Last modified: 2016-11-21
Priority:3
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Issue: TheCopyConstructible requirements are wishy-washy. It requiresthat the copy is "equivalent" to the original, but "equivalent" is neverdefined.
I believe this to be an example of a more general lack of rigor aroundcopy and assignment, although I haven't done the research to dig up allthe instances.
It's a problem because if you don't know whatCopyConstructible means,you also don't know what it means to copy a pair ofCopyConstructibletypes. It doesn't prevent us from writing code, but it is a hole in ourability to understand the meaning of copy.
Furthermore, I'm pretty sure that vector's copy constructor doesn'trequire the elements to beEqualityComparable, so that table is actuallyreferring to some ill-defined notion of equivalence when it uses ==.
[2009 Santa Cruz:]
Move to "Open". Dave is right that this is a big issue. Paper D2987("Defining Move Special Member Functions", Bjarne Stroustrup andLawrence Crowl) touches on this but does not solve it. This issue isdiscussed in Elements of Programming.
[2010 Rapperswil:]
This issue is quite vague, so it is difficult to know if and when it has been resolved.John Lakos wrote a paper covering this area a while back, and there is a real interest in providing some sort of clean-up in the future. We need a more clearly draughted issues with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard. Move to Tentatively NAD Future.
[Moved to NAD Future at 2010-11 Batavia]
[2016-11-12, Issaquah]
Sat PM: Status: NAD
It was said in 2010: "We need a more clearly draughted issue with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard."
Proposed resolution:
thread constructor non-variadicSection: 32.4.3.3[thread.thread.constr]Status:NADSubmitter: Howard HinnantOpened: 2009-07-18Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [thread.thread.constr].
View all otherissues in [thread.thread.constr].
View all issues withNAD status.
Discussion:
The variadicthread constructor is causing controversy, e.g.N2901.This issue has been created as a placeholder for this course of action.
template <class F, class ...Args> thread(F&& f, Args&&... args);
See929(i) for wording which specifies an rvalue-ref signature butwith "decay behavior", but using variadics.
[2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Proposed resolution:
Rationale:
The (tentative) concensus of the LWG is to keep the variadic thread constructor.
Section: 16.3.2.4[structure.specifications]Status:NAD EditorialSubmitter: Robert KlarerOpened: 2009-07-21Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [structure.specifications].
View all otherissues in [structure.specifications].
View all issues withNAD Editorial status.
Discussion:
While reviewing971(i) I noted that 16.3.2.4[structure.specifications]/7 says:
-7- Error conditions specify conditions where a function may fail. Theconditions are listed, together with a suitable explanation, as the
enumclass errcconstants (19.5) that could be used as an argument tofunctionmake_error_condition(19.5.3.6).
This paragraph should mentionmake_error_code or the text "thatcould be used as an argument to functionmake_error_condition(19.5.3.6)" should be deleted. I believe this is editorial.
[2009-07-21 Chris adds:]
I'm not convinced there's a problem there, because as far as the "Errorconditions" clauses are concerned, make_error_condition() is used by auser to test for the condition, whereas make_error_code is not. Forexample:
void foobar(error_code& ec = throws());Error conditions:
permission_denied - Insufficient privilege to perform operation.
When a user writes:
error_code ec;foobar(ec);if (ec == errc::permission_denied) ...the implicit conversion
errc->error_conditionmakes the if-testequivalent to:if (ec == make_error_condition(errc::permission_denied))On the other hand, if the user had written:
if (ec == make_error_code(errc::permission_denied))the test is now checking for a specific error code. The test mayevaluate to
falseeven thoughfoobar()failed due to the documentederror condition "Insufficient privilege".
[2009 Santa Cruz:]
NAD Editorial.
What the WP says right now is literally true: these codes can be used asan argument to
make_error_condition. (It is also true that they can beused as an argument tomake_error_code, which the WP doesn't say.) Maybeit would be clearer to just delete "that could be used as an argument tofunctionmake_error_condition", since that fact is already implied byother things that we say. We believe that this is editorial.
Proposed resolution:
Section: 23.3.13[vector]Status:NADSubmitter: Alisdair MeredithOpened: 2009-07-29Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [vector].
View all issues withNAD status.
Discussion:
Opened at Alisdair's request, steming from96(i).Alisdair recommends NAD Future.
[2009-10 Santa Cruz:]
NAD Future. We want a heap allocated bitset, but we don't have one today anddon't have time to add one.
[2017-02 in Kona, LEWG recommends NAD]
Solution in process: Presented at Olu (Vincent Reverdy)P0237r5 Value reference pointer and iterator. The reference should be put into the issue.
[2017-06-02 Issues Telecon]
This is a feature request, not a defect.
Resolve as NAD
Proposed resolution:
Section: 23.6.6[stack]Status:NAD ConceptsSubmitter: Alisdair MeredithOpened: 2009-07-31Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [stack].
View all issues withNAD Concepts status.
Discussion:
The library templateforward_list could easily model the idea of astack, where the operations work on the front of the list rather thanthe back. However, the standard librarystack adaptor cannot supportthis.
It would be relatively easy to write a partial specialization forstackto supportforward_list, but that opens the question of which header toplace it in. A much better solution would be to add aconcept_map fortheStackLikeContainer concept to the<forward_list> header and theneverything just works, including a user's own further uses in astack-like context.
Therefore while I am submitting the issue now so that it is on record, Istrongly recommend we resolve as "NAD Concepts" as any non-conceptsbased solution will be inferior to the final goal, and the feature isnot so compelling it must be supported ahead of the concepts-basedlibrary.
[2009-11-02 Howard adds:]
Moved to Tentatively NAD Concepts after 5 positive votes on c++std-lib.
Rationale:
Any non-concepts based solution will be inferior to the final goal, and thefeature is not so compelling it must be supported ahead of the concepts-basedlibrary.
Proposed resolution:
Section: 23.2.8[unord.req], 23.5[unord]Status:NADSubmitter: Matt AusternOpened: 2009-08-10Last modified: 2019-02-26
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
Unordered associative containers have a notion of a maximum load factor:when the number of elements grows large enough, the containersautomatically perform a rehash so that the number of elements per bucketstays below a user-specified bound. This ensures that the hash table'sperformance characteristics don't change dramatically as the sizeincreases.
For similar reasons, Google has found it useful to specify a minimumload factor: when the number of elements shrinks by a large enough, thecontainers automatically perform a rehash so that the number of elementsper bucket stays above a user-specified bound. This is useful for tworeasons. First, it prevents wasting a lot of memory when an unorderedassociative container grows temporarily. Second, it prevents amortizediteration time from being arbitrarily large; consider the case of a hashtable with a billion buckets and only one element. (This was discussedeven before TR1 was published; it was TR issue 6.13, which the LWGclosed as NAD on the grounds that it was a known design feature.However, the LWG did not consider the approach of a minimum loadfactor.)
The only interesting question is when shrinking is allowed. In principlethe cleanest solution would be shrinking on erase, just as we grow oninsert. However, that would be a usability problem; it would break anumber of common idioms involving erase. Instead, Google's hash tablesonly shrink on insert and rehash.
The proposed resolution allows, but does not require, shrinking inrehash, mostly because a postcondition for rehash that involves theminimum load factor would be fairly complicated. (It would probably haveto involve a number of special cases and it would probably have tomention yet another parameter, a minimum bucket count.)
The current behavior is equivalent to a minimum load factor of 0. If wespecify that 0 is the default, this change will have no impact onbackward compatibility.
[2010 Rapperswil:]
This seems to a useful extension, but is too late for 0x.Move to Tentatively NAD Future.
[Moved to NAD Future at 2010-11 Batavia]
[LEWG Kona 2017]
Should there be a shrink_to_fit()? Is it too surprising to shrink on insert()? (We understand that shrinking on erase() is not an option.) Maybe make people call rehash(0) to shrink to the min_load_factor? On clear(), the load factor goes to 0 or undefined (0/0), which is likely to violate min_load_factor() min_load_factor(z)'s wording should match max_load_factor(z)'s, e.g. "May change the container’s maximum load factor" Want a paper exploring whether shrink-on-insert has been surprising. From Titus: Google's experience is that maps don't shrink in the way this would help with. NAD, not worth the time. Write a paper if you can demonstrate a need for this.
Proposed resolution:
Add two new rows, and change rehash's postcondition in the unorderedassociative container requirements table in 23.2.8[unord.req]:
Table 87 — Unordered associative container requirements(in addition to container) Expression Return type Assertion/note pre-/post-condition Complexity a.min_load_factor()floatReturns a non-negative number that the container attempts to keep theload factor greater than or equal to. The container automaticallydecreases the number of buckets as necessary to keep the load factorabove this number. constant a.min_load_factor(z)voidPre: zshall be non-negative. Changes the container's minimumload factor, usingzas a hint. [Footnote: the minimumload factor should be significantly smaller than the maximum. Ifzis too large, the implementation may reduce it to a more sensible value.]constant a.rehash(n)voidPost: a.bucket_count() >= n, anda.size() <= a.bucket_count()* a.max_load_factor(). [Footnote: It is intentional that thepostcondition does not mention the minimum load factor.This member function is primarily intended for cases where the user knowsthat the container's size will increase soon, in which case the container'sload factor will temporarily fall belowa.min_load_factor().]a.bucket_cout > a.size() / a.max_load_factor()anda.bucket_count()>= n.Average case linear in a.size(), worst case quadratic.
Add a footnote to 23.2.8[unord.req] p12:
The insert members shall not affect the validity of references tocontainer elements, but may invalidate all iterators to the container.The erase members shall invalidate only iterators and references to theerased elements.
[A consequence of these requirements is that while insert may change thenumber of buckets, erase may not. The number of buckets may be reducedon calls to insert or rehash.]
Change paragraph 13:
The insert members shall not affect the validity of iterators if
(N+n) < z * Bzmin * B <= (N+n) <= zmax * B,whereNis the number of elements inthe container prior to the insert operation,nis the number ofelements inserted,Bis the container's bucket count,zminis the container's minimum load factor,andzmaxis the container's maximum load factor.
Add to theunordered_map class synopsis in section 23.5.3[unord.map],theunordered_multimap class synopsisin 23.5.4[unord.multimap], theunordered_set class synopsis in23.5.6[unord.set], and theunordered_multiset class synopsisin 23.5.7[unord.multiset]:
float min_load_factor() const;void min_load_factor(float z);
In 23.5.3.2[unord.map.cnstr], 23.5.4.2[unord.multimap.cnstr], 23.5.6.2[unord.set.cnstr], and23.5.7.2[unord.multiset.cnstr], change:
...
max_load_factor()returns 1.0andmin_load_factor()returns 0.
Section: 23.2.8[unord.req], 23.5[unord]Status:NADSubmitter: Matt AusternOpened: 2009-08-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
The unordered associative container requirements table specifies thata.set_max_load_factor(z) has return typevoid. However, there is auseful piece of information to return: the previous value. Users whodon't need it can always ignore it.
[2010 Rapperswil:]
The benefit seems minor, while breaking with the getter/setter idiom these overloads support.Move to Tentatively NAD.
[Moved to NAD at 2010-11 Batavia]
Proposed resolution:
In the unordered associative container requirements table, change:
Table 87 — Unordered associative container requirements(in addition to container) Expression Return type Assertion/note pre-/post-condition Complexity a.max_load_factor(z)voidfloatPre: zshall be positive. Changes the container's maximumloadload factor, usingzas a hint.Returns: the previous value ofa.max_load_factor().constant
Change the return type ofset_max_load_factorin the class synopses in 23.5.3[unord.map], 23.5.4[unord.multimap], 23.5.6[unord.set],and 23.5.7[unord.multiset].
If issue1188(i) is also accepted, make the same changes formin_load_factor.
char_traits<T>::int_type requirementsSection: 27.2.3[char.traits.typedefs]Status:NADSubmitter: Sean HuntOpened: 2009-09-03Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [char.traits.typedefs].
View all issues withNAD status.
Discussion:
The footnote forint_type in 27.2.3[char.traits.typedefs] says that
If
eof()can be held inchar_typethen some iostreams implementations may give surprising results.
This implies thatint_type should be a superset ofchar_type. However, the requirements forchar16_t andchar32_t defineint_type to be equal toint_least16_t andint_least32_t respectively.int_least16_t is likely to be the same size aschar_16_t, which may leadto surprising behavior, even ifeof() is not a valid UTF-16 code unit.The standard should not prescribe surprising behavior, especiallywithout saying what it is (it's apparently not undefined, justsurprising). The same applies for 32-bit types.
I personally recommend that behavior be undefined ifeof() is a memberofchar_type, and another type be chosen forint_type (my personalfavorite has always been astruct {bool eof; char_type c;}).Alternatively, the exact results of such a situation should be defined,at least so far that I/O could be conducted on these types as long asthe code units remain valid. Note that the argument that no one streamschar16_t orchar32_t is not really valid as it would be perfectlyreasonable to use abasic_stringstream in conjunction with UTF charactertypes.
[2009-10-28 Ganesh provides two possible resolutions and expresses a preferencefor the second:]
Replace [char.traits.specializations.char16_t] para 3 with:
The member
eof()shall returnan implementation-definedconstant that cannot appear as a valid UTF-16 code unitUINT_LEAST16_MAX[Note: this value is guaranteed tobe a permanently reserved UCS-2 code position ifUINT_LEAST16_MAX ==0xFFFFand it's not a UCS-2 code position otherwise —endnote].Replace [char.traits.specializations.char32_t] para 3 with:
The member
eof()shall returnan implementation-defined constant thatcannot appear as a Unicode code pointUINT_LEAST32_MAX[Note: this value is guaranteed to be apermanently reserved UCS-4 code position ifUINT_LEAST32_MAX ==0xFFFFFFFFand it's not a UCS-4 code position otherwise —endnote].In [char.traits.specializations.char16_t], in thedefinition of
char_traits<char16_t>replace the definition of nestedtypedefint_typewith:namespace std { template<> struct char_traits<char16_t> { typedef char16_t char_type; typedefuint_least16_tuint_fast16_t int_type; ...Replace [char.traits.specializations.char16_t] para 3 with:
The member
eof()shall returnan implementation-definedconstant that cannot appear as a valid UTF-16 code unitUINT_FAST16_MAX[Note: this value is guaranteed tobe a permanently reserved UCS-2 code position ifUINT_FAST16_MAX ==0xFFFFand it's not a UCS-2 code position otherwise —endnote].In [char.traits.specializations.char32_t], in thedefinition of
char_traits<char32_t>replace the definition of nestedtypedefint_typewith:namespace std { template<> struct char_traits<char32_t> { typedef char32_t char_type; typedefuint_least32_tuint_fast32_t int_type; ...Replace [char.traits.specializations.char32_t] para 3 with:
The member
eof()shall returnan implementation-defined constant thatcannot appear as a Unicode code pointUINT_FAST32_MAX[Note: this value is guaranteed to be apermanently reserved UCS-4 code position ifUINT_FAST32_MAX ==0xFFFFFFFFand it's not a UCS-4 code position otherwise —endnote].
[2010 Rapperswil:]
This seems an overspecification, and it is not clear what problem is being solved - these values can be used portably by using the named functions; there is no need for the value itself to be portable.Move to Tentatively NAD.
[Moved to NAD at 2010-11 Batavia]
Proposed resolution:
integral_constant needs a spring cleanSection: 21.3.4[meta.help]Status:NADSubmitter: Alisdair MeredithOpened: 2009-09-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [meta.help].
View all issues withNAD status.
Discussion:
The specification ofintegral_constant has been inheritedessentially unchanged from TR1:
template <class T, T v>struct integral_constant { static const T value = v; typedef T value_type; typedef integral_constant<T,v> type;};In light of 0x language changes there are several things we mightconsider changing, notably the form of specification for value.
The current form requires a static data member have storage allocatedfor it, where we could now implement without this using the new enumsyntax:
template <class T, T v>struct integral_constant {enum : T { value = v }; typedef T value_type; typedef integral_constant type;};The effective difference between these two implementation is:
&integral_constant<T,v>::value;Also note the editorial change to drop the explicit qualification ofintegral_constant in thetypedef type. This makes it quite clear wemean the current instantiation, and cannot be mistaken for a recursivemetaprogram.
Even if we don't mandate this implementation, it would be nice to givevendors freedom under QoI to choose their preferred representation.
The other side of this issue is if we choose to retain the staticconstant form. In that case we should go further and insist onconstexpr, much like we did throughoutnumeric_limits:
template <class T, T v>struct integral_constant { staticconstexpr T value = v; typedef T value_type; typedef integral_constant type;};[Footnote] It turns outconstexpr is part of the Tentatively Readyresolution for1019(i). I don't want to interfere with that issue, butwould like a new issue to consider if the fixed-base enum implementationshould be allowed.
[2009-09-05 Daniel adds:]
I think that the suggested resolution is incomplete andmay have some possible unwanted side-effects. To understandwhy, note that
integral_constantiscompletely specifiedby code in 21.3.4[meta.help]. While this is usually consideredas a good thing, let me give a possible user-definedspecialization that would break given the suggested changes:enum NodeColor { Red, Black };std::integral_constant<NodeColor, Red> red;The reason why that breaks is due to the fact thatcurrent core language rules does only allow integraltypes as enum-bases, see 9.8.1[dcl.enum]/2.
So, I think that we cannot leave the implementation thefreedom to decide which way they would like to providethe implementation, because that is easily user-visible(I don't speak of addresses, but of instantiation errors),therefore if applied, this should be either specified orwording must be added that gives a note about thisfreedom of implementation.
Another possible disadvantage seems to me that user-expectationsare easy to disappoint if they see a failureof the test
assert(typeid(std::integral_constant<int, 0>::value) == typeid(int));or of
static_assert(std::is_same<decltype(std::integral_constant<int, 0>::value), const int>::value, "Bad library");
[2010-01-14 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
Rationale:
We think that the suggested resolution is incomplete and may have some possibleunwanted side-effects. (see Daniel's 2009-09-05 comment for details).
Proposed resolution:
Section: 29.4[complex.numbers]Status:NADSubmitter: Ted ShaneyfeltOpened: 2009-09-26Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [complex.numbers].
View all issues withNAD status.
Discussion:
Concerning mathematically proper operation of the type:
complex<complex<T> >
Generally accepted mathematical semantics of such a construct correspondto quaternions through Cayly-Dickson construct
(w+xi) + (y+zi) j
The proper implementation seems straightforward by adding a fewdeclarations like those below. I have included operator definition forcombining real scalars and complex types, as well, which seemsappropriate, as algebra of complex numbers allows mixing complex andreal numbers with operators. It also allows for constructs such ascomplex<double> i=(0,1), x = 12.34 + 5*i;
Quaternions are often used in areas such as computer graphics, where,for example, they avoid the problem of Gimbal lock when rotating objectsin 3D space, and can be more efficient than matrix multiplications,although I am applying them to a different field.
/////////////////////////ALLOW OPERATORS TO COMBINE REAL SCALARS AND COMPLEX VALUES /////////////////////////template<typename T,typename S> complex<T> operator+(const complex<T> x,const S a) { complex<T> result(x.real()+a, x.imag()); return result;}template<typename T,typename S> complex<T> operator+(const S a,const complex<T> x) { complex<T> result(a+x.real(), x.imag()); return result;}template<typename T,typename S> complex<T> operator-(const complex<T> x,const S a) { complex<T> result(x.real()-a, x.imag()); return result;}template<typename T,typename S> complex<T> operator-(const S a,const complex<T> x) { complex<T> result(a-x.real(), x.imag()); return result;}template<typename T,typename S> complex<T> operator*(const complex<T> x,const S a) { complex<T> result(x.real()*a, x.imag()*a); return result;}template<typename T,typename S> complex<T> operator*(const S a,const complex<T> x) { complex<T> result(a*x.real(), a*x.imag()); return result;}/////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS/////////////////////////template<typename T> double normSq(const complex<complex<T> >q) { return q.real().real()*q.real().real() + q.real().imag()*q.real().imag() + q.imag().real()*q.imag().real() + q.imag().imag()*q.imag().imag();}template<typename T> double norm(const complex<complex<T> >q) { return sqrt(normSq(q));}/////// Cayley-Dickson Constructiontemplate<typename T> complex<complex<T> > conj(const complex<complex<T> > x) { complex<complex<T> > result(conj(x.real()),-x.imag()); return result;}template<typename T> complex<complex<T> > operator*(const complex<complex<T> > ab,const complex<complex<T> > cd) { complex<T> re(ab.real()*cd.real()-conj(cd.imag())*ab.imag()); complex<T> im(cd.imag()*ab.real()+ab.imag()*conj(cd.real())); complex<complex<double> > q(re,im); return q;}//// Quaternion divisiontemplate<typename S,typename T> complex<complex<T> > operator/(const complex<complex<T> > q,const S a) { return q * (1/a);}template<typename S,typename T> complex<complex<T> > operator/(const S a,const complex<complex<T> > q) { return a*conj(q)/normSq(q);}template<typename T> complex<complex<T> > operator/(const complex<complex<T> > n, const complex<complex<T> > d) { return n * (conj(d)/normSq(d));}[2009-10 Santa Cruz:]
NAD Future. There is no consensus or time to move this into C++0X.
[LEWG Kona 2017]
Recommend SG6 - We note thatcomplex<complex> is the wrong way to spell this
[2017-03-03, Kona]
SG6 suggests this issue is a new feature, not a problem with the existingstandard, and should therefore be closed NAD. However, SG6 invites papers that bringthe proposal up to date with the current standard.
Proposed resolution:
Section: 32.6.5.4.3[thread.lock.unique.locking]Status:DupSubmitter: Jeffrey YasskinOpened: 2009-09-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.lock.unique.locking].
View all issues withDup status.
Duplicate of:1159
Discussion:
unique_lock::lock and friends raise"resource_deadlock_would_occur -- if the current thread alreadyowns the mutex (i.e., on entry,owns istrue)." 1)The current thread owning a mutex is not the same as any particularunique_lock::owns beingtrue. 2) There's no need toraise this exception for arecursive_mutex ifowns isfalse. 3) Ifowns is true, we need to raise someexception or the unique_lock will lose track of whether to unlock itselfon destruction, but "deadlock" isn't it. For (3), s/bool owns/intownership_level/ would fix it.
[2009-11-11 Alisdair notes that this issue is very closely related to1159(i),if not a dup.]
[2009-11-14 Moved to Tentatively Dup after 5 positive votes on c++std-lib.]
Proposed resolution:
Section: 32.7.5[thread.condition.condvarany]Status:NADSubmitter: Jeffrey YasskinOpened: 2009-09-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvarany].
View all issues withNAD status.
Discussion:
Forcondition_variable_any, must all lock arguments to concurrent wait calls"match" in some way, similar to the requirement in32.7.4[thread.condition.condvar] thatlock.mutex() returns the samevalue for each of the lock arguments supplied by all concurrentlywaiting threads (viawait ortimed_wait)?
[2010-02-12 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Rationale:
The rationale is that it doesn't matter, and you can't check: the lock types maybe different, or the same and user-defined, so the implementation must provideinternal synchronization anyway.
Proposed resolution:
Section: 32.7.5[thread.condition.condvarany]Status:NADSubmitter: Jeffrey YasskinOpened: 2009-09-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvarany].
View all issues withNAD status.
Discussion:
Forcondition_variable_any, are recursive mutexes allowed? (I think "no")
[2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Proposed resolution:
Rationale:
condition_variable_any::wait accepts any type of mutex. It callsunlock precisely once on entry andlock precisely once onexit. It is up to the user to ensure that this provides the requiredsynchronization. Use of a recursive mutex is safe if either its lock count is 1,so after the single unlock it can be acquired by another thread, or anothermechanism is used to synchronize the data.
Section: 21.3.6.4[meta.unary.prop]Status:NADSubmitter: Alisdair MeredithOpened: 2009-10-07Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.unary.prop].
View all otherissues in [meta.unary.prop].
View all issues withNAD status.
Discussion:
According to p1 21.3.3[meta.type.synop]:
The behavior of a program that adds specializations for any of the classtemplates defined in this subclause is undefined unless otherwisespecified.
I believe we should 'otherwise specify' for the nothrow traits, arethese are exactly the use cases where the end user actually has moreinformation than the compiler.
[2009-10 Santa Cruz:]
Moved to Open. Definitely need to give the users the ability to ensurethat the traits give the right answers. Unsure we want to give them theability to say this in more than one way. Believes the noexcept proposalalready gives this.
[2010 Pittsburgh: Moved to NAD, rationale added below.]
Rationale:
We believe the solution offered byN3050is superior.
Proposed resolution:
Add the following comment:
user specialization permitted to derive from
std::true_typewhen theoperation is known not to throw.
to the following traits in 21.3.6.4[meta.unary.prop] Table 43 Typeproperty predicates.
[This may require a new Comments column]
has_nothrow_default_constructorhas_nothrow_copy_constructorhas_nothrow_assign
mem_fn and variadic templatesSection: 22.10.16[func.memfn]Status:DupSubmitter: Alisdair MeredithOpened: 2009-10-09Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [func.memfn].
View all issues withDup status.
Duplicate of:920
Discussion:
Since we have removed the entry in B[implimits] for thelibrary-specific limit for number of arguments passed tofunction/tuple/etc. I believe we need to update thespec formem_fn to reflect this.
The "Remarks: Implementations may implementmem_fn as a set ofoverloaded function templates." no longer holds, as we cannot create anarbitrary number of such overloads. I believe we should strike theremark and add a second signature:
template<class R, class T, typename ... ArgTypes> unspecified mem_fn(R (T::*pm)(ArgTypes...));
I believe we need two signatures as pointer-to-data-member andpointer-to-member-function-taking-no-args appear to use subtly differentsyntax.
[920(i) as a similar proposed resolution.]
Proposed resolution:
Add to 22.10[function.objects] and 22.10.16[func.memfn]:
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&&);
Strike 22.10.16[func.memfn], p5:
Remarks: Implementations may implementmem_fnas a setof overloaded function templates.
swap's with rvalue-referencesSection: 16[library]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2009-10-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD Editorial status.
Discussion:
The current library contains still rvalue reference-swaps that seem to beoverlooked in the process of switching back to lvalue-ref swaps.
[2009-10 Santa Cruz:]
Editor accepts as NAD Editorial.
Proposed resolution:
Change 22.3[pairs]/1 as indicated:
template <class T1, class T2>struct pair { ... void swap(pair&& p);};Change 22.3[pairs] before p. 17 as indicated:
void swap(pair&&p);
Change 22.3[pairs] before p. 21 as indicated:
template<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>& y);template<class T1, class T2> void swap(pair<T1, T2>&& x, pair<T1, T2>& y);template<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>&& y);
Change 22.4.1[tuple.general]/2, header<tuple> synopsis, as indicated:
// 20.5.2.9, specialized algorithms:template <class... Types>void swap(tuple<Types...>& x, tuple<Types...>& y);template <class... Types>void swap(tuple<Types...>&& x, tuple<Types...>& y);template <class... Types>void swap(tuple<Types...>& x, tuple<Types...>&& y);
Change 22.4.4[tuple.tuple] as indicated:
// 20.5.2.3, tuple swapvoid swap(tuple&&)
Change 22.4.4.4[tuple.swap] before 1 as indicated:
void swap(tuple&&rhs);
Change 22.10[function.objects]/2, header<functional> synopsis, as indicated:
template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)&&);
Change 22.10.17.3[func.wrap.func], as indicated:
// 20.7.15.2.2, function modifiers:void swap(function&&);template<class F, class A> void assign(F, const A&);[..]// 20.7.15.2.7, specialized algorithms:template <class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);template <class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);template <class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
Change 22.10.17.3.8[func.wrap.func.alg] before 1 as indicated:
template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>& f2);template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);template<class R, class... ArgTypes>void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);
Change 20.3.2.2[util.smartptr.shared]/1 as indicated:
// 20.8.12.2.4, modifiers:void swap(shared_ptr&&r);[..]// 20.8.12.2.9, shared_ptr specialized algorithms:template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
Change 27.4[string.classes]/1, header<string> synopsis, as indicated:
// 21.4.8.8: swaptemplate<class charT, class traits, class Allocator>void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>& rhs);template<class charT, class traits, class Allocator>void swap(basic_string<charT,traits,Allocator>&& lhs, basic_string<charT,traits,Allocator>& rhs);template<class charT, class traits, class Allocator>void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>&& rhs);
Change 23.3[sequences]/1, header<deque> synopsis, as indicated:
template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);
Change 23.3[sequences]/1, header<list> synopsis, as indicated:
template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>&& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>&& y);
Change 23.3[sequences]/1, header<queue> synopsis, as indicated:
template <class T, class Allocator>void swap(queue<T, Container>& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>&& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>& x, queue<T, Container>&& y);template <class T, class Container = vector<T>, class Compare = less<typename Container::value_type> >class priority_queue;template <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);
Change 23.3[sequences]/1, header<stack> synopsis, as indicated:
template <class T, class Container>void swap(stack<T, Container>& x, stack<T, Container>& y);template <class T, class Container>void swap(stack<T, Container>&& x, stack<T, Container>& y);template <class T, class Container>void swap(stack<T, Container>& x, stack<T, Container>&& y);
Change 23.3[sequences]/1, header<vector> synopsis, as indicated:
template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);
Change 23.3.5[deque]/2 as indicated:
iterator erase(const_iterator position);iterator erase(const_iterator first, const_iterator last);void swap(deque<T,Allocator>&&);void clear();[..]// specialized algorithms:template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);
Change [deque.special] as indicated:
template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y);template <class T, class Allocator>void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);
Change [forwardlist]/2 as indicated:
iterator erase_after(const_iterator position);iterator erase_after(const_iterator position, iterator last);void swap(forward_list<T,Allocator>&&);[..]// 23.3.3.6 specialized algorithms:template <class T, class Allocator>void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y);template <class T, class Allocator>void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y);template <class T, class Allocator>void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& y);
Change [forwardlist.spec] as indicated:
template <class T, class Allocator>void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y);template <class T, class Allocator>void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y);template <class T, class Allocator>void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& y);
Change 23.3.11[list]/2 as indicated:
iterator erase(const_iterator position);iterator erase(const_iterator position, const_iterator last);void swap(list<T,Allocator>&&);void clear();[..]// specialized algorithms:template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>&& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>&& y);
Change [list.special] as indicated:
template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>&& x, list<T,Allocator>& y);template <class T, class Allocator>void swap(list<T,Allocator>& x, list<T,Allocator>&& y);
Change 23.6.3.1[queue.defn] as indicated:
void swap(queue&&q) { c.swap(q.c); }[..]template <class T, class Container>void swap(queue<T, Container>& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>&& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>& x, queue<T, Container>&& y);
Change 23.6.3.6[queue.special] as indicated:
template <class T, class Container>void swap(queue<T, Container>& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>&& x, queue<T, Container>& y);template <class T, class Container>void swap(queue<T, Container>& x, queue<T, Container>&& y);
Change 23.6.4[priority.queue]/1 as indicated:
void swap(priority_queue&&);// no equality is providedtemplate <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, class Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);
Change 23.6.4.5[priqueue.special] as indicated:
template <class T, class Container, Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, Compare>void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y);template <class T, class Container, Compare>void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);
Change 23.6.6.2[stack.defn] as indicated:
void swap(stack&&s) { c.swap(s.c); }[..]template <class T, class Allocator>void swap(stack<T,Allocator>& x, stack<T,Allocator>& y);template <class T, class Allocator>void swap(stack<T,Allocator>&& x, stack<T,Allocator>& y);template <class T, class Allocator>void swap(stack<T,Allocator>& x, stack<T,Allocator>&& y);
Change 23.6.6.7[stack.special] as indicated:
template <class T, class Container>void swap(stack<T, Container>& x, stack<T, Container>& y);template <class T, class Container>void swap(stack<T, Container>&& x, stack<T, Container>& y);template <class T, class Container>void swap(stack<T, Container>& x, stack<T, Container>&& y);
Change 23.3.13[vector]/2 as indicated:
void swap(vector<T,Allocator>&&);void clear();[..]// specialized algorithms:template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);
Change 23.3.13.3[vector.capacity] before p. 8 as indicated:
void swap(vector<T,Allocator>&&x);
Change [vector.special] as indicated:
template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y);template <class T, class Allocator>void swap(vector<T,Allocator>& x, vector<T,Allocator>&& y);
Change 23.3.14[vector.bool]/1 as indicated:
iterator erase(const_iterator first, const_iterator last);void swap(vector<bool,Allocator>&&);static void swap(reference x, reference y);
Change 23.4[associative]/1, header<map> synopsis as indicated:
template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& y);[..]template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& y);
Change 23.4[associative]/1, header<set> synopsis as indicated:
template <class Key, class Compare, class Allocator>void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(set<Key,T,Compare,Allocator&& x, set<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(set<Key,T,Compare,Allocator& x, set<Key,T,Compare,Allocator>&& y);[..]template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multiset<Key,T,Compare,Allocator&& x, multiset<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multiset<Key,T,Compare,Allocator& x, multiset<Key,T,Compare,Allocator>&& y);
Change 23.4.3[map]/2 as indicated:
iterator erase(const_iterator first, const_iterator last);void swap(map<Key,T,Compare,Allocator>&&);void clear();[..]// specialized algorithms:template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& y);
Change [map.special] as indicated:
template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator>&& x, map<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>&& y);
Change 23.4.4[multimap]/2 as indicated:
iterator erase(const_iterator first, const_iterator last);void swap(multimap<Key,T,Compare,Allocator>&&);void clear();[..]// specialized algorithms:template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& y);
Change [multimap.special] as indicated:
template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator>&& x, multimap<Key,T,Compare,Allocator>& y);template <class Key, class T, class Compare, class Allocator>void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>&& y);
Change 23.4.6[set]/2 and [set.special] as indicated: (twice!)
// specialized algorithms:template <class Key, class Compare, class Allocator>void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(set<Key,Compare,Allocator&& x, set<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(set<Key,Compare,Allocator& x, set<Key,Compare,Allocator>&& y);
Change 23.4.7[multiset]/2 as indicated:
iterator erase(const_iterator first, const_iterator last);void swap(multiset<Key,Compare,Allocator>&&);void clear();[..]// specialized algorithms:template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator&& x, multiset<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator& x, multiset<Key,Compare,Allocator>&& y);
Change [multiset.special] as indicated:
template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator>&& x, multiset<Key,Compare,Allocator>& y);template <class Key, class Compare, class Allocator>void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>&& y);
unique_ptr signatures in synopsisSection: 20.2[memory]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2009-10-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [memory].
View all issues withNAD Editorial status.
Discussion:
Related to296(i). Someunique_ptr signatures are missingfrom the synopsis in 20.2[memory].
[2009-11-04 Howard adds:]
Moved to Tentatively NAD Editorial. The editor has adopted the fix.
Proposed resolution:
Add in 20.2[memory], Header<memory> synopsismissing declarations as shown below:
// 20.8.11 Class unique_ptr:template <class X> class default_delete;template<class T> struct default_delete<T[]>;template <class X, class D = default_delete<T>> class unique_ptr;template<class T, class D> class unique_ptr<T[], D>;template<class T, class D> void swap(unique_ptr<T, D>& x, unique_ptr<T, D>& y);template<class T1, class D1, class T2, class D2>bool operator==(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);template<class T1, class D1, class T2, class D2>bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);template<class T1, class D1, class T2, class D2>bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);template<class T1, class D1, class T2, class D2>bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);template<class T1, class D1, class T2, class D2>bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);template<class T1, class D1, class T2, class D2>bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
Section: 29.5.3.6[rand.req.dist]Status:NADSubmitter: Matthias TroyerOpened: 2009-10-12Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [rand.req.dist].
View all issues withNAD status.
Discussion:
There exist optimized, vectorized vendor libraries for the creation ofrandom number generators, such as Intel's MKL [1] and AMD's ACML [2]. Intiming tests we have seen a performance gain of a factor of up to 80(eighty) compared to a pure C++ implementation (in Boost.Random) whenusing these generator to generate a sequence of normally distributedrandom numbers. In codes dominated by the generation of random numbers(we have application codes where random number generation is more than50% of the CPU time) this factor 80 is very significant.
To make use of these vectorized generators, we use a C++ class modelingtheRandomNumberEngine concept and forwarding the generation of randomnumbers to those optimized generators. For example:
namespace mkl { class mt19937 {.... };}For the generation of random variates we also want to dispatch tooptimized vectorized functions in the MKL or ACML libraries. See thisexample:
mkl::mt19937 eng;std::normal_distribution<double> dist;double n = dist(eng);
Since the variate generation is done through theoperator() of thedistribution there is no customization point to dispatch to Intel's orAMD's optimized functions to generate normally distributed numbers basedon themt19937 generator. Hence, the performance gain of 80 cannot beachieved.
Contrast this with TR1:
mkl::mt19937 eng;std::tr1::normal_distribution<double> dist;std::tr1::variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > rng(eng,dist);double n = rng();
This - admittedly much uglier from an aestethic point of view - designallowed optimization by specializing thevariate_generator template formkl::mt19937:
namespace std { namespace tr1 {template<>class variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > { .... };} }A similar customization point is missing in the C++0x design andprevents the optimized vectorized version to be used.
Suggested resolution:
Add a customization point to the distribution concept. Instead of thevariate_generator template this can be done through a call to afree functiongenerate_variate found by ADL instead ofoperator() of the distribution:
template <RandomNumberDistribution, class RandomNumberEngine>typename RandomNumberDistribution ::result_typegenerate_variate(RandomNumberDistribution const& dist, RandomNumberEngine& eng);
This function can be overloaded for optimized enginges likemkl::mt19937.
[2009-10 Santa Cruz:]
NAD Future. No time to add this feature for C++0X.
[LEWG Kona 2017]
Recommend NAD: The standard has changed enough that the issue doesn't make sense anymore. Write a paper proposing a way to get this performance as changes to the current library.
[Kona 2019: Jonathan notes:]
Libstdc++ has the following non-standard extensions for more efficient generation of large numbers of random numbers:
template<typename ForwardIterator, typename UniformRandomNumberGenerator>void __generate(ForwardIterator, ForwardIterator, UniformRandomNumberGenerator&);template<typename ForwardIterator, typename UniformRandomNumberGenerator>void __generate(ForwardIterator, ForwardIterator, UniformRandomNumberGenerator&, const param_type&);template<typename UniformRandomNumberGenerator>void __generate(result_type*, result_type*, UniformRandomNumberGenerator&, const param_type&);
Proposed resolution:
Section: 16[library]Status:NADSubmitter: Sean HuntOpened: 2009-10-13Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
I wasn't sure whether to consider this a library or a language issue,because the issue is I think it's incorrectly categorized as being partof the library, so I thought I'd send a message to both of you and letyou sort it out.
Most reserved identifiers are treated as unilaterally available to theimplementation, such as to implement language extensions, or providemacros documenting its functionality. However, the requirements forreserved identifers are in 16.4.5.3[reserved.names], which are asubsection of 16.4.5[constraints]. 16.4.5.1[constraints.overview] appears only to apply to "C++ programsthat use the facilities of the C++ standard library", meaning that, intheory, all implementations are erroneous in having any non-standardidentifiers predefined for programs that do not, at some point, includea standard library header.
Furthermore, it's unclear whether the use of certain identifiers is UBor results in an ill-formed program. In particular, 16.4.5.3.3[macro.names] uses a "shall not", where [global.names] says that names are "reserved to theimplementation". 16.4.5.3[reserved.names] seems only to cover theinstance of a name being described as "reserved", so are implementationsrequired to diagnose a program that performs, as an example, "#undefget"?
[2009 Santa Cruz:]
Move to NAD. There may in theory be multiple interpretations possible,but there's no evidence that this causes any genuine problems oruncertainty about what implementations are allowed to do. We do notbelieve this rises to the level of a defect.
Proposed resolution:
Section: 21.3.6.4[meta.unary.prop]Status:NAD EditorialSubmitter: David AbrahamsOpened: 2009-10-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.unary.prop].
View all otherissues in [meta.unary.prop].
View all issues withNAD Editorial status.
Discussion:
Table 43 defines a number of traits that yield true for arrays of classtypes with the trait's property, but not arrays of other types with thatproperty. For example,has_trivial_default_constructor:
Tis a trivial type (3.9) or a class type with a trivial defaultconstructor (12.1) or an array of such a class type.
[2009-10 post-Santa Cruz:]
An array of a trivial type is a trivial type.
Mark as Tentatively NAD Editorial. The wording is OK as is,since an array of a trivial type is a trivial type, but the wording asproposed might be clearer.
Rationale:
The wording is OK as is, since an array of a trivial type is a trivial type.Project editor may wish to accept the suggested wording as editorial.
Proposed resolution:
Change all the traits in question following this pattern:
Tis a trivial type (3.9) or a class type with a trivial default constructor (12.1), or an array of such aclasstype.
i.e., add a comma and delete a "class."
Section: 23[containers]Status:NADSubmitter: Herb SutterOpened: 2009-10-21Last modified: 2020-09-06
Priority:Not Prioritized
View otheractive issues in [containers].
View all otherissues in [containers].
View all issues withNAD status.
Discussion:
SeeN2980.
[2009-10 Santa Cruz]
The paper was lengthy discussed but considerable concern remained to add this feature to C++0x. The LWG does not wish to make a change at this time. Strong consensus was found to consider it for C++1x, though.
[LEWG Kona 2017]
Recommend Open: seems to be existing practice now
[2018-11 San Diego Thursday night issue processing]
Status to NAD; Alisdair to provide rationale.
Rationale:
Insufficient motivation to make a change now. This is existing practice in the major implementations, and they are motivated to do this even if not mandated to do so, because it improves compilation time which benefits their users. If the issue submitter feels strongly about this they are invited to write anupdated paper with suggested wording to mandate it.Proposed resolution:
operator+= (initializer_list<T>) forvalarraySection: 29.6.2.7[valarray.cassign]Status:NADSubmitter: Daniel KrüglerOpened: 2009-10-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [valarray.cassign].
View all issues withNAD status.
Discussion:
Addresses JP 64
During the additions ofinitializer_list overloadsbasic_string added:
basic_string& operator+=(initializer_list<charT>);
but
valarray<T>& operator+= (initializer_list<T>);
was not defined.
[Daniel adds on opening:]
Recommend NAD. The
operator+=overload ofbasic_stringbehaves as-if callingappend, which is completely different inmeaning as the existingoperator+=overloads invalarraywhich just sum the value or values to the existingelements. The suggestion to add a corresponding append function tovalarraywas not considered as appropriate and the request waswithdrawn (c++std-lib-24968).
[2009-10 Santa Cruz:]
Mark as NAD. Request has been withdrawn by NB.
Proposed resolution:
Add to 29.6.2.7[valarray.cassign]:
valarray<T>& operator+= (initializer_list<T>);
vector::resize() missing efficiency guaranteeSection: 23.3.13.3[vector.capacity]Status:NADSubmitter: David AbrahamsOpened: 2009-10-24Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [vector.capacity].
View all otherissues in [vector.capacity].
View all issues withNAD status.
Discussion:
Ifv is avector, I think repeated calls tov.resize( v.size() + 1 ) should be amortized O(1), but it's notclear that's true from the text of the standard:
void resize(size_type sz);Effects: If
sz < size(), equivalent toerase(begin() + sz, end());. Ifsize() < sz, appendssz - size()default constructed elements to thesequence.
Seems to me if we usedpush_back instead of appends, we might be givingthe guarantee I'd like. Thoughts?
[2009-11-10 Howard adds:]
Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale addedbelow.
Proposed resolution:
In 23.3.13.3[vector.capacity]/10, change
void resize(size_type sz);Effects: If
sz < size(), equivalent toerase(begin() + sz, end());. Ifsize() < sz,appendsequivalent tosz - size()default constructed elements to thesequencesz - size()consecutive evaluations ofpush_back(T()).
Rationale:
The description in terms ofpush_back led some to believe thatone could expect the exact same growth pattern from bothresize andpush_back (e.g.) which could lead to sub-optimal implementations.Additionally, 23.3.13[vector], p1 includes a statement that this container"supports (amortized) constant time insert and erase operations at the end;",therefore addressing the concern of this issue.
basic_stringbufSection: 31.8.2.2[stringbuf.cons]Status:NADSubmitter: Martin SeborOpened: 2009-10-29Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [stringbuf.cons].
View all issues withNAD status.
Discussion:
I just came across issue1204(i) -- Global permission to move, whichseems to address the concern raised by the example in c++std-lib-25030.
IIUC, the example violates the permission to assume that argumentsbound to rvalue references are unnamed temporaries granted toimplementations by the resolution of issue1204(i) - Global permissionto move.
I.e., theostringstream(ostringstream &&rhs) ctor can leave therhspointers pointing to the newly constructed object's buffer just aslong as the dtor doesn't change or invalidate the buffer. The callermay not make any assumptions about rhs after the move beyond it beingsafe to destroy or reassign.
So unless I misunderstood something, I still think thebasic_stringbufmove ctor is overspecified. Specifically, I think the third sentencein the Effects clause and the last 6 bullets in the Postconditionsclause can, and IMO should, be stricken.
[2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.Rationale added below.]
Rationale:
The sense of 1251 appears to be that thebasic_stringbuf moveconstructor offers more guarantees than the minimum. This is true, and quitecorrect. The additional words guarantee that the internal buffer has genuinelytransferred from one object to another, and further operations on the originalwill not affect the buffer of the newly created object. This is a veryimportant guarantee, much as we see that a moved-fromunique_ptr isguaranteed to be empty.
Proposed resolution:
Strike from 31.8.2.2[stringbuf.cons]:
basic_stringbuf(basic_stringbuf&& rhs);Effects: Move constructs from the rvalue
rhs. It isimplementation-defined whether the sequence pointers in*this(eback(),gptr(),egptr(),pbase(),pptr(),epptr()) obtain the values whichrhshad.Whether they do or not,The openmode,locale and any other state of*thisandrhsreferenceseparate buffers (if any at all) after the construction.rhsis also copied.Postconditions: Let
rhs_prefer to the state ofrhsjust prior to this construction and letrhs_areferto the state ofrhsjust after this construction.
str() == rhs_p.str()gptr() - eback() == rhs_p.gptr() - rhs_p.eback()egptr() - eback() == rhs_p.egptr() - rhs_p.eback()pptr() - pbase() == rhs_p.pptr() - rhs_p.pbase()epptr() - pbase() == rhs_p.epptr() - rhs_p.pbase()if(eback()) eback() != rhs_a.eback()if(gptr()) gptr() != rhs_a.gptr()if(egptr()) egptr() != rhs_a.egptr()if(pbase()) pbase() != rhs_a.pbase()if(pptr()) pptr() != rhs_a.pptr()if(epptr()) epptr() != rhs_a.epptr()
Section: 23.2.4[sequence.reqmts]Status:NADSubmitter: Sean HuntOpened: 2009-11-05Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD status.
Discussion:
According to 23.2.4[sequence.reqmts],X(il) isequivalent toX(il.begin(), il.end()). Should it instead beequivalent toX(move_iterator(il.begin()),move_iterator(il.end())) so that needless copies are not made? Thisdoesn't seem ideal either - it may make more sense to provide twooverloads for the constructor, one for move and one for copy.
[2009-11-10 Howard adds:]
I've moved this issue to Tentatively NAD after 5 positive votes on c++std-lib,and added a rationale below.
Proposed resolution:
Rationale:
There is no consensus at this time within EWG or CWG to make therequired language changes. Therefore this is not something that the LWGcan even consider. Should such language changes be made for a futurestandard, no doubt there would need to be an accompanying library impactsurvey.
swap overloads forregexSection: 28.6.3[re.syn]Status:NADSubmitter: Howard HinnantOpened: 2009-11-12Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.syn].
View all issues withNAD status.
Discussion:
Addresses: UK 314
In Message c++std-lib-25529, Alisdair writes:
UK comment 314requests rvalue swap overloads in a couple of places theywere missed.
We have in general reverted to the single swap signature taking lvaluereferences, which could be seen as the alternative solution toUK 314,bringing consistency to the standard <g>
Either way, I no longer expect to see any work to resolve this comment -the work is complete and it should be either marked Rejected, orAccepted with Modifications (namely, removing all other rvalue swaps!)
[Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
Proposed resolution:
Rationale:
We have in general reverted to the single swap signature takinglvalue references, which could be seen as the alternative solution toUK 314, bringing consistency to the standard.
longjmp and destructorsSection: 17.14[support.runtime]Status:NADSubmitter: Sean HuntOpened: 2009-11-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [support.runtime].
View all issues withNAD status.
Discussion:
17.14[support.runtime]/4 says thatlongjmp is undefined ifunwinding by the mechanism used by catch and throw would invoke any nontrivialdestructors. However, the text as written is rather vague, in particular whendealing withcatch(...):
void foo() { jump_buf buf; non_trivial_dtor n1; // 1 if (!setjmp(buf)) { non_trivial_dtor n2; // 2 try { longjmp(buf, 1); } catch (...) { } }}My interpretation of the meaning of 17.14[support.runtime]/4 is thatdeclaration 2, but not 1, would cause thelongjmp to be undefinedbehavior. However, it's not entirely clear from the text. Arguably, replacingthesetjmp andlongjmp withcatch would still causethe destructor forn1 to be called after the unwinding, which wouldlead to undefined behavior. This is clearly not an intended consequence of thewording. However, it is probably still UB, asn1 now has"indeterminate" value, and running its destructor onfoo's exit willcause Bad Things.
Declarations 2 has a more interesting issue. Thecatch(...) muddles upthe definition that usesthrow andcatch - iflongjmp() were indeed athrow, control would never return tothesetjmp. As such,n2's destructor wouldn't be called(except by the argument forn1, which is that the destructor would becalled later as the frame was left in the normal control flow).
I suggest that paragraph 4 of 17.14[support.runtime] should be replacedwith the following, or something that reads better but has the same effect:
The function signature
longjmp(jmp_buf jbuf, int val)has morerestricted behavior in this International Standard. A call tolongjmphas undefined behavior if any non-trivial destructors would be called were thelongjmpcall replaced with a throw-expression whose nearest matchinghandler were a (possibly imaginary) function-try-block on the functioncontaining the correspondingsetjmpcall.
[2009-11-17 Moved to Tentatively NAD after 5 positive votes on c++std-lib. Rationale added below.]
Proposed resolution:
Change 17.14[support.runtime]/4:
The function signature
longjmp(jmp_buf jbuf, int val)has morerestricted behavior in this International Standard.AA call tosetjmp/longjmpcall pair has undefined behavior if replacingthesetjmpandlongjmpbycatchandthrowwould invoke any non-trivial destructors for any automatic objects.longjmphas undefined behavior if any non-trivialdestructors would be called were thelongjmpcall replaced with athrow-expression whose nearest matching handler were a (possibly imaginary)function-try-block on the function containing the correspondingsetjmpcall.
Rationale:
In the given example, it is clear that it is onlyn2 and notn1 that is destroyed by thelongjmp.
At this late stage in the standards process, we are focusing on issues thatimpact users or implementers. Trying to rewrite complex wording just for thesake of improved clarity is likely to do more harm than good.
std::split algorithmSection: 26[algorithms]Status:NADSubmitter: Igor SemenovOpened: 2009-12-07Last modified: 2019-02-26
Priority:Not Prioritized
View otheractive issues in [algorithms].
View all otherissues in [algorithms].
View all issues withNAD status.
Discussion:
Motivation and Scope
Splitting strings into parts by some set of delimiters is an often task, butthere is no simple and generalized solution in C++ Standard. Usually C++developers usestd::basic_stringstream<> to split string intoparts, but there are several inconvenient restrictions:
Impact on the Standard
This algorithm doesn't interfere with any of current standard algorithms.
Design Decisions
This algorithm is implemented in terms of input/output iterators. Also, there isone additional wrapper forconst CharType * specified delimiters.
Example implementation
template< class It, class DelimIt, class OutIt >void split( It begin, It end, DelimIt d_begin, DelimIt d_end, OutIt out ){ while ( begin != end ) { It it = std::find_first_of( begin, end, d_begin, d_end ); *out++ = std::make_pair( begin, it ); begin = std::find_first_of( it, end, d_begin, d_end, std::not2( std::equal_to< typename It::value_type >() ) ); }}template< class It, class CharType, class OutIt >void split( It begin, It end, const CharType * delim, OutIt out ){ split( begin, end, delim, delim + std::strlen( delim ), out );}Usage
std::string ss( "word1 word2 word3" );std::vector< std::pair< std::string::const_iterator, std::string::const_iterator > > v;split( ss.begin(), ss.end(), " ", std::back_inserter( v ) );for ( int i = 0; i < v.size(); ++i ){ std::cout << std::string( v[ i ].first, v[ i ].second ) << std::endl;}// word1// word2// word3[2010-01-22 Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.Rationale added below.]
[LEWG Kona 2017]
Recommend NAD: Paper encouraged. Have papers for this;LEWG259.
Rationale:
The LWG is not considering completely new features for standardization at thistime. We would like to revisit this good suggestion for a future TR and/orstandard.
Proposed resolution:
Add to the synopsis in 26.1[algorithms.general]:
template< class ForwardIterator1, class ForwardIterator2, class OutputIterator > void split( ForwardIterator1 first, ForwardIterator1 last, ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last, OutputIterator result );template< class ForwardIterator1, class CharType, class OutputIterator > void split( ForwardIterator1 first, ForwardIterator1 last, const CharType * delimiters, OutputIterator result );
Add a new section [alg.split]:
template< class ForwardIterator1, class ForwardIterator2, class OutputIterator > void split( ForwardIterator1 first, ForwardIterator1 last, ForwardIterator2 delimiter_first, ForwardIterator2 delimiter_last, OutputIterator result );1.Effects: splits the range
[first, last)into parts, using anyelement of[delimiter_first, delimiter_last)as a delimiter. Resultsare pushed to output iterator in the form ofstd::pair<ForwardIterator1,ForwardIterator1>. Each of these pairs specifies a maximal subrange of[first, last)which does not contain a delimiter.2.Returns: nothing.
3.Complexity: Exactly
last - firstassignments.template< class ForwardIterator1, class CharType, class OutputIterator > void split( ForwardIterator1 first, ForwardIterator1 last, const CharType * delimiters, OutputIterator result );1.Effects: split the range
[first, last)into parts, using anyelement ofdelimiters(interpreted as zero-terminated string) as adelimiter. Results are pushed to output iterator in the form ofstd::pair<ForwardIterator1, ForwardIterator1>. Each of thesepairs specifies a maximal subrange of[first, last)which does notcontain a delimiter.2.Returns: nothing.
3.Complexity: Exactly
last - firstassignments.
Section: 22.2[utility]Status:NADSubmitter: Ion GaztañagaOpened: 2009-12-14Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [utility].
View all issues withNAD status.
Discussion:
In section 16.4.4.6[allocator.requirements], Table 40 — Allocator requirements,the following expression is required for allocator pointers:
Table 40 — Allocator requirements Expression Return type Assertion/note
pre-/post-conditionDefault static_cast<X::pointer>(w)X::pointerstatic_cast<X::pointer>(w) == p
To achieve this expression, a smart pointer writer must introduce an explicitconversion operator fromsmart_ptr<void> tosmart_ptr<T> so thatstatic_cast<pointer>(void_ptr) is a valid expression.Unfortunately this explicit conversion weakens the safety of a smart pointersince the following expression (invalid for raw pointers) would become valid:
smart_ptr<void> smart_v = ...;smart_ptr<T> smart_t(smart_v);
On the other hand,shared_ptr also defines its own casting functions in20.3.2.2.10[util.smartptr.shared.cast], and although it's unlikely that aprogrammer will useshared_ptr asallocator::pointer, havingtwo different ways to do the same cast operation does not seem reasonable. Apossible solution would be to replacestatic_cast<X::pointer>(w)expression with a user customizable (via ADL)static_pointer_cast<value_type>(w), and establish thexxx_pointer_cast functions introduced byshared_ptr as therecommended generic casting utilities of the standard.
Unfortunately, we've experienced problems in Boost when trying to establishxxx_pointer_cast as customization points for generic libraries (http://objectmix.com/c/40424-adl-lookup-explicit-template-parameters.html)because these casting functions are called with explicit template parameters andthe standard says in 13.10.2[temp.arg.explicit] p.8 "Explicit templateargument specification":
8 ...But when a function template with explicit template arguments is used, thecall does not have the correct syntactic form unless there is a functiontemplate with that name visible at the point of the call. If no such name isvisible, the call is not syntactically well-formed and argument-dependent lookupdoes not apply.
So we can do this:
template<class BasePtr>void generic_ptr_swap(BasePtr p){ //ADL customization point swap(p, p); //...}but not the following:
template<class BasePtr>void generic_ptr_algo(BasePtr p){ typedef std::pointer_traits<BasePtr>::template rebind<Derived> DerivedPtr; DerivedPtr dp = static_pointer_cast<Derived>(p);}The solution to makestatic_pointer_cast a customization point is toadd a generic declaration (no definition) ofstatic_pointer_cast in anamespace (likestd) and apply "usingstd::static_pointer_cast" declaration to activate ADL:
namespace std{template<typename U, typename T>unspecifiedstatic_pointer_cast(T&&) = delete;}template<class BasePtr>void generic_ptr_algo(BasePtr p){ typedef std::pointer_traits<BasePtr>::template rebind<Derived> DerivedPtr; //ADL applies because static_pointer_cast is made // visible according to [temp.arg.explicit]/8 using std::static_pointer_cast; DerivedPtr dp = static_pointer_cast<Derived>(p); //...}A complete solution will need also the definition ofstatic_pointer_cast for raw pointers, and this definition has beenpresent in Boost (http://www.boost.org/boost/pointer_cast.hpp) for years.
[2010-03-26 Daniel made editorial adjustments to the proposed wording.]
[Moved to NAD Future at 2010-11 Batavia]
This is a new feature rather than a defect. It can be added later: "this is such a hairy area that people will put up with changes"
[LEWG Kona 2017]
Recommend NAD: NAD. Should bring a paper as a proposal for 2020.
Proposed resolution:
Add to section 22.2[utility] Utility components, Header<utility> synopsis:
// 20.3.X, generic pointer cast functionstemplate<typename U, typename T>unspecifiedstatic_pointer_cast(T&&) = delete;template<typename U, typename T>unspecifieddynamic_pointer_cast(T&&) = delete;template<typename U, typename T>unspecifiedconst_pointer_cast(T&&) = delete;//Overloads for raw pointerstemplate<typename U, typename T>auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));template<typename U, typename T>auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));template<typename U, typename T>auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));
Add to section 22.2[utility] Utility components, a new subclause20.3.X Pointer cast utilities [pointer.cast]:
20.3.X Pointer cast utilities [pointer.cast]
1 The library defines generic pointer casting function templates so that template codecan explicitly make these names visible and activate argument-dependent lookupfor pointer cast calls.
//Generic declarationstemplate<typename U, typename T>unspecifiedstatic_pointer_cast(T&&) = delete;template<typename U, typename T>unspecifieddynamic_pointer_cast(T&&) = delete;template<typename U, typename T>unspecifiedconst_pointer_cast(T&&) = delete;2 The library also defines overloads of these functions for raw pointers.
//Overloads for raw pointerstemplate<typename U, typename T>auto static_pointer_cast(T* t) -> decltype(static_cast<U*>(t));Returns:
static_cast<U*>(t)template<typename U, typename T>auto dynamic_pointer_cast(T* t) -> decltype(dynamic_cast<U*>(t));Returns:
dynamic_cast<U*>(t)template<typename U, typename T>auto const_pointer_cast(T* t) -> decltype(const_cast<U*>(t));Returns:
const_cast<U*>(t)[Example:
#include <utility> //static_pointer_cast#include <memory> //pointer_traitsclass Base{};class Derived : public Base{};template<class BasePtr>void generic_pointer_code(BasePtr b){ typedef std::pointer_traits<BasePtr>::template rebind<Derived> DerivedPtr; using std::static_pointer_cast; //ADL applies now that static_pointer_cast is visible DerivedPtr d = static_pointer_cast<Derived>(b);}—end example]
Replace in section 16.4.4.6[allocator.requirements] Table 40 — Allocatorrequirements, the following table entries for allocator pointers:
Table 40 — Allocator requirements Expression Return type Assertion/note
pre-/post-conditionDefault static_pointer_cast<X::pointerT>(w)X::pointerstatic_pointer_cast<X::pointerT>(w) == pstatic_pointer_cast<X::const_pointerconst T>(w)X::const_pointerstatic_pointer_cast<X::const_pointerconst T>(z) == q
map andmultimap value_compare overspecifiedSection: 23.4.3[map]Status:NADSubmitter: Alisdair MeredithOpened: 2009-12-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [map].
View all issues withNAD status.
Discussion:
The container class templatesmap andmultimap both contain anested type calledvalue_compare, that is used to compare thevalue_type pair elements, an adaptor of the user-supplied comparisonfunction-like object.
I believe these types are over-specified, as we require a distinct type for eachtemplate, even though the allocator plays no part in the comparator, andmap andmultimap value_compare classes could easily be shared. The benefits are similar to the SCARY iterator proposal (although on a muchsmaller scale!) but unlike SCARY, this is not a QoI issue today but activelyprohibited.
If thevalue_compare classes were marked 'exposition only', a vendorwould be free to experiment with implementations that do not produce so manytemplate instantiations with negligible impact on conforming programs. (Thereis a minor risk that programs could no longer portably overload functions takingvalue_compare types. This scenario is extremely unlikely outsideconformance suites.)
(Note that there are no similar problems for unordered maps, nor any of the setvariants)
[2010-01-31 Moved to Tentatively NAD after 5 positive votes on c++std-lib.Rationale added below.]
Rationale:
Thevalue_compare specification is an unfortunate bit from the pastthat we have to live with. Fortunately vendors can work around the problemsmentioned in this issue.
Proposed resolution:
p2 23.4.3[map]:Above the declaration of classvalue_compare in the map synopsis, add:
template <class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key, T> > >class map {public: // types: ...// exposition only. class value_compare : public binary_function<value_type,value_type,bool> { ...p2 23.4.4[multimap]:Above the declaration of classvalue_compare in the map synopsis, add:
template <class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key, T> > >class multimap {public: // types: ...// exposition only. class value_compare : public binary_function<value_type,value_type,bool> { ...clear() and assignmentSection: 23.2.4[sequence.reqmts]Status:NAD EditorialSubmitter: Nicolai JosuttisOpened: 2010-01-01Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [sequence.reqmts].
View all otherissues in [sequence.reqmts].
View all issues withNAD Editorial status.
Discussion:
I propose thatclear() be defined to be equivalent toerase(begin(),end()) except not using copy or move of elements.
To: C++ libraries mailing list
Message c++std-lib-26465and specifiying as post:
size()==0might also not be appropriatebecause forward-Lists provide nosize(), this it should be:post:empty()==trueBjarne Stroustrup schrieb/wrote:
To: C++ libraries mailing list
Message c++std-lib-26458in table 94 we define
clear()as:a.clear() void erase(begin(), end())post: size() == 0Now
eraserequires assignment (MoveAssignable) which makessense if we have to move an element, but why should that be required fromclear()where all elements are destroyed?
[2010-01-23 Alisdiar provides wording.]
[2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]
[2010-01-30 Daniel opens:]
First, I read the newly proposed spec for
clear()that it does ingeneralnot invalidate a previous past-the-end iterator value, butdequesays in 23.3.5.4[deque.modifiers] for the semantics oferasethat erasures at the end will invalidate the past-the-enditerator. With removal of a direct binding betweenclear()anderase()there seem to be some fixes necessary. One way to fix thatwould be to mention in Table 94 that this "may also invalidate the past-the-enditerator" and then to mention for all specific containers where this does nothappen, the exception, [1] e.g. instd::vector.std::vectorhas no own specification ofclear()and one aspect of the closed issue1102(i) was to realize just that (indirectly viaerase). IMOwe should now add an extra specification forclear(). Btw.:std::vector::erasereads to me that it would invalidate previouspast-the-end values (and that seems correct in general).Before I will provide explicit wording, I would like todiscuss these points.
[1]
std::listdoes fortunately specify that clear does not invalidatethe past-the-end iterator.
[2010-02-08 Moved to Tentatively NAD Editorial after 5 positive votes on c++std-lib.Rationale added below.]
Rationale:
Solved as proposed by LWG704(i).
Proposed resolution:
Change 23.2.2[container.requirements.general]/10:
Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.2.3, and 23.3.6.4) allcontainer types defined in this Clause meet the following additionalrequirements:
- ..
- no
erase(),clear(),pop_back()orpop_front()function throws an exception.- ...
Replace the following words from Table 94 — Sequence containerrequirements (in addition to container) in 23.2.4[sequence.reqmts]:
Table 94 — Sequence container requirements (in addition tocontainer) Expression Return type Assertion/note
pre-/post-conditiona.clear()voiderase(begin(), end())
Destroys all elements in the container a. Invalidates all references,pointers, and iterators referring to the elements ofaand mayinvalidate the past-the-end iterator.
post:.size() == 0a.empty() == true
Add a new paragraph after [forwardlist.modifiers]/23:
void clear();23Effects: Erases all elements in the range
[begin(),end()).Remarks: Does not invalidate past-the-end iterators.
emplace semantics for sequence and associated containersSection: 23.2.7[associative.reqmts], 23.2.8[unord.req]Status:NADSubmitter: Nicolai JosuttisOpened: 2010-01-03Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
According to the new naming scheme introduced withN2680
vector<T> v;v.emplace(v.begin(),x,y,z)
now has a different semantics than
set<T> s;s.emplace(s.begin(),x,y,z);
While the version forvectors takes the first argument as position andthe remaining for construction, the version forsets takes allarguments for construction.
IMO, this is a serious design mistake for a couple of reasons:
First, in principle, all STL member functions should have the same behavior withthe same member function to avoid confusion and allow to write proper genericcode.
In fact, when I write the following simple function template:
template <typename T>void doEmplace (T& cont){ cont.emplace(cont.begin(),"nico","josuttis",42);}the semantics depends on the type of the container.
In addition, I also guess using the nameemplace_hint() instead ofemplace() for associative containers is a design mistake. According tomy knowledge, it was a design goal of the original STL to provide ONEinsert function, which works for ALL containers. This wasinsert(pos,val).
The trick to declarepos as a hint, allowed that we could implement agenericinsert for all containers. Now, with the newemplacenaming scheme, this trick is gone for the new kind of insertion.
I consider this to be a serious design penalty because once thisis specified we can't fix that without breaking backward compatibility.
However, we have two choices for a fix:
emplace_hint(pos,val) for associative containers back toemplace(pos,val). However to avoid the overloading problems, we alsohave to rename the existingemplace(val) functions to something else (Idon't have a good name here at hand).emplace(val) for associative containers as it is, but renameemplace(pos,val) for sequence containers andemplace_hint(pos,val) to something likeemplace_at(pos,val),declaring thatpos is a hint for associative containers.[2010 Pittsburgh: Moved to NAD, rationale added below.]
Rationale:
There was no consensus to make this change.
Proposed resolution:
In 23.2.8[unord.req], change:
Table 96 — Associative container requirements (in addition to container) expression Return type Assertion/note pre-/post-condition Post-condition ... a_uniq.emplace_value(args)pair<iterator, bool>inserts a T object t constructed with std::forward<Args>(args)...
if and only if there is no element in the container with key equivalent to the key of t.
The bool component of the returned pair is true if and only if the insertion takes place, and the iterator component of the pair points to the element with key equivalent to the key of t.logarithmic a_eq.emplace_value(args)iteratorinserts a T object t constructed with std::forward<Args>(args)... and returns the iterator pointing to the newly inserted element. logarithmic a.emplace_hint(p,args)iteratorequivalent to a.emplace_value(std::forward<Args>(args)...). Return value is an iterator pointing to the element with the key equivalent to the newly inserted element. The const_iterator p is a hint pointing to where the search should start. Implementations are permitted to ignore the hint.logarithmic in general, but amortized constant if the element is inserted right after p ...
In 23.2.8[unord.req], change:
Table 98 — Unordered associative container requirements (in addition to container) expression Return type Assertion/note pre-/post-condition Post-condition ... a_uniq.emplace_value(args)pair<iterator, bool>inserts a Tobjecttconstructed withstd::forward<Args>(args)...if and only if there is no element in the container with key equivalent to the key oft. The bool component of the returned pair is true if and only if the insertion takes place, and the iterator component of the pair points to the element with key equivalent to the key of t.Average case O(1), worst case O(a_uniq.size()). a_eq.emplace_value(args)iteratorinserts a T object t constructed with std::forward<Args>(args)... and returns the iterator pointing to the newly inserted element. Average case O(1), worst case O(a_eq.size()). a.emplace_hint(p,args)iteratorequivalent to a.emplace_value(std::forward<Args>(args)...). Return value is an iterator pointing to the element with the key equivalent to the newly inserted element. The const_iterator p is a hint pointing to where the search should start. Implementations are permitted to ignore the hint.Average case O(1), worst case O(a.size()). ...
In 23.4.3[map], 23.4.6[set], 23.5.3[unord.map], 23.5.6[unord.set], change:
// modifiers:
template <class... Args> pair<iterator, bool> emplace_value(Args&&... args);
template <class... Args> iterator emplace_hint(const_iterator position, Args&&... args);
In 23.4.4[multimap], 23.4.7[multiset], 23.5.4[unord.multimap], 23.5.7[unord.multiset], change:
// modifiers:
template <class... Args> iterator emplace_value(Args&&... args);
template <class... Args> iterator emplace_hint(const_iterator position, Args&&... args);
initializer_list overloads ofmin,max, andminmaxSection: 26.8.9[alg.min.max]Status:NADSubmitter: Niels DekkerOpened: 2010-02-02Last modified: 2017-09-07
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withNAD status.
Discussion:
In San Francisco, June 2008,N2722was adopted, replacing the variadic templatesmin,max, andminmax by overloads that have aninitializer_list<T>parameter. The paper showed benchmark results whereininitializer_listversions ofmin appeared to outperform the corresponding variadictemplate. Unfortunately, in October 2009 a very serious error was detected inthe benchmark. (c++std-lib-25210).In fact, aninitializer_list<T> version ofmin oftenappears to performworse than the corresponding variadic template,especially whenT has an expensive copy constructor (c++std-lib-25253,http://www.xs4all.nl/~nd/dekkerware/issues/n2772_fix).
IMO, the biggest problem of theinitializer_list overloads is that theypass and returnT objectsby value. Which has the followingconsequences:
T isCopyConstructible. IMO that is too much of aconstraint for a generic, general purpose function likestd::min<T>.T's less-than-operatorthrows nothing. (And of course, less-than typically throws nothing.)std::min andstd::max.Consider the subtle difference betweenconst T& c1 = min(a,b); andconst T& c2 = min({a,b}); (c++std-lib-25265)In the future, this problem might be solvable by using aninitializer_list ofconst references, instead:
const T& min(initializer_list<const T&>);const T& max(initializer_list<const T&>);pair<const T&, const T&> minmax(initializer_list<const T&>);
It is unlikely that C++0x will supportinitializer_list<const T&>, but technically it seems possible to add such a languagefeature after C++0x (c++std-core-15428).
Variadic templates ofmin,max, andminmax, asproposed byN2551(Sylvain Pion), do have some other advantages overinitializer_listoverloads:
constexpr,now thatCWG issue #991 is in drafting status.Unfortunately, the variadic templates ofmin,max, andminmax may still need further improvement, before having them in theStandard Library. Especially the optionalCompare parameter appears tobe a concern. So for this moment I recommend to keep both versions out of C++0x,and postpone further discussion until after C++0x.
[2010 Pittsburgh: Discussed and the LWG still prefers the initializer listsolution ofN2772.]
Rationale:
We prefer the solution ofN2772which will be reapplied.
Proposed resolution:
Remove both variadic templates andinitializer_list overloads ofmin,max, andminmax from the synopsis in26.1[algorithms.general] and from 26.8.9[alg.min.max].
[Note: This proposed resolution will resolve LWG915(i) as NAD.]
Section: 29.5.8.1[rand.util.seedseq]Status:NADSubmitter: Daniel KrüglerOpened: 2010-02-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.util.seedseq].
View all issues withNAD status.
Discussion:
The Seed sequence requirements (29.5.3.2[rand.req.seedseq]) require theexistence of a member function
template<typename OutputIterator>void param(OutputIterator ob);
The fact that this function returnsvoid instead of the value ofob after accepting the sequence data leads to the same problem as inissue865(i) - In case of pure output iterators there is no way toserialize further data into that data sink.
[2010-02-07 Howard adds:]
At the time this issue was opened, the suggested changes are with respect to ananticipated draft which does not yet exist.
[2010 Pittsburgh:]
No technical counterarguments, but it is simply too late in the processto make this change at this point.
Proposed resolution:
In Table 109 — Seed sequence requirements, expression "r.param(ob)"change the
Return type entry:
voidOutputIterator
In 29.5.8.1[rand.util.seedseq], class seed_seq synopsis change
template<class OutputIterator>voidOutputIterator param(OutputIterator dest) const;
NULL andnullptrSection: 17.2[support.types]Status:NADSubmitter: Sean HuntOpened: 2010-02-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [support.types].
View all issues withNAD status.
Discussion:
Currently, the 17.2[support.types]/3 allowsNULL to be anynull pointer constant. The footnote marks that 0 or 0L might be appropriate.However, this definition also allows the implementation to defineNULLto benullptr. This may lead to overload and conversion issues moreserious than with the C++98 version:
void f(void*);void f(int);void g(){ // calls f(int) if NULL is integral // calls f(void*) if NULL is nullptr f(NULL);}Possible resolutions:
NULL from beingnullptrNULL to benullptrMakingNULLnullptr would improve code correctness, andbreaking backwards compatibility shouldn't be a huge concern asNULLshouldn't be used except as a null pointer constant anyways.
[2010-02-10 Chris provided wording.]
[2010 Pittsburgh: Moved to NAD, rationale added below.]
Rationale:
The LWG discussed the proposed resolution and several other options. There wasno concensus to make this or any other changes.
Proposed resolution:
17.2[support.types]
3 The macro
NULLis defined to benullptr.isan implementation-defined C++ null pointer constant in this InternationalStandard (4.10).196
196) Possible definitions include0and0L, but not(void*)0.
20.2.12[c.malloc]
7 The contents are the same as the Standard C library header
<string.h>, with the change tomemchr()specified in21.6and the macroNULLdefined to benullptr.
[date.time]
2 The contents are the same as the Standard C library header
<time.h>.232except the macroNULL, which is defined to benullptr. The functionsasctime,ctime,gmtime, andlocaltimearenot required to avoid data races (17.6.4.8).
28.3.5[c.locales]
2 The contents are the same as the Standard C library header
<locale.h>except the macroNULL, which is definedto benullptr.
C.8.3.4[diff.null]
1 The macro
NULL, defined in any of<clocale>,<cstddef>,<cstdio>,<cstdlib>,<cstring>,<ctime>, or<cwchar>, isnullptran implementation-defined C++ null pointer constant inthis International Standard (18.2).
asyncSection: 32.10.9[futures.async]Status:NAD EditorialSubmitter: Jonathan WakelyOpened: 2009-02-09Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [futures.async].
View all otherissues in [futures.async].
View all issues withNAD Editorial status.
Discussion:
Both overloads ofasync returnfuture<typenameF::result_type> which requires thatF has a nested type. Thispreventsasync being used with function pointers and makes the examplein 32.10.9[futures.async] invalid. I believe this is unintentional.
The proposed resolution also addresses editorial issues with thelaunch_policy function parameter.
For the first overload it is not sufficient to returnfuture<typenameresult_of<F(ArgTypes...)>::type>. Callingasync(launch::xxx,foo, bar) performs argument deduction on bothasync overloads,which for the first overload attempts to instantiateresult_of<launch(F,ArgTypes...)>, which is invalid. SFINAE must be used to prevent that.
[2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]
[2010-02-12 Daniel opens:]
[..] if
decay<F>::typeis of typestd::launch.or
[..] if
remove_cv<remove_reference<F>::type>::typeis oftypestd::launch.The latter is the more specific form, but the former is equivalent tothe latter for all cases that can occur here. I suggest to use theformer for simplicity, but expect that implementations can effectivelyuse the latter.
[2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.]
[2010 Pittsburgh:]
Moved to NAD Editorial. Rationale added below.
Rationale:
Solved by N3058.
Proposed resolution:
In 32.10.1[futures.overview] paragraph 1:
template <class F, class... Args>future<typename F::result_type>future<typename result_of<F(Args...)>::type> async(F&& f, Args&&... args);template <class F, class... Args>future<typename F::result_type>future<typename result_of<F(Args...)>::type> async(launch policy, F&& f, Args&&... args);
In 32.10.9[futures.async] before paragraph 1
template <class F, class... Args>future<typename F::result_type>future<typename result_of<F(Args...)>::type> async(F&& f, Args&&... args);template <class F, class... Args>future<typename F::result_type>future<typename result_of<F(Args...)>::type> async(launch policy, F&& f, Args&&... args);...
Remarks: The first signature shall not participate in overload resolutionif
decay<F>::typeisstd::launch.
Section: 22.10.19[unord.hash]Status:NADSubmitter: Nicolai M. JosuttisOpened: 2010-02-10Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [unord.hash].
View all issues withNAD status.
Discussion:
Currently, the library lacks a convenient way to provide a hash function thatcan be used with the provided unordered containers to allow the usage of nontrivial element types.
While we can easily declare an
std::unordered_set<int>
or
std::unordered_set<std::string>
we have no easy way to declare anunordered_set for a user definedtype. IMO, this is a big obstacle to use unordered containers in practice. Notethat in Java, the wide usage ofHashMap is based on the fact that thereis always a default hash function provided.
Of course, a default hash function implies the risk to provide poor hashfunctions. But often even poor hash functions are good enough.
While I really would like to see a default hash function, I don't propose ithere because this would probably introduce a discussion that's too big for thisstate of C++0x.
However, I strongly suggest at least to provide a convenience variadic templatefunctionmake_hash<>() to allow an easy definition of a (possiblypoor) hash function.
As a consequence for a user-defined type such as
class Customer { friend class CustomerHash; private: string firstname; string lastname; long no; ... };would allow to specify:
class CustomerHash : public std::unary_function<Customer, std::size_t>{ public: std::size_t operator() (const Customer& c) const { return make_hash(c.firstname,c.lastname,c.no); }};instead of:
class CustomerHash : public std::unary_function<Customer, std::size_t>{ public: std::size_t operator() (const Customer& c) const { return std::hash<std::string>()(c.firstname) + std::hash<std::string>()(c.lastname) + std::hash<long>()(c.no); }};Note that, in principle, we can either specify that
make_hashreturns the sum of a call ofstd::hash<T>()(x)for each argumentxof typeT
or we can specify that
make_hashprovides a hash value for each argument, for which astd::hash()function is provided
with the possible note that the hash value may be poor or only a good hash valueif the ranges of all passed arguments is equally distributed.
For my convenience, I propose wording that describesthe concrete implementation.
[2010 Pittsburgh: Moved to NAD Editorial, rationale added below.]
[LEWG Kona 2017]
Recommend NAD: Feature? Needs a paper. (This isLEWG21)
Rationale:
There is no consensus to make this change at this time.
Proposed resolution:
In Function objects 22.10[function.objects]in paragraph 2 at the end of the Header<functional> synopsisinsert:
// convenience functionstemplate <class T> size_t make_hash (const T&);template <class T, class... Types> size_t make_hash (const T&, const Types&...);
In Class template hash 22.10.19[unord.hash]add:
20.7.16.1 Hash creation functions [hash.creation]
template <class T> size_t make_hash (const T& val);Returns:
hash<T>()(val);template <class T, class... Types> size_t make_hash (const T& val, const Types&... args);Returns:
hash<T>()(val) + std::make_hash(args...)
Section: 20.2.9.2[allocator.traits.types]Status:NADSubmitter: Pete BeckerOpened: 2010-02-11Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [allocator.traits.types].
View all issues withNAD status.
Duplicate of:1375
Discussion:
Addresses US-87
N2982says that containers should have a nested typedef that defines theirreference_type asvalue_type&; the previousstandard deferred to the allocator to define itsreference_type, and containers simply passed the allocator'stypedef on. This change is a mistake. Allocators should define both apointer type and areference type. That's essentialfor their original purpose, which was to make different memory modelstransparent. If an allocator defines apointer type that isn'tcompatible with a normal pointer it also has to define a correspondingreference type. For example (and please forgive a Windows-ism),if an allocator's pointer isT __far*, then it'sreference has to beT __far&. Otherwise everythingcrashes (under the hood, references are pointers and have to have thesame memory access mechanics). Extensions such as this for more generalmemory models were explicitly encouraged by C++03, and the allocator'spointer andreference typedefs were the hooks for suchextensions. Removing the allocator'sreference andconst_reference typedefs makes those extensions unimplementableand breaks existing implementations that rely on those hooks.
[2010-02-25 Alisdair adds:]
vector<bool>::referenceis a nested class, and not a typedef. Itshould be removed from the list of containers when this change is made.In general, I am uncomfortable placing this reference requirement on eachcontainer, as I would prefer to require:
is_same<Container::reference, Container::iterator::reference>This distinction is important, if we intend to support proxy iterators. Theiterator paper in the pre-Pittsburgh mailing(N3046)doesnot make this proposal, but organises clause 24 in such a way thiswill be much easier to specify.
The changes to clause 20 remain important for all the reasons Pete highlights.
[2010 Batavia]
Removedvector from list of templates that should be adjusted as of meeting outcome.
[2010 post-Batavia]
Replacedvector<bool> reference byvector reference because of misinterpreting meeting typo.Additional corrected numbering in P/R to N3225 wording.
[2010-12-06 Daniel reopens]
Unfortunately, the current P/R is defective for several reasons:
T&, namely in:Especially the second and third items are misses in the 1318 P/R,e.g. in N2723 or in C++03 these were referringto
ta value of type const T&ra value of type T&obtained by the expression*psa value of type const T&obtained by the expression*qor by conversion from a valuer
X::reference andX::const_reference, resp.None of them is referenced anywhere in the allocator requirementstable:r ands where historically needed todefine the expressionsa.address(r) anda.address(s) which are gone now,andt was needed to define the expressiona.construct(p, t) which has beenreplaced bya.construct(p,args).The easiest fix seems to be to remove all three rows from Table 43.similar to the other container types, i.e. to definestackpriority_queuequeue
reference andconst_reference now asThis would not only be an ill-formed definition (because there is no nametypedef typename allocator_traits<Allocator>::reference reference;typedef typename allocator_traits<Allocator>::const_reference const_reference;
Allocator in scope), but it would also introduce a breakage compared to C++03,where these definitions where already referring to the definition of the wrapped containers. So, the adaptor class templates should be removed from the current list.match_result::reference is currently defined asbecause it is animmutable container (And we had this definitionalready in N2723). The application of the rule would change this silently.typedef const_reference reference;
unordered_ containers is incomplete.The reason is a current inconsistency between these containers and the rest: Whilenormally the definition of the pointer types isfor the unordered containers they aretypedef typename allocator_traits<Allocator>::pointer pointer;typedef typename allocator_traits<Allocator>::const_pointer const_pointer;
These definitions arenot equivalent, because allocators are no longerrequired to define typedefstypedef typename allocator_type::pointer pointer;typedef typename allocator_type::const_pointer const_pointer;
pointer andconst_pointer, theallocator_traits were invented as a further indirection to copewith that. I.e. for the unordered containers we need to bring both the definitionof referencesand pointers in sync.[2011-02-23 Daniel updates the proposed wording with support from Pablo]
The update attempts to fix the backward-compatibility problem that we haveintroduced by ignoring the C++03 member function overloadsaddressof allocator types in C++0x completely. The resolution attempts to fix thatby adding these functions as optional members of allocators that are consideredfirst before falling back topointer_traits::pointer_to. This stillallows us to remove the unused symbolt from the table, but we adaptthe symbolsr ands to purely refer to the typenamesreference andconst_reference.
[2011-03-06 Daniel adapts numbering to N3242]
[2011-03-11 Daniel removesnoexcept specifiers fromaddress functions]
[2011-03-12 Further wording improvements by Daniel and Pablo]
[2011-03-22 Madrid]
Closed as NAD, no consensus to make a change
Rationale:
No consensus to make a change
Proposed resolution:
iter_swapSection: 24.2[iterator.synopsis]Status:NADSubmitter: Alisdair MeredithOpened: 2010-02-16Last modified: 2017-06-05
Priority:Not Prioritized
View all otherissues in [iterator.synopsis].
View all issues withNAD status.
Discussion:
Theiter_swap function template appears in the<algorithm> header, yet its main use is in building furtheralgorithms, not calling existing ones. The main clients are implementers of datastructures and their iterators, so it seems most appropriate to place thetemplate in the<iterator> header instead.
Note that this is not an issue for implementers of the standard library, as theyrarely use the standard headers directly, designing a more fine-grained set ofheaders for their own internal use. This option is not available to customersof the standard library.
Note that we cannot removeiter_swap from<algorithm>without breaking code, but there is no reason we cannot offer the samedeclaration via two standard headers. Alternatively, require<algorithm> to#include <iterator>, butintroducing the dependency on the iterator adaptors seems un-necessary.
[]
Discussed possibly moving to<utility> but don't like that. Some not seeing this as a defect, and want to keep it in<algorithm>. No one seems to feel strongly about moving to<iterator>.
[2017-02 in Kona, LEWG recommends NAD]
[2017-06-02 Issues Telecon]
Resolve as NAD
Proposed resolution:
Add the declaration ofiter_swap to the<iterator>header synopsis (24.2[iterator.synopsis]), with a note that it isdocumented in clause 26[algorithms].
...template <class T, size_t N> T* end(T (&array)[N]);// documented in 26[algorithms]template<class ForwardIterator1, class ForwardIterator2> void iter_swap(ForwardIterator1 a, ForwardIterator2 b);
Section: 23.2[container.requirements]Status:NADSubmitter: Nicolai JosuttisOpened: 2010-03-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [container.requirements].
View all issues withNAD status.
Discussion:
Abstract:
In general, it seems that in a couple of places container behavior isnot described in requirement tables although it is a general behavior.
History:
Issue676(i) added move semantics to unordered containers.For the added insert functions the Editor requested to put theirsemantic description into a requirements table rather than describingthem for each container individually. The text however was taken fromthe associative containers, where we also have the semantics for eachcontainer described. Also,1034(i) is to some extendrequesting a clarification of the requirement tables and it turned outthat in other places we have the same problem (e.g. we have no generalrequirement for type pointer and const_pointer although each containerhas them with issue1306(i)).
From my personal list of functions in requirement tablesand containers, the following types/functions are missing inrequirement tables:
pointer,const_pointer in Table 91 (container requirements)all copy constructors, copy constructors with allocator, assignment operators, and insert operators with move semantics for associative and unordered containers
ContType c1(c2&&)ContType c1(c2&&,alloc)c1 = c2&&c.insert(val&&)c.insert(pos,val&&)
As a special case, we lack the following requirements for all sequencecontainers BUT array (so special wording or a new container category isrequired):
constructor with only a size argument
ContType c(num)
copy constructor with allocator and move semantics
ContType c1(c2&&,alloc)
all constructors that insert multiple elements with additional allocator
ContType c(num, val,alloc)ContType c(beg, end,alloc)ContType c(initlist,alloc)
all resize functiuons:
c.resize(num)c.resize(num,val)
Note that we also might have to add additional requirements on otherplaces for sequence containers because having an allocator requiresadditional statements for the treatment of the allocators. E.g. swap forcontainers with allocators is not specified in any requirement table.
And finally, if we have the requirements in the requirements tables, wecan remove the corresponding descriptions for the individual container.However, note that sequence container requirements have NO complexitycolumn, so that we still need container specific descriptions for thefunctions listed there.
[2010 Batavia]
While there is consensus that further cleaning up the container requirementtables would be a good thing, there is no feeling that thismustbe done in time for 0x. The issue remains open, but Deferred.
[2011 Bloomington]
Closes as NAD. There are a number of deficiencies in the way the containerrequirements tables are presented, and the LWG welcomes further papers thatwill help clear up this presentation.
Proposed resolution:
Section: 16[library]Status:NADSubmitter: Martin SeborOpened: 2010-03-10Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Review the library portion of the spec and incorporate the newly addedcore feature Move Special Member Functions (N3044).
Rationale:
2010 Batavia: This has now been done to a large extent.
Proposed resolution:
Section: 16[library]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Addresses GB-64
There are a number of unspecified types used throughoutthe library, such as the container iterators. Many of theseunspecified types have restrictions or expectations ontheir behaviour in terms of exceptions. Are they permittedor required to use exception specifications, morespecifically the newnoexcept specification? For example,ifvector<T>::iterator is implemented as a native pointer,all its operations will have an (effective)noexceptspecification. If the implementation uses a class type toimplement this iterator, is it permitted or required tosupport that same guarantee?
[Resolution proposed by ballot comment]
Clearly state the requirements for exceptionspecifications on all unspecified library types. Forexample, all container iterator operations shouldbe conditionallynoexcept, with the conditionmatching the same operation applied to theallocator'spointer_type, a certain subset of whichare already required not to throw.
[2011-03-24 Madrid meeting]
Discussion:
Alisdair: Probably an NAD Future at least but could be NAD.
Daniel K: Approach is not consistent with what we've decided withnoexcept.Alisdair: Any objection to marking 1348 as NAD?No objections.Rationale:
Standard is correct as written
Proposed resolution:
Section: 16[library]Status:DupSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withDup status.
Duplicate of:1421
Discussion:
Addresses CH-15
Due to the new rules about implicit copy and moveconstructors some library facilities are now move-only.
[Resolution proposed by ballot comment]
Make them copyable again.
Proposed resolution:
noexceptSection: 16[library]Status:DupSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withDup status.
Duplicate of:1344
Discussion:
Addresses CH-16
Dynamic exception specifications are deprecated.Deprecated features shouldn't be used in the Standard.
[Resolution proposed by ballot comment]
Replace dynamic exception specifications withnoexcept.
Proposed resolution:
noexcept where library specification says "Throws: Nothing"Section: 16[library]Status:DupSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withDup status.
Duplicate of:1346
Discussion:
Addresses CH-17
The introduction ofnoexcept makes "Throws: Nothing" clauses looking strange.
[Resolution proposed by ballot comment]
Consider replacing "Throws: Nothing." clause bythe respective noexcept specification.
Proposed resolution:
<chrono> and<ratio> tofreestanding implementationsSection: 16.4.2.5[compliance]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [compliance].
View all issues withNAD status.
Discussion:
Addresses GB-55
The<thread> header usesduration types, found in the<chrono> header, and which rely on theratio typesdeclared in the<ratio> header.
[Extracts from lengthy Rapperswil discussion:]
There is a concern that this issue is a misunderstanding of the actualrequirements of a free-standing implementation to support the<thread>header. In general, a free-standanding implementation will provide anemptyheader, specifically so that a user can test for the absence of the_ _ STDCPP_THREADS _ _ macro. This idiom as used as there is no portable way to test for the lack of a header.
At this point, it was suggested the NB comment is trying to solve the wrong problem, and that_ _ STDCPP_THREADS _ _ should be a pre-defined macro in clause 16 that can be tested before including<thread>. That would remove the need to add additional headers to the free-standanding requirements.
It is worth noting that Japan requested<ratio> as a free-standing header in their CD1 comments. No-one seemed keen to require clocks of a free-standing implementation though.
Detlef volunteers to look at a way to redraft 17.6.1.3 p3.
[Original resolution proposed by NB comment:]
Add the
<chrono>and<ratio>headers to thefreestanding requirements.It might be necessary to address scaled-downexpectations of clock support in a freestandingenvironment, much like
<thread>.
[2011-02-25: Alberto drafts wording]
[2011-03-06: Daniel observes:]
Accepting the proposaln3256 would solve this issue.
[2011-03-24 Madrid meeting]
Freestanding no longer requires<thread> header
Rationale:
We are not adding new headers to freestanding at this point.
Proposed resolution:
Add a new entry in Table 14 — C++ library headers:
Table 14 — C++ library headers … <iterator><library_support><limits>…
Remove the last row 32.4[thread.threads]<threads>from Table 16 — C++ headers for freestanding implementations and inserta new one instead (To the editor: For the actual target Clause please see the commentin bullet 5 of this proposed resolution):
Table 16 — C++ headers for freestanding implementations Subclause Header(s) … 32.4[thread.threads] Threads<thread>?? Library support <library_support>
Modify paragraph 16.4.2.5[compliance] p. 3:
3 The supplied version of the header
<cstdlib>shall declare at least the functionsabort,atexit,at_quick_exit,exit, andquick_exit(18.5).The supplied version of the header. The other headers listed in this table shall meet the same requirements as for a hosted implementation.A program can detect the presence of standard headers not listed in Table16 using the facilities provided by the<thread>shall meet thesame requirements as for a hosted implementation or including it shall have no effect<library_support>header.
Remove the following line from the header<thread> synopsis in 32.4[thread.threads] p. 1:
namespace std {#define __STDCPP_THREADS__ __cplusplus class thread; [...]}Add a new section in Clause 18 or 20 (or any other suitable place atthe editor's discretion):
?? Library support [library.support]
The header
<library_support>defines an implementation-defined set of macros to allow a program detect the presence of standard headers in freestandingimplementations. [Note: Hosted implementations shall provide allstandard headers, thus shall provide all macros. —end note]For each standard header listed in Tables 14 (C++ library headers) and 15 (C++ headers for C library facilities)that is provided by the implementation,
<library_support>shall define a macro with name_ _HAS_XXX_HEADER_ _whereXXXis replaced by the uppercase version of the name of the header. Each such macro shall expand to the value_ _cplusplus.[Example:#include <library_support>#ifdef _ _HAS_THREADS_HEADER_ _ #include <threads> // code that exploit the presence of threads#else // fallback code that doesn't rely on threads#endif—end example]
No other standard header shall define macros with a name beginning with
_ _HAS_and ending with_HEADER_ _.
<tuple> and<utility> to freestanding implementationsSection: 16.4.2.5[compliance]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [compliance].
View all issues withNAD status.
Discussion:
Addresses GB-56
The<utility> header provides support for severalimportant C++ idioms withmove,forward andswap.Likewise,declval will be frequently used like a type trait.In order to complete cycles introduced bystd::pair, the<tuple> header should also be made available. This is asimilarly primitive set of functionality, with no dependencyof a hosted environment, but does go beyond the minimalset of functionality otherwise suggested by thefreestanding libraries.
Alternatively, split themove/forward/swap/declvalfunctions out of<utility> and into a new primitive header,requiring only that of freestanding implementation.
[Summary of Rapperswil discusions]
The preference of the meeting was to extract the rvalue-reference related utilities and swap into a freestanding header, but there was no clear preference for a name. Howard suggested simply dropping them into<type_traits> as both these utilities and type traits are used pretty much everywhere in the library implementation, it is the most convenient place to keep them (from an implementer's perspective).
Poll: Two-way: New header for forward, move, swap, move_with_noexcept and declval vs. calling out forward, move, swap, move_with_noexcept and declval as freestanding explicitly?SF new header: 4 WF new header: 3 WF call out as freestanding: 1 SF call out as freestanding: 2Alisdair: Willing to write up both solutions, give us some time to think on it.Action: Need an issue and proposed wording for GB 56 - Alisdair to draft both options as in the last poll.
[Resolution proposed by ballot comment]
Add
<utility>and<tuple>to table 15, headersrequired for a free-standing implementation.
[2010-Batavia:]
Closed as NAD, reversing the decision at Rapperswil.
The consensus was thatany freestanding implementation is going to feel compelled to offer the importantfeatures of<utility> even if we do not make them a freestandingrequirement; breaking out additional small headers may have additional costs atcompile time, and while the criticalmove-related functions could migrateto<type_traits>, the header name is far from appealing; adding thewhole of<utility> starts to drag in dependencies on<tuple>and<memory>, so we prefer to place the burden of slicing or supportingthis whole header on free-standing vendors.
Proposed resolution:
Rationale:
No consensus for a change at this time.
std::size_t in a header imply that typedef name is available to users?Section: 16.4.3[using]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses GB-58
It is not clear whether a library header specified in termsof a typedef name makes that same typedef nameavailable for use, or if it simply requires that the specifiedtype is an alias of the same type, and so the typedef namecannot be used without including the specific header thatdefines it. For example, is the following code required tobe accepted:
#include <vector>std::size_t x = 0;
Most often, this question concerns the typedefs defined inheader<cstddef>
[Resolution proposed by ballot comment:]
Add a paragraph under 16.4.3[using] clarifying whetheror not headers specified in terms ofstd::size_t canbe used to access the typedefsize_t, or whetherthe header<cstddef> must be included to reliablyuse this name.
[Batavia: NAD - see rationale below]
Proposed resolution:
Rationale:
The standard is correct as written.
rethrow_exception may introduce data racesSection: 17.9.7[propagation]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [propagation].
View all issues withNAD status.
Discussion:
Addresses GB-74
One idea for theexception_ptr type was that a reference-countedimplementation could simply 'reactivate' the sameexception object in the context of a call torethrow_exception. Such an implementation would allowthe same exception object to be active in multiple threads(such as when multiple threads join on ashared_future)and introduce potential data races in any exceptionhandler that catches exceptions by reference - notablyexisting library code written before this capability wasadded.rethrow_exception shouldalways make a copyof the target exception object.
[Resolution suggested by NB comment]
Add the following to 18.8.5, [propogation]
Throws: a copy of the exception object to which
prefers.
[2011-03-15: Anthony drafts wording]
[2011-03-23 Madrid meeting]
No consensus for a change
Rationale:
It would break too many existing implementations
Proposed resolution:
Alter 14.2[except.throw] p. 5 as follows:
5 When the thrown object is a class object, the copy/move constructor and the destructor shall be accessible,even if the copy/move operation is elided ( [class.copy]).The copy constructor shall beaccessible, and is odr-used (6.3[basic.def.odr]), even if the copy operation is elided, or a move constructor used to construct the exception object.
Alter 17.9.7[propagation] p. 7 as follows:
exception_ptr current_exception() noexcept;7Returns: An
exception_ptrobject that refers tothe currently handled exception (14.4[except.handle]) ora copy of the currently handled exception, or a nullexception_ptrobject if no exception is being handled. The referenced object shall remain valid at least as long as there is anexception_ptrobject that refers to it. If the function needs to allocate memory and the attempt fails, it returns anexception_ptrobject that refers to an instance ofbad_alloc. It is unspecified whether the return values of two successive calls tocurrent_exceptionrefer to the same exception object. [Note: That is, it is unspecified whethercurrent_exceptioncreates a new copy each time it is called. —end note ] If the attempt to copy the current exception object throws an exception, or is otherwise not possible, the function returns anexception_ptrobject that refers to the thrown exceptionif any or,if this is not possible,to an instance ofbad_exception. [Note: The copy constructor of the thrown exception may also fail, so the implementation is allowed to substitute abad_exceptionobject to avoid infinite recursion. —end note ]
Alter 17.9.7[propagation] p. 9 and add a new paragraph after p. 9 as follows:
[[noreturn]] void rethrow_exception(exception_ptr p);8Requires:
9Throws:a copy of the exception object to whichpshall not be a null pointer.prefers, or any exception thrown by the attempt to copy the exception object to whichprefers.?Synchronization: Calls torethrow_exceptiononexception_ptrobjectsthat refer to the same exception object shall appear to occur in a single total order. The completion of each call shall synchronize with (6.10.2[intro.multithread]) the next call in that total order.
Section: 19[diagnostics]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses GB-75
None of the exception types defined in clause 19 areallowed to throw an exception on copy or moveoperations, but there is no clear specification that theoperations have an exception specification to prove it.Note that the implicitly declared constructors, taking theexception specification from their base class (ultimatelystd::exception) will implicitly generate anoexceptexception specification if all of their data memberssimilarly declarenoexcept operations. As therepresentation is unspecified, we cannot assume nonthrowingoperations unless we explicitly state this as aconstraint on the implementation.
[Resolution proposed by ballot comment:]
Add a global guarantee that all exception typesdefined in clause 19 that rely on implicitly declaredoperations have a non-throwing exceptionspecification on those operations.
[2010 Batavia:]
This is addressed by the current words in 18.8.1 [exception], p2
Each standard library class
Tthat derives from classexceptionshall have a publicly accessible copy constructor and a publicly accessible copyassignment operator that do not exit with an exception.
Proposed resolution:
Section: 22.2[utility]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility].
View all issues withNAD status.
Discussion:
Addresses GB-79
The library provides several traits mechanisms intended acustomization points for users. Typically, they aredeclared in headers that are growing quite large. This isnot a problem for standard library vendors, who canmanage their internal file structure to avoid largedependencies, but can be a problem for end users whohave no option but to include these large headers.
[2010 Rapperswil]
There was no enthusiasm for touchingchar_traits orregex_traits.Consensus to moveiterator_traits,allocator_traitsandpointer_traits to their own respective headers once wording supplied.
[2010 Rapperswil]
After some discussion, consensus is that moving these features into separateheaders does not buy much in practice, as the larger headers will inevitablybe included anyway. Resolve as NAD.
[Resolution proposed in ballot comment]
Move the following traits classes into their ownheaders, and require the existing header to#include the traits header to support backwardscompatibility:
iterator_traits (plus the iterator tag-types)allocator_traitspointer_traitschar_traitsregex_traits
[2010 Batavia:]
Closed as NAD with the rationale below.
Rationale:
This suggest is not a defect, as the likely benefit is small, if any,compared to the cost of not just implementating the feature, but alsoexplaining/teaching it.
Proposed resolution:
Section: 16.4.4.2[utility.arg.requirements]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility.arg.requirements].
View all issues withNAD status.
Discussion:
Addresses US-85
20.2.1 Table 34 "MoveConstructible requirements" says"Note: rv remains a valid object. Its state is unspecified".Some components give stronger guarantees. Forexample, moved-fromshared_ptrs are guaranteedempty(20.9.11.2.1/25).In general, what the standard really should say (preferablyas a global blanket statement) is that moved-from objectscan be destroyed and can be the destination of anassignment. Anything else is radioactive. For example,containers can be "emptier than empty". This needs to beexplicit and required generally.
Note: The last time that one of us mentioned "emptierthan empty" (i.e. containers missing sentinel nodes, etc.)the objection was that containers can store sentinel nodesinside themselves in order to avoid dynamically allocatingthem. This is unacceptable because
(a) it forces existing implementations (i.e. Dinkumware's, Microsoft's,IBM's, etc.) to change for no good reason (i.e. permitting moreoperations on moved-from objects), and
(b) it invalidates end-iterators when swapping containers. (The WorkingPaper currently permits end-iterator invalidation, which weconsider to be wrong, but that's a separate argument. Inany event,mandating end-iterator invalidation is verydifferent from permitting it.)
[Resolution proposed in ballot comment]
State as a general requirement that moved-fromobjects can be destroyed and can be thedestination of an assignment. Any other use isundefined behavior.
Proposed resolution:
Resolved byN3241
reference_type should not have been removed from theallocator requirementsSection: 16.4.4.6[allocator.requirements]Status:DupSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withDup status.
Duplicate of:1318
Discussion:
Addresses US-87
reference_type should not have been removed from theallocator requirements. Even if it is always the same asvalue_type&, it is an important customization point forextensions and future features.
Proposed resolution:
In [allocator.requirements] Table 42 - Allocotor Requirements, Add a row (aftervalue_type) with columns:
Expression:
X::reference_type
Return type:T&
Assertion/note...: (empty)
Default:T&
[allocator.traits]:
namespace std { template <class Alloc> struct allocator_traits { typedef Alloc allocator_type; typedef typename Alloc::value_type value_type; typedefsee below pointer; typedefsee below const_pointer; typedefsee below void_pointer; typedefsee below const_void_pointer;typedef value_type& reference_type;Addreference_type toallocator_traits template, defaulted tovalue_type&.
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
Addresses US-88
Allocator interface is not backward compatible.
[Resolution proposed by ballot comment]
See Appendix 1 - Additional Details
[2010-10-24 Daniel adds:]
n3165 provides an alternative resolution.
[2910 Batavia:]
Closed as NAD - withdrawn by the submitter.
Proposed resolution:
Seen3165
Rationale:
Withdrawn by the submitter.
Section: 21.3.8[meta.rel]Status:NAD EditorialSubmitter: JapanOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [meta.rel].
View all otherissues in [meta.rel].
View all issues withNAD Editorial status.
Discussion:
Addresses JP-32
Representations of reference link are not unified.Most reference links to clause (table) number, say X, arein the form "Clause X" ("Table X") capitalized, andsubsection Y.Y.Y is referenced with its number only in theform "Y.Y.Y". Whether they are parenthesized or notdepends on the context.However there are some notations "(Z)" consisting of onlya number Z in parentheses to confer Clause or Tablenumber Z.
Proposed resolution:
Change "(10)" to "(Clause 10)".
regex should support allocatorsSection: 28.6.7[re.regex]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2020-11-09
Priority:Not Prioritized
View all otherissues in [re.regex].
View all issues withNAD status.
Duplicate of:1451
Discussion:
Addresses US-104, US-141
std::basic_regex should have an allocator for all thereasons that astd::string does. For example, I can useboost::interprocess to put astring orvectorin shared memory, but not aregex.
[Resolution proposed by ballot comment]
Add allocators to regexes
[2010-10-24 Daniel adds:]
Acceptingn3171 would solve this issue.
[2011-03-22 Madrid]
Close 1396 as NAD Future.
[LEWG Kona 2017]
Recommend Open: Covered in LEWG9, P0269, which is in wording review.
[2020-07-17; status changed to Tentatively NAD in issue processing telecon]
P0269R0 has been superseded by P1294R0.Requested LEWG to confirm which version they forwarded to LWG.In any case, this is a feature request, not a defect, and will be dealt with as a proposal not an issue.
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Rationale:
No consensus for a change at this time
Proposed resolution:
<functional> headerSection: 22.10[function.objects]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [function.objects].
View all issues withNAD status.
Discussion:
Addresses GB-96
The function templateshash,less andequal_toare important customization points for user-defined types tobe supported by several standard containers. These areaccessed through the<functional> header which hasgrown significantly larger in C++0x, exposing many morefacilities than a user is likely to need through there ownheader, simply to declare the necessary specialization.There should be a smaller header available for users tomake the necessary customization.
[Resolution proposed by ballot comment]
Provide a tiny forwarding header for importantfunctor types in the<functional> header that auser may want to specialize. This should containthe template declaration forequal_to,hash andless.
[Rapperswill summary]
Alisdair: Would recommend NAD unless someone takes the issue.
Daniel: Volunteers to write a paper for this.
[2010-11-07 Daniel provides a paper available on the Batavia document list]
[2010 Batavia:]
Closed as NAD - the consensus was that forwarding headers such as<iosfwd> do not bring the expected benefits, and arenot widely used (to the surprise of some active users in the room!).Without real experience reporting a benefit, there is no further interestin pursuing this issue as an extension - hence NAD rather than NAD Future.
Rationale:
No consensus to make a change
Proposed resolution:
See paper "Forwarding<functional> functor templates"on the Batavia LWG document list
Section: 20.3.2.2[util.smartptr.shared]Status:NADSubmitter: JapanOpened: 2010-08-25Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [util.smartptr.shared].
View all issues withNAD status.
Discussion:
Addresses JP-5
Hash support based on ownership sharing should besupplied forshared_ptr andweak_ptr.For twoshared_ptr objectsp andq, two distinctequivalence relations can be defined. One is based onequivalence of pointer values, which is derived from theexpressionp.get() == q.get() (hereafter calledaddress basedequivalence relation), the other is based onequivalence of ownership sharing, which is derived fromthe expression!p.owner_before(q) && !q.owner_before(p)(hereafter calledownership-based equivalence relation).These two equivalence relations are independent ingeneral. For example, ashared_ptr object created by theconstructor of the signatureshared_ptr(shared_ptr<U>const &, T *) could reveal a difference between these tworelations. Therefore, hash support based on eachequivalence relation should be supplied forshared_ptr.However, while the standard library provides the hashsupport for address-based one (20.9.11.6 paragraph 2), itlacks the hash support for ownership-based one. Inaddition, associative containers work well in combinationwith theshared_ptr's ownership-based comparison butunordered associative containers don't. This isinconsistent.
For the case ofweak_ptr, hash support for the ownership basedequivalence relation can be safely defined onweak_ptrs, and even on expired ones. The absence ofhash support for the ownership-based equivalencerelation is fatal, especially for expiredweak_ptrs. And theabsence of such hash support precludes some quiteeffective use-cases, e.g. erasing theunordered_map entryof an expiredweak_ptr key from a customized deletersupplied toshared_ptrs.
Hash support for the ownership-based equivalencerelation cannot be provided by any user-defined mannerbecause information about ownership sharing is notavailable to users at all. Therefore, the only way to provideownership-based hash support is to offer it intrusively bythe standard library.
As far as we know, such hash support is implementable.Typical implementation of such hash function could returnthe hash value of the pointer of the counter object that isinternally managed byshared_ptr andweak_ptr.
[2010 Rapperswil:]
No consensus to make this change at this time.
[LEWG Kona 2017]
Recommend NAD: Needs a paper. Feature. Exposing an implementation detail (indirectly observable via hash).
Proposed resolution:
Add the following non-static member functions toshared_ptr andweak_ptr class template;
Update [util.smartptr.shared], 20.9.11.2 paragraph 1
namespace std{template<class T> class shared_ptr {public:...size_t owner_hash() const;...};}Update [util.smartptr.weak], 20.9.11.3 paragraph 1
namespace std{template<class T> class weak_ptr {public:...size_t owner_hash() const;...};}These functions satisfy the followingrequirements. Letp andq be objects of eithershared_ptr orweak_ptr,H be a hypotheticalfunction object type that satisfies the hashrequirements ([hash.requirements], 20.2.4) andh be an object of thetypeH. The expressionp.owner_hash() behavesas if it were equivalent to the expressionh(p). Inaddition,h(p) == h(q) must becometrue ifp andq share ownership.
monotonic_clockSection: 99 [time.clock.monotonic]Status:DupSubmitter: DINOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [time.clock.monotonic].
View all issues withDup status.
Duplicate of:1410
Discussion:
Addresses DE-20
The library componentmonotonic_clock is conditionallysupported, but no compile-time flag exists that allowsuser-code to query its existence. Further-on there exist noportable means to simulate such a query. (To do so, usercode would be required to add types to namespacestd::chrono.)
Proposed resolution:
Provide a compile-time flag (preferably a macro)that can be used to query the existence ofmonotonic_clock.
high_resolution_clock is a distinct type or a typedefSection: 30.7.8[time.clock.hires]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses US-112
What it means forhigh_resolution_clock to be a synonymis undefined. If it may or may not be a typedef, thencertain classes of programs become unportable.
[Resolution proposed in ballot comment]
Require that it be a distinct class type.
[2010 Batavia]
This is not a defect. Threre are a number of places in the standard wherewe allow implentations to choose their preferred technique, the most obviousexample being theiterator/const_iterator types ofset.
Typically, this means it is not portable to declare function overloads that differonly in their use of these types.
Proposed resolution:
Section: 23.2.2[container.requirements.general]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [container.requirements.general].
View all otherissues in [container.requirements.general].
View all issues withNAD Editorial status.
Discussion:
Requirements on iterators swapping allegiance woulddisallow the small-string optimization.
[Resolved in Rapperswil by paper N3108.]
Proposed resolution:
Add an exclusion forbasic_string to the sentencebeginning “Every iterator referring to anelement...”. Add a sentence to 21.4.6.8/2 sayingthat iterators and references to string elementsremain valid, but it is not specified whether theyrefer to the same string or the other string.
forward_list::erase_after should return an iteratorSection: 23.3.7[forward.list]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [forward.list].
View all issues withNAD Editorial status.
Discussion:
Addresses US-117
forward_list::erase_after should return an iterator.
[Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.]
Proposed resolution:
See Appendix 1 - Additional Details
random_shuffle andshuffle should have consistent signaturesSection: 26.7.13[alg.random.shuffle]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [alg.random.shuffle].
View all issues withDup status.
Duplicate of:1432
Discussion:
Addresses GB-119
The functionsrandom_shuffle andshuffle both takearguments providing a source of randomness, but onetake its argument by rvalue reference, and the otherrequires an lvalue reference. The technical merits of whichform of argument passing should be settled for thisspecific case, and a single preferred form usedconsistently.
Proposed resolution:
[DEPENDS ON WHETHER RVALUE ORLVALUE REFERENCE IS THE PREFERREDFORM]
min/max functions replace variadic arguments byinitializer_list argumentSection: 26.8.9[alg.min.max]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [alg.min.max].
View all otherissues in [alg.min.max].
View all issues withNAD Editorial status.
Discussion:
Addresses US-122
It was the LWG's intent in Pittsburgh that N2772 be applied to the WP.
[Resolved in Rapperswil by paper N3106.]
Proposed resolution:
Apply N2772 to the WP.
Section: 32[thread]Status:NAD EditorialSubmitter: CanadaOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread].
View all issues withNAD Editorial status.
Duplicate of:1443
Discussion:
Addresses CA-9, GB-122
[CA-9:]
Imposed happens-before edges should be insynchronizes-with
Each use of the words "happens-before" should bereplaced with the words "synchronizes-with" in thefollowing sentences:
27.2.3p2
30.3.1.2p6
30.3.1.5p7
30.6.4p7
30.6.9p5
30.6.10.1p23
Rationale: Happens-before is defined in 1.10p11 in a waythat (deliberately) does not make it explicitly transitivelyclosed. Adding edges to happens-before directly, as in27.2.3p2 etc., does not provide transitivity withsequenced-before or any other existing happens-beforeedge. This lack of transitivity seems to be unintentional.
[GB-122]
At various points in the standard new edges are added tohappens-before, for example 27.2.3:2 adds happens-before edges betweenwrites and reads from a stream:
If one thread makes a library call a that writes a value to astream and, as a result, another thread reads this value from thestream through a library call b such that this does not result in adata race, then a happens before b.
Happens-before is defined in 1.10:11 in a deliberate way that makes itnot explicitly transitively closed. Adding edges to happens-beforedirectly, as in 27.2.3:2, does not provide transitivity withsequenced-before or any other existing happens-before edge. This lackof transitivity seems to be unintentional. In order to achievetransitivity we suggest each edge be added tointer-thread-happens-before as a synchronises-with edge (as perconversation with Hans Boehm). In the standard, each use of the words"happens-before" should be replaced with the words "synchronizes-with"in the following sentences:
27.2.3:2,30.3.1.2:6,30.3.1.5:7,30.6.4:7,30.6.9:5,30.6.10.1:23
Proposed resolution:
[Beman provided specific wording for the proposed resolution.]
Change 27.2.3 Thread Safety [iostreams.threadsafety] paragraph 2:
If one thread makes a library calla that writes a value to a stream and, as a result, another thread reads this value from the stream through a library callb such that this does not result in a data race, thenahappens beforesynchronizes withb.
Change 30.3.1.2 thread constructors [thread.thread.constr] paragraph 6:
Synchronization: The invocation of the constructorhappens beforesynchronizes with the invocation of the copy off.
Change 30.3.1.5 thread members [thread.thread.member] paragraph 7:
Synchronization: The completion of the thread represented by*thishappens beforesynchronizes with (1.10)join()returnsreturning. [ Note: Operations on*this are not synchronized. --end note ]
Change 30.6.4 Associated asynchronous state [futures.state] paragraph 7:
Calls to functions that successfully set the stored result of an associated asynchronous state synchronize with (1.10) calls to functions successfully detecting the ready state resulting from that setting. The storage of the result (whether normal or exceptional) into the associated asynchronous statehappens beforesynchronizes with (1.10) that stateisbeing set to ready.
Change 30.6.9 Function template async [futures.async] paragraph 5:
Synchronization: the invocation ofasynchappens beforesynchronizes with (1.10) the invocation off. [Note: thisstatement applies even when the corresponding future object is moved to another thread. —endnote ] If the invocation is not deferred, a call to a waiting function on an asynchronous return objectthat shares the associated asynchronous state created by this async call shall block until the associatedthread has completed. If the invocation is not deferred, thejoin() on the created threadhappens beforesynchronizes with (1.10) the first function that successfully detects the ready status of the associated asynchronous state returns or before the function that gives up the last reference to the associated asynchronous state returns, whichever happens first. If the invocation is deferred, the completion of the invocation of the deferred functionhappens beforesynchronizes with the calls to the waiting functions return.
Change 30.6.10.1 packaged_task member functions [futures.task.members] paragraph 23:
Synchronization: a successful call tooperator() synchronizes with (1.10) a call to any member function of afuture,shared_future, oratomic_future object that shares the associated asynchronous state of*this. The completion of the invocation of the stored task and the storage of the result (whether normal or exceptional) into the associated asynchronous statehappens beforesynchronizes with (1.10) the stateisbeing set to ready. [ Note:operator() synchronizes and serializes with other functions through the associated asynchronous state. —end note ]
Section: 32[thread]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread].
View all issues withDup status.
Duplicate of:1442
Discussion:
Addresses GB-122
At various points in the standard new edges are added tohappens-before, for example 27.2.3:2 adds happens-before edges betweenwrites and reads from a stream:
If one thread makes a library call a that writes a value to astream and, as a result, another thread reads this value from thestream through a library call b such that this does not result in adata race, then a happens before b.
Happens-before is defined in 1.10:11 in a deliberate way that makes itnot explicitly transitively closed. Adding edges to happens-beforedirectly, as in 27.2.3:2, does not provide transitivity withsequenced-before or any other existing happens-before edge. This lackof transitivity seems to be unintentional. In order to achievetransitivity we suggest each edge be added tointer-thread-happens-before as a synchronises-with edge (as perconversation with Hans Boehm). In the standard, each use of the words"happens-before" should be replaced with the words "synchronizes-with"in the following sentences:
27.2.3:2,30.3.1.2:6,30.3.1.5:7,30.6.4:7,30.6.9:5,30.6.10.1:23
Proposed resolution:
Request the concurrency working group todetermine if changes are needed
OFF_T is not definedSection: 31.5.3.3[fpos.operations]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [fpos.operations].
View all issues withDup status.
Duplicate of:1414
Discussion:
Addresses GB-123
Several rows in table 124 specify a Return type of'OFF_T', which does not appear to be a type defined inthis standard.
Proposed resolution:
Resolve outstanding references to the removed type 'OFF_T'.
Section: 31.7[iostream.format]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iostream.format].
View all issues withNAD status.
Discussion:
Addresses US-138
For istreams and ostreams, the move-constructor doesnot move-construct, the move-assignment operator doesnot move-assign, and the swap function does not swapbecause these operations do not manage therdbuf()pointer. Useful applications of these operations areprevented both by their incorrect semantics and becausethey are protected.
[Resolution proposed by ballot comment:]
In short: reverse the resolution of issue 900, thenchange the semantics to move and swap therdbuf() pointer. Add a new protected constructorthat takes an rvalue reference to a stream and apointer to a streambuf, a new protectedassign()operator that takes the same arguments, and anew protectedpartial_swap() function that doesn'tswaprdbuf().See Appendix 1 - Additional Details
[2010-10-24 Daniel adds:]
Acceptingn3179 would solve this issue.
[2010-11 Batavia]
Closed as NAD.
The Library Working Group reviewedn3179 and concluded that this change alone was not sufficient, as it would require changes to some of the derived stream types in the library. The preference is to not make such a broad fix, and retain the current semantics. This is closed as NAD rather than NAD future as it will be difficult to rename the new functions introduced in the C++0x revision of the standard at a later date.
Proposed resolution:
regex should support allocatorsSection: 28.6.7[re.regex]Status:DupSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.regex].
View all issues withDup status.
Duplicate of:1396
Discussion:
Addresses US-141
std::basic_regex should have an allocator for all thereasons that astd::string does. For example, I can useboost::interprocess to put astring orvector in shared memory, but not a regex.
Proposed resolution:
Add allocators to regexes; see paperN3171in the pre-Batavia mailing.
Section: 28.6.9.5[re.results.acc]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [re.results.acc].
View all issues withNAD status.
Discussion:
Addresses GB-125
The term "target sequence" is not defined (28.6.9.5[re.results.acc] p. 2).
[Resolution proposed by ballot comment:]
Replace "target sequence" with "string being searched/matched"
[2010-11-01 Daniel comments:]
The proposed resolution looks incomplete to me, there are more normativeusages of the termtarget sequence in clause 28, e.g.28.6.11.2[re.tokiter] p. 7.
[2011-03-22 Madrid meeting: Moved to NAD]
Rationale:
Standard is correct as written
Proposed resolution:
Wording changes are against N3126. They are intended not to conflict with the wording changessuggested byn3158.
Change 28.6.9.5[re.results.acc] p. 2 as indicated:
difference_type position(size_type sub = 0) const;2Returns: The distance from the start of the
target sequencestring being matched to(*this)[sub].first.
Section: 32.5[atomics]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withDup status.
Duplicate of:1455
Discussion:
Addresses GB-128
WG14 has made some late changes to their specificationof atomics, and care should be taken to ensure that weretain a common subset of language/library syntax todeclare headers that are portable to both languages.Ideally, such headers would not require users to definetheir own macros, especially not macros that map tokeywords (which remains undefined behaviour)
[Resolution proposed by ballot comment]
Depends on result of the review of WG14 work,which is expected to be out to ballot during thetime wg21 is resolving its own ballot comments.Liaison may also want to file comments in WG14to ensure compatibity from both sides.
Proposed resolution:
atomic_ typedefsSection: 32.5[atomics]Status:NADSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withNAD status.
Discussion:
Addresses GB-129
Table 143 lists the typedefs for various atomic typescorresponding to the various standard integer typedefs,such asatomic_int_least8_t forint_least8_t, andatomic_uint_fast64_t foruint_fast64_t. However, there areno atomic typedefs corresponding to the fixed-sizestandard typedefsint8_t,int16_t, and so forth.
[2010-10-24 Daniel adds:]
Acceptingn3164 would solve this issue.
[2011-02-15 Anthony corrects numbering/naming for N3225, Howard suggests improvement for the positionof '(optional)', Daniel reorders rows in harmony to remaining entries and suggests specific optionalitycomments:]
[2011-02-16 Reflector discussion]
Moved to Tentatively Ready after 5 votes.
[2011-03-16: Hans reopenes and comments]
WG14 briefly discussed LWG 1456. It turns out that they had previously made a conscious decision not to make a similar change. If C++ would deviate, this would introduce a C divergence.
We should reopen the issue and, in my opinion, probably resolve it as NAD instead. This is in a part of the standard that is there mostly for C compatibility, so introducing divergence here seems to make no sense.[2011-03-24 Madrid]
Rationale:
WG14 does not require these typedefs, and we see no reason to be gratuitously different.
Proposed resolution:
Add the following entries to table 143:
Table 146 — atomic<inttypes.h>typedefsAtomic typedef <inttypes.h>type......atomic_intmax_tintmax_tatomic_uintmax_tuintmax_tatomic_int8_t//iffint8_tis providedint8_tatomic_uint8_t//iffuint8_tis provideduint8_tatomic_int16_t//iffint16_tis providedint16_tatomic_uint16_t//iffuint16_tis provideduint16_tatomic_int32_t//iffint32_tis providedint32_tatomic_uint32_t//iffuint32_tis provideduint32_tatomic_int64_t//iffint64_tis providedint64_tatomic_uint64_t//iffuint64_tis provideduint64_t
Section: 32.5.4[atomics.order]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.order].
View all otherissues in [atomics.order].
View all issues withDup status.
Duplicate of:1459
Discussion:
Addresses GB-131
32.5.5[atomics.lockfree] p.8 states:
An atomic store shall only store a value that has been computedfrom constants and program input values by a finite sequence ofprogram evaluations, such that each evaluation observes the valuesof variables as computed by the last prior assignment in thesequence.
... but 6.10.1[intro.execution] p.13 states:
If A is not sequenced before B and B is not sequenced before A,then A and B are unsequenced. [Note: The execution of unsequencedevaluations can overlap. —end note ]
Overlapping executions can make it impossible to construct the sequencedescribed in 32.5.5[atomics.lockfree] p.8. We are not sure of the intention here and do notoffer a suggestion for change, but note that 32.5.5[atomics.lockfree] p.8 is the conditionthat prevents out-of-thin-air reads.
Proposed resolution:
Request the concurrency working group todetermine if changes are needed. Considerchanging the use of "sequence" in 32.5.5[atomics.lockfree]
ATOMIC_* macros asSTD_ATOMIC_*Section: 32.5[atomics]Status:NADSubmitter: CanadaOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics].
View all issues withNAD status.
Discussion:
Addresses CA-1
AllATOMIC_... macros should be prefixed withSTD_ asinSTD_ATOMIC_... to indicate they areSTD macros asother standard macros. The rationale that they all seem too long seems weak.
[2011-03-06: Daniel adapts suggested wording to N3242 and comments]
I suggest to declare this issue as NAD. Reason for this suggestion is, thatC1x is currently going to suggest exactly the same macros as additions toheader<stdatomic.h>, therefore C++0x should not define awhole new set. I'm making this suggestion with the understanding thatC1x is intending to keep in sync in this regard. For example, the mostrecent draft of C1x does contain the macroATOMIC_ADDRESS_LOCK_FREEwhich has recently been removed from the C++ working draft.
[2011-03-24]
Rationale:
C is not going to change the name of these macros, and it isimportant they have the same name for compatibility
Proposed resolution:
Change sub-clause 32.5.2[atomics.syn] as indicated:
[..]//[atomics.lockfree], lock-free property#defineSTD_ATOMIC_CHAR_LOCK_FREEunspecified#defineSTD_ATOMIC_CHAR16_T_LOCK_FREEunspecified#defineSTD_ATOMIC_CHAR32_T_LOCK_FREEunspecified#defineSTD_ATOMIC_WCHAR_T_LOCK_FREEunspecified#defineSTD_ATOMIC_SHORT_LOCK_FREEunspecified#defineSTD_ATOMIC_INT_LOCK_FREEunspecified#defineSTD_ATOMIC_LONG_LOCK_FREEunspecified#defineSTD_ATOMIC_LLONG_LOCK_FREEunspecified//[atomics.types.operations.req], operations on atomic types#defineSTD_ATOMIC_VAR_INIT(value)see below[..]
Change 32.5.5[atomics.lockfree] p. 1 as indicated:
#defineSTD_ATOMIC_CHAR_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_CHAR16_T_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_CHAR32_T_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_WCHAR_T_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_SHORT_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_INT_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_LONG_LOCK_FREEimplementation-defined#defineSTD_ATOMIC_LLONG_LOCK_FREEimplementation-defined1 The
STD_ATOMIC_..._LOCK_FREEmacros indicate the lock-free property of the corresponding atomic types, [..]
Change 99 [atomics.types.operations.req] p. 6 as indicated:
#defineSTD_ATOMIC_VAR_INIT(value)see below5Remarks: The macro expands to a token sequence suitable for constant initialization an atomic variable of static storage duration of a type that is initialization-compatiblewithvalue. [Note: This operation may need to initialize locks. —end note ] Concurrent access to the variable being initialized, even via an atomic operation, constitutes a data race. [Example:
atomic<int> v =STD_ATOMIC_VAR_INIT(5);—end example ]
Change 32.5.10[atomics.flag] p. 1+4 as indicated:
namespace std { [..] #defineSTD_ATOMIC_FLAG_INITsee below}[..]4 The macro
STD_ATOMIC_FLAG_INITshall be defined in such a way that it can be used to initialize an object oftypeatomic_flagto the clear state. For a static-duration object, that initialization shall be static. It isunspecified whether an unitializedatomic_flagobject has an initial state of set or clear. [Example:atomic_flag guard =STD_ATOMIC_FLAG_INIT;—end example ]
atomic_boolSection: 99 [atomics.types.integral]Status:DupSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [atomics.types.integral].
View all issues withDup status.
Duplicate of:1462
Discussion:
Addresses US-157
atomic_bool has avolatile assignment operator but not anon-volatile operator. The other integral types have both.
Proposed resolution:
Add a non-volatile assignment operator toatomic_bool.
Section: 32.5.8.2[atomics.types.operations]Status:DupSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withDup status.
Duplicate of:1474
Discussion:
Addresses US-165
According to 32.5.8.2[atomics.types.operations] p. 23:
“is the same that same as that of” is not grammatical (and is not clear)
Proposed resolution:
Section: 32.5.8.2[atomics.types.operations]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withNAD Editorial status.
Discussion:
Addresses US-168
32.5.8.2[atomics.types.operations] around p. 4: The definition of the default constructor needs exposition.
Proposed resolution:
Insert a new general prototype description following the current 32.5.8.2[atomics.types.operations] p. 3 as indicated:
3 [Note: Many operations are volatile-qualified. The “volatile as device register” semantics have not changedin the standard. This qualification means that volatility is preserved when applying these operations tovolatile objects. It does not mean that operations on non-volatile objects become volatile. Thus, volatilequalified operations on non-volatile objects may be merged under some conditions. --end note]
A::A() = default;?Effects: Leaves the atomic object in an uninitialized state.[Note: These semantics ensure compatiblity with
C. --end note]
constexpr A::A(C desired);[..]
atomic_initSection: 32.5.8.2[atomics.types.operations]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withNAD Editorial status.
Discussion:
Addresses US-171
As of 32.5.8.2[atomics.types.operations] p. 7:
Theatomic_init definition "Non-atomically assigns thevalue" is not quite correct, as theatomic_init purpose isinitialization.Proposed resolution:
Change 32.5.8.2[atomics.types.operations] p. 7 as indicated:
void atomic_init(volatile A *object, C desired);void atomic_init(A *object, C desired);7Effects:
Non-atomically assigns the value desired toInitializes*object*objectwith valuedesired. Concurrent access from another thread, even via an atomic operation, constitutes a data race.[Note: This function should only be applied to objects that have been default constructed. These semantics ensurecompatibility withC. —end note]
Section: 32.5.8.2[atomics.types.operations]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withNAD status.
Discussion:
Addresses US-172
As of 32.5.8.2[atomics.types.operations] p. 9, 13, 17, 20:
The order specifications are incomplete because the non-_explicitfunctions do not have such parameters.Add a new sentence: "If the program does not specify an order, it shall bememory_order_seq_cst." Or perhaps: "The non-_explicitnon-member functions shall affect memory as though they were _explicit withmemory_order_seq_cst."[2010 Batavia]
The Concurrency subgroup reviewed this, and deemed it NAD according to32.5.8.2[atomics.types.operations] paragraph 2, bullet 4.
Rationale:
The working paper is correct as written.
Proposed resolution:
void atomic_store(volatile A* object, C desired);void atomic_store(A* object, C desired);void atomic_store_explicit(volatile A *object, C desired, memory_order order);void atomic_store_explicit(A* object, C desired, memory_order order);void A::store(C desired, memory_order order = memory_order_seq_cst) volatile;void A::store(C desired, memory_order order = memory_order_seq_cst);8Requires: The order argument shall not be
9Effects: Atomically replaces the value pointed to bymemory_order_consume,memory_order_acquire, normemory_order_acq_rel.objector by this with the value ofdesired.Memory is affected according to the value oforder.If the program does not specify an order, it shall bememory_order_seq_cst.
C atomic_load(const volatile A* object);C atomic_load(const A* object);C atomic_load_explicit(const volatile A* object, memory_order);C atomic_load_explicit(const A* object, memory_order);C A::load(memory_order order = memory_order_seq_cst) const volatile;C A::load(memory_order order = memory_order_seq_cst) const;12Requires: The order argument shall not be
13Effects: Memory is affected according to the value ofmemory_order_releasenormemory_order_acq_rel.order.If the program does not specify an order, it shall bememory_order_seq_cst.14Returns: Atomically returns the value pointed to byobjector bythis.
C atomic_exchange(volatile A* object, C desired);C atomic_exchange(A* object, C desired);C atomic_exchange_explicit(volatile A* object, C desired, memory_order);C atomic_exchange_explicit(A* object, C desired, memory_order);C A::exchange(C desired, memory_order order = memory_order_seq_cst) volatile;C A::exchange(C desired, memory_order order = memory_order_seq_cst);17Effects: Atomically replaces the value pointed to by
18Returns: Atomically returns the value pointed to byobjector bythiswithdesired. Memoryis affected according to the value oforder. These operations are atomic read-modify-write operations(1.10).If the program does not specify an order, it shall bememory_order_seq_cst.objector bythisimmediately before the effects.
bool atomic_compare_exchange_weak(volatile A* object, C * expected, C desired);bool atomic_compare_exchange_weak(A* object, C * expected, C desired);bool atomic_compare_exchange_strong(volatile A* object, C * expected, C desired);bool atomic_compare_exchange_strong(A* object, C * expected, C desired);bool atomic_compare_exchange_weak_explicit(volatile A* object, C * expected, C desired, memory_order success, memory_order failure);bool atomic_compare_exchange_weak_explicit(A* object, C * expected, C desired, memory_order success, memory_order failure);bool atomic_compare_exchange_strong_explicit(volatile A* object, C * expected, C desired, memory_order success, memory_order failure);bool atomic_compare_exchange_strong_explicit(A* object, C * expected, C desired, memory_order success, memory_order failure);bool A::compare_exchange_weak(C & expected, C desired, memory_order success, memory_order failure) volatile;bool A::compare_exchange_weak(C & expected, C desired, memory_order success, memory_order failure);bool A::compare_exchange_strong(C & expected, C desired, memory_order success, memory_order failure) volatile;bool A::compare_exchange_strong(C & expected, C desired, memory_order success, memory_order failure);bool A::compare_exchange_weak(C & expected, C desired, memory_order order = memory_order_seq_cst) volatile;bool A::compare_exchange_weak(C & expected, C desired, memory_order order = memory_order_seq_cst);bool A::compare_exchange_strong(C & expected, C desired, memory_order order = memory_order_seq_cst) volatile;bool A::compare_exchange_strong(C & expected, C desired, memory_order order = memory_order_seq_cst);19Requires: The
20Effects: Atomically, compares the contents of the memory pointed to byfailureargument shall not bememory_order_releasenormemory_order_acq_rel.Thefailureargument shall be no stronger than the success argument.objector bythisfor equalitywith that inexpected, and if true, replaces the contents of the memory pointed to byobjector bythiswith that indesired, and if false, updates the contents of the memory in expected with thecontents of the memory pointed to byobjector bythis. Further, if the comparison is true, memoryis affected according to the value ofsuccess, and if the comparison is false, memory is affectedaccording to the value offailure. When only onememory_orderargument is supplied, the value ofsuccessisorder, and the value offailureisorderexcept that a value ofmemory_order_acq_relshall be replaced by the valuememory_order_acquireand a value ofmemory_order_releaseshall be replaced by the valuememory_order_relaxed.If the program does not specify an order, it shall bememory_order_seq_cst. If the operation returnstrue, these operations are atomic read-modify-write operations (1.10). Otherwise, these operations are atomic load operations.[..]
Section: 32.5.8.2[atomics.types.operations]Status:DupSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withDup status.
Duplicate of:1474
Discussion:
Addresses CH-23
32.5.8.2[atomics.types.operations] p. 23: The first sentence has non-English syntax.
[Resolution proposed in ballot comment:]
Change to "The weak compare-and-exchangeoperations may fail spuriously, that is, return falsewhile leaving the contents of memory pointed toby expected unchanged."
[Daniel translates NB comment in a proposed resolution]
Change 32.5.8.2[atomics.types.operations] p. 23 as indicated:
23Remark:
When a compare-and-exchange is in a loop, the weak version will yield better performance on someplatforms. When a weak compare-and-exchange would require a loop and a strong one would not, thestrong one is preferable. —end note ]The weak compare-and-exchange operations may fail spuriously, that is, return false whileleaving the contents of memory pointed to byThe weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to byexpectedbefore the operation is the same that sameas that of theobjectand the same as that ofexpectedafter the operationexpectedunchanged.. [Note: This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g., loadlocked store-conditional machines. A consequence of spurious failure is that nearly all uses of weak compare-and-exchange will be in a loop.
[See1474(i) for the proposed resolution]
Proposed resolution:
Section: 32.5.8.2[atomics.types.operations]Status:DupSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withDup status.
Duplicate of:1474
Discussion:
Addresses US-177
The first sentence of this paragraph doesn't make sense.
[Resolution proposed in ballot comment]
Figure out what it's supposed to say, and say it.
Proposed resolution:
Section: 32.5.8.2[atomics.types.operations]Status:DupSubmitter: BSIOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withDup status.
Duplicate of:1474
Discussion:
Addresses GB-135
The first sentence of 32.5.8.2[atomics.types.operations] p.23 was changed by n2992 butnow makes no sense: "that is, returnfalse while leavingthe contents of memory pointed to byexpected before theoperation is the same that same as that of theobject andthe same as that ofexpected after the operation."There's a minor editorial difference between n2992 ("isthat same as that" vs "is the same that same as that") butneither version makes sense.Also, the remark talks about "object" which shouldprobably be "object orthis" to cover the member functionswhich have no object parameter.
[Resolution proposed in ballot comment:]
Fix the Remark to say whatever was intended.
Proposed resolution:
__STDCPP_THREADS spellingSection: 32.4[thread.threads]Status:NAD EditorialSubmitter: DINOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Addresses DE-23
Predefined macros usually start and end with twounderscores, see 16.8 and FDIS 29124 = WG21 N3060clause 7.__STDCPP_THREADS should blend in.
[Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.]
Proposed resolution:
Change the macro name to__STDCPP_THREADS__.
thread::id specificationSection: 32.4.3.2[thread.thread.id]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.thread.id].
View all issues withNAD status.
Discussion:
Addresses US-184
It is unclear when athread::id ceases to be meaningful.The sentence "The library may reuse the value of athread::id of a terminated thread that can no longer bejoined." implies that some terminated threads can bejoined. It says nothing about detached threads.
[Resolution proposed by ballot comment:]
Require a unique
thread::idfor every thread that is(1) detached and not terminated or (2) has an associatedstd::threadobject.
[2010-11-22 Howard Hinnant observes]
A thread can either be running or terminated. Additionally a thread can be joined, detached, or neither. These combine into the five possible states shown in this table:
| Running | Terminated | |
|---|---|---|
| Neither joined nor detached | shall not reuse id | shall not reuse id |
| detached | shall not reuse id | may reuse id |
| joined | impossible state | may reuse id |
Only if a thread is neither joined nor detached can it be joined. Or said differently, if a thread has already been joined or detached, then it can not be joined. The sentence:
The library may reuse the value of a
thread::idof a terminated thread that can no longer be joined.
precisely defines the two states shown in the above table where a thread::id may be reused.
The following program illustrates all of the possibilities:
#include <mutex>#include <thread>#include <iostream>#include <chrono>std::mutex mut;void f(){ std::lock_guard<std::mutex> _(mut); std::cout << "f id = " << std::this_thread::get_id() << " terminating\n";}void g(){ std::lock_guard<std::mutex> _(mut); std::cout << "g id = " << std::this_thread::get_id() << " terminating\n";}int main(){ std::cout << "main id = " << std::this_thread::get_id() << "\n"; std::thread t1(f); std::thread(g).detach(); std::this_thread::sleep_for(std::chrono::seconds(1)); std::cout << "g's thread::id can be reused here because g has terminated and is detached.\n"; std::cout << "f's thread::id can't be reused here because f has terminated but is still joinable.\n"; std::cout << "f id = " << t1.get_id() << "\n"; t1.join(); std::cout << "f's thread::id can be reused here because f has terminated and is joined.\n"; std::cout << "f id = " << t1.get_id() << "\n";}main id = 0x7fff71197ca0f id = 0x100381000 terminatingg id = 0x100581000 terminatingg's thread::id can be reused here because g has terminated and is detached.f's thread::id can't be reused here because f has terminated but is still joinable.f id = 0x100381000f's thread::id can be reused here because f has terminated and is joined.f id = 0x0[2011-02-11 Reflector discussion]
Moved to Tentatively NAD after 5 votes.
Proposed resolution:
this_thread::get_id() underspecified for detached threadSection: 32.4.5[thread.thread.this]Status:NADSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.thread.this].
View all issues withNAD status.
Discussion:
Addresses CH-24
What would be the valuethis_thread::get_id() when called from a detached thread?
[Resolution proposed by ballot comment:]
Add some text to clarify thatget_id() still returns the same value even after detaching.
[2010-11-22 Howard Hinnant observes]
32.4.5[thread.thread.this]/1 contains the following sentence describingthis_thread::get_id():
... No other thread of execution shall have this id and this thread of execution shall always have this id.
I don't object to adding "even if detached" to this sentence, but it seems unnecessary to me. "Always" means always.
[2011-02-11 Reflector discussion]
Moved to Tentatively NAD after 5 votes.
Proposed resolution:
unlock functions and unlock mutex requirements are inconsistentSection: 32.6[thread.mutex]Status:NAD EditorialSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.mutex].
View all issues withNAD Editorial status.
Discussion:
Addresses CH-26
Specifications ofunlock member functions andunlockmutex requirements are inconsistent wrt to exceptions andpre- and postconditions.
[Resolution proposed by ballot comment:]
unlockshould specifiy the precondition that thecurrent thread "owns the lock", this will make callswithout holding the locks "undefined behavior".unlockin [mutex.requirements] should either benoexcept(true)or be allowed to throwsystem_errorlikeunique_lock::unlock, or the lattershould benothrow(true)and have the preconditionowns == true.Furthermoreunique_lock's postcondition is wrongin the case of a recursive mutex whereownsmight stay true, when it is not the lastunlockneeded to be called.
Proposed resolution:
wait_for return value insufficientSection: 32.7[thread.condition]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition].
View all issues withNAD Editorial status.
Discussion:
Addresses US-191
The condition variablewait_for returningcv_status is insufficient.
[Resolution proposed by ballot comment:]
Return a duration of timeout remaining instead.See Appendix 1 ofn3141 - Additional Details, p. 211
Proposed resolution:
condition_variable not implementableSection: 32.7.4[thread.condition.condvar]Status:NAD EditorialSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvar].
View all issues withNAD Editorial status.
Discussion:
Addresses CH-28
Requiringwait_until makes it impossible to implementcondition_variable correctly using respective objectsprovided by the operating system (i.e. implementing thenative_handle() function) on many platforms (e.g. POSIX,Windows, MacOS X) or using the same object as for thecondition variable proposed for C.
[Resolution proposed by ballot comment:]
Remove the
wait_untilfunctions or make them at least conditionally supported.
Proposed resolution:
Section: 32.7[thread.condition]Status:NADSubmitter: INCITSOpened: 2010-08-25Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [thread.condition].
View all issues withNAD status.
Discussion:
Addresses US-193
Condition variables preclude a wakeup optimization.
[Resolution proposed by ballot comment:]
Change condition_variable to allow suchoptimization. See Appendix 1 - Additional Details
[2010 Batavia]
The Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x.
Rationale:
The LWG does not wish to make the change at this time.
[LEWG Kona 2017]
Recommend NAD: (N4618 numbering) 30.5.1[thread.condition.condvar] p10.3 allows spurious wakeups. This issue is out of date.
[2017-03-01, Kona]
SG1 recommends: Close as NAD
The approach suggested there raises all sorts of issues aboutthread_locals, etc. It's probably way too late to change this anyway, but this would have required a careful paper.Proposed resolution:
native_handle()Section: 32.7.5[thread.condition.condvarany]Status:NAD EditorialSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.condition.condvarany].
View all issues withNAD Editorial status.
Discussion:
Addresses CH-32
Given that the lock type can be something the underlyingdoesn't know 'native_handle()' is probablyunimplementable on essentially all platforms.
[Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.]
Proposed resolution:
Consider the removal of 'native_handle()'.
Section: 32.10.5[futures.state]Status:NAD EditorialSubmitter: SwitzerlandOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.state].
View all issues withNAD Editorial status.
Discussion:
Addresses CH-35
The term "associated asynchronous state" is long, ugly and misleading terminology. When introduced we agreed upon that we should come up with a better name. Here it is: "liaison state". Since the state is hidden and provides synchronization of afuture with its correspondingpromise, we believe "liaison state" is a much better and shorter name (liaison ~ (typically hidden) relationship)
[Resolution proposed by ballot comment:]
Change all occurrences of "associatedasynchronous state" to "liaison state".
Proposed resolution:
The project editor may supply a more appopriate term, or use "liaison state",at his own discretion.
set_exception with a null pointerSection: 32.10.6[futures.promise]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.promise].
View all issues withNAD Editorial status.
Discussion:
Addresses US-198
promise::set_exception can be called with a null pointer,but none of the descriptions of theget() functions for thethree types of futures say what happens for this case.
[Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.]
Proposed resolution:
Add the following sentence to the end of30.6.5/22: The behavior of a program that callsset_exception with a null pointer is undefined.
future::get more than onceSection: 99 [futures.atomic_future]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.atomic_future].
View all issues withNAD Editorial status.
Discussion:
Addresses US-202
The note in this paragraph says "unlikefuture, callinggetmore than once on the sameatomic_future object is welldefined and produces the result again." There is nothinginfuture that says anything negative about callinggetmore than once.
[Resolution proposed by ballot comment:]
Remove this note, or add words to therequirements for future that reflect what this notesays.
Proposed resolution:
atomic_future operations unlessvalid()Section: 99 [futures.atomic_future]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.atomic_future].
View all issues withNAD Editorial status.
Discussion:
Addresses US-203
Bothfuture andshared_future specify that calling mostmember functions on an object for whichvalid() == falseproduces undefined behavior. There is no such statementforatomic_future.
[Resolution proposed by ballot comment:]
Add a new paragraph after 99 [futures.atomic_future]/2 with the same words as [futures.shared_future]/3.
[2010-11-02 Daniel translates proposed changes into specific deltas and comments:]
While applying the wording, I notice that [futures.shared_future]/3 doesspeak of the move-assignment operator, andnot of the copy-assignment operator.
atomic_futureobviously needs this to be true for the copy-assignment operator,but I strongly assume thatshared_futureneeds to mention both special memberassignment operators in this paragraph. To keep this consistent, the following P/R alsoprovides wording to fix the corresponding location forshared_future.
Proposed resolution:
3 The effect of calling any member function other than the destructor, the copy-assignment operator, the move-assignment operator, or
valid()on ashared_futureobject for whichvalid() == falseis undefined.
? The effect of calling any member function other than the destructor, the copy-assignment operator, or
valid()on aatomic_futureobject for whichvalid() == falseis undefined.
atomic_futureSection: 99 [futures.atomic_future]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [futures.atomic_future].
View all issues withNAD Editorial status.
Discussion:
Addresses US-204
According to the definition ofatomic_future, all membersofatomic_future are synchronizing except constructors.However, it would probably be appropriate for a moveconstructor to be synchronizing on the source object. Ifnot, the postconditions on paragraphs 7-8, might not besatisfied. This may be applicable if a collection of futuresare being doled out to a set of threads that process theirvalue.
[Resolution proposed by ballot comment:]
Make the move constructor for atomic future lockthe source
Proposed resolution:
Section: 32.10.9[futures.async]Status:NAD EditorialSubmitter: INCITSOpened: 2010-08-25Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [futures.async].
View all otherissues in [futures.async].
View all issues withNAD Editorial status.
Discussion:
Addresses US-205
32.10.9[futures.async] p. 3: The third sentence says "If the invocation is not deferred, a call to a waiting function on an asynchronous return object that shares the associated asynchronous statecreated by thisasync call shall block until the associatedthread has completed." The next sentence says "If theinvocation is not deferred, thejoin() on the createdthread..." Blocking until a thread completes is notnecessarily a join.
[Resolution proposed by ballot comment:]
Decide whether the requirement is to block untilfinished or to call join, and rewrite to match.
Proposed resolution:
emplace broken for associative containersSection: 23.2.8[unord.req]Status:NADSubmitter: Pablo HalpernOpened: 2010-10-18Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
The current definition ofemplace(args) for associative containers asdescribed in Table 99 is:
Requires:
Effects: Inserts aTshall be constructible fromargs.Tobjecttconstructed withstd::forward<Args>(args)...if and only if there is no elementin the container with key equivalent to the key oft. Theboolcomponent of the returnedpairistrueif and only if theinsertion takes place, and the iterator component of thepairpoints to the element with key equivalent to the key oft.
There is similar language in Table 100 for unordered associative containers.
The first issue is editorial:T should bevalue_type throughoutboth tables.The major issue is that, if the container ismap,multimap,unordered_map, orunordered_multimap, then the only way toconstruct an object ofvalue_type is to supply exactly two argumentsforKey andValue, apair<Key,Value>, or apiecewise_construct_t followed by twotuples. The originalemplace() proposal would have allowed you to specify aKeyvalue followed by any number of constructor arguments forValue.When we removed the variadic constructor topair, this ability wentaway. I don't think that was deliberate.Fixing this is non-trivial, I think. I think thatemplace() formapandmultimap need several overloads: one for each overloaded constructor inpair<Key,Value>, and one for theemplace(Key, valueargs...) case.And it probably needs some SFINAE meta-programming to ensure that the last casedoesn't override any of the other ones. Alternatively, one could say thatthere are exactly two cases:emplace(args) wherepair<Key,Value>is constructible fromargs, andemplace(args) whereKey isconstructible form the firstarg andValue is constructible from therest.Alternatively, the status quo is to usepiecewise_construct_t if you want toconstruct an object.[2010 Batavia:]
N3178 was looked at in session and moved to NAD.
Proposed resolution:
hash should bestd qualified for unordered containerSection: 23.5[unord]Status:NADSubmitter: Pete BeckerOpened: 2011-02-07Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [unord].
View all issues withNAD status.
Discussion:
Tom Plum pointed out to me that there's an apparent inconsistency in thestd:: qualification of template names in the unordered containers:
template <class Key, class T, class Hash = hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<std::pair<const Key, T> > > class unordered_map;
Is there a reason that hash is not qualified withstd::? TR1 alsodoes not usestd:: here.
[2011-02-07 Chris Jefferson adds:]
I assumed (I might be wrong) it is becausehash is designed to be acustomisation point, likeswap.
[2011-02-07 Howard Hinnant adds:]
I think this is incorrect. We meanstd::hash, though clientsare free to specializestd::hash on user-defined types. With thepossible exception ofbegin/end (which I'm not sure ifwe've settled that),swap is the only intended customization point (look up a function by ADL) in thestd:: lib.
[2011-02-24 Chris Jefferson adds:]
I recommend NAD, due to 16.4.2.2[contents] p3:
Whenever a name
xdefined in the standard library is mentioned, the namexis assumed to be fully qualifiedas::std::x, unless explicitly described otherwise. For example, if the Effects section for library functionFis described as calling library functionG, the function::std::Gis meant.
[2011-02-25 Reflector discussion]
Moved to Tentatively NAD after 5 votes.
Proposed resolution:
istream >> char andeofbitSection: 31.7.5.2[istream]Status:NADSubmitter: Howard HinnantOpened: 2011-02-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream].
View all issues withNAD status.
Discussion:
The question is: When a single character is extracted from anistream usingoperator>>, doeseofbit get set if this is the last character extracted from the stream? The current standard is at best ambiguous on the subject. 31.7.5.2[istream]/p3 describes all extraction operations with:
3 If
rdbuf()->sbumpc()orrdbuf()->sgetc()returnstraits::eof(), then the input function, except as explicitly noted otherwise, completes its actions and doessetstate(eofbit), which may throwios_base::failure(31.5.4.4[iostate.flags]), before returning.
And [istream::extractors]/p12 in describingoperator>>(basic_istream<charT,traits>& in, charT& c); offers no further clarification:
12Effects: Behaves like a formatted input member (as described in [istream.formatted.reqmts]) of
in. After asentryobject is constructed a character is extracted fromin, if one is available, and stored inc. Otherwise, the function callsin.setstate(failbit).
I coded it one way in libc++, and g++ coded it another way. Chris Jefferson noted that some boost code was sensitive to the difference and fails for libc++. Therefore I believe that it is very important that we specify this extraction operator in enough detail that both vendors and clients know what behavior is required and expected.
Here is a brief code example demonstrating the issue:
#include <sstream>#include <cassert>int main(){ std::istringstream ss("1"); char t; ss >> t; assert(!ss.eof());};For every type capable of reading this istringstream butchar,ss.eof() will be true after the extraction (bool,int,double, etc.). So for consistency's sake we might want to havechar behave the same way as other built-in types.
However Jean-Marc Bourguet offers this counter example code using an interactive stream. He argues that settingeof inhibits reading the next line:
#include <iostream>int main(){ char c; std::cin >> std::noskipws; std::cout << "First line: "; while (std::cin >> c) { if (c == '\n') { std::cout << "Next line: "; } }}As these two code examples demonstrate, whether or noteofbit gets set is an observable difference and it is impacting real-world code. I feel it is critical that we clearly and unambiguously choose one behavior or the other. I am proposing wording for both behaviors and ask the LWG to choose one (and only one!).
Wording for settingeof bit:
Modify [istream::extractors]/p12 as follows:
12Effects: Behaves like a formatted input member (as described in [istream.formatted.reqmts]) of
in. After asentryobject is constructed a character is extracted fromin, if one is available, and stored inc.Otherwise, the function callsIf a character is extracted and it is the last character in the pending sequence, the function callsin.setstate(failbit).in.setstate(eofbit). If a character is not extracted the function callsin.setstate(failbit | eofbit).
Wording for not settingeof bit:
12Effects: Behaves like a formatted input member (as described in [istream.formatted.reqmts]) of
in. After asentryobject is constructed a character is extracted fromin, if one is available, and stored inwithc. Otherwise, the function callsin.setstate(failbit).in.rdbuf()->sbumpc(). Iftraits::eof()is returned, the function callsin.setstate(failbit | eofbit). Otherwise the return value is converted to typecharTand storedinc.
[2011-02-27: Jean-Marc Bourguet comments]
Just for completeness: it [the counter example] doesn't inhibit to read the next line, it inhibits the prompt to be put at the appropriate time.
More information to take into account when deciding:
if I'm reading correctly the section to get boolean values whenboolalpha is set, there we mandate thateof isn't set if trying to read past the end of the pending sequence wasn't needed to determine the result.
see also the behaviour ofgetline (which isn't a formatted input function but won't seteof if it occurs just after the delimiter)
if I'm reading the C standard correctlyscanf("%c") wouldn't setfeof either in that situation.
[2011-02-28: Martin Sebor comments]
[Responds to bullet 1 of Jean-Marc's list]
Yes, this matches the stdcxx test suite fornum_get andtime_getbut notmoney_get when the currency symbol is last. I don't seewhere in the locale.money.get.virtuals section we specify whethereofbit is or isn't set and when.
char extractor to be consistent weshould also fix all the others extractors and manipulators thataren't consistent (includingstd::get_money andstd::get_time).[2011-03-24 Madrid meeting]
Dietmar convinced Howard, that the standard does already say the right words
Rationale:
Reading the last character does not set eofbit and the standard says so already
Proposed resolution:
std{in,out,err} should be usable as field namesSection: 31.13[c.files]Status:NADSubmitter: Jeffrey YasskinOpened: 2011-03-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [c.files].
View all issues withNAD status.
Discussion:
People often define structs and classes with fields namedstdin,stdout, orstderr. According to 31.13[c.files], though, these are macros.
__stdoutpor(&__sF[1]), etc depending on__DARWIN_UNIX03. It's possible toallow their use while, as far as I can see, only requiring minorchanges to various libc's, so C++1x should allow it.[2011 Bloomington]
Closed as NAD. This is an extension request that has been an issue for over 20 years.Supporting the extension would place a burden on the underlying C library that we maynot be in a position to influence.
Proposed resolution:
This wording is relative to the FDIS.
In 31.13[c.files] add "stderr", "stdin", and "stdout" to a new Values section in Table134 — Header<cstdio> synopsis:
134 — Header <cstdio>synopsisType Name(s) Macros: BUFSIZFOPEN_MAXSEEK_CURTMP_MAX_IONBFstdoutEOFL_tmpnamSEEK_END_IOFBFstderrFILENAME_MAXNULL <cstdio>SEEK_SET_IOLBFstdinTypes: FILEfpos_tsize_t <cstdio>Functions: … Values: stderrstdinstdout
Add a new paragraph after paragraph 2 as indicated:
2 Calls to the function
? The macrostmpnamwith an argument ofNULLmay introduce a data race (17.6.5.9) with other calls totmpnamwith an argument ofNULL.
See also: ISO C 7.9, Amendment 1 4.6.2.stderr,stdin, andstdoutshall expand tostderr,stdin, andstdout, respectively. [Note: This allows uses of#ifdefto detect their presence, while allowing code in other scopes to use them as identifiers. —end note]
In C.8[diff.library] add "stderr", "stdin", and "stdout" to Table 150 — Standard values:
Table 150 — Standard values CHAR_BITFLT_DIGINT_MINMB_LEN_MAX… … … … SHRT_MIN… … … stderr… … … stdin… … … stdout… … … UCHAR_MAX…
shared_future(future<R>&&) should be allowed to throwSection: 32.10.8[futures.shared.future]Status:NADSubmitter: Peter SommerladOpened: 2011-04-04Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [futures.shared.future].
View all issues withNAD status.
Discussion:
Requiring the constructorshared_future(future<R>&& rhs) not to throwis a pessimisation of the case where a future is returned from a call toasync(function,launch::deferred) and possible other cases.
shared_future from that future will require moreinfrastructure, like space for the value of typeR, anexception_ptr, and a synchronizedreference counter for theshared_future's instances.Enforcing the constructorshared_future(future<R>&& rhs) not to throw,implies that any implementation offuture will need to pre-allocate space forshared_future'sinfrastructure, that also requires an operating system resource for synchronization, regardlessif is ever needed.All this came up when discussing D/N3267 and Concurrency Working Group decided that the constructorshared_future(future<R>&& rhs) should be allowed to throw.[2011 Bloomington]
Closed as NAD. Rationale to follow by email...
Proposed resolution:
Apply the proposed resolution ofn3269
unique_ptr<T[]>(nullptr_t) missingnoexceptSection: 20.3.1.4[unique.ptr.runtime]Status:NAD EditorialSubmitter: Howard Hinnant, Paolo CarliniOpened: 2011-05-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [unique.ptr.runtime].
View all issues withNAD Editorial status.
Discussion:
The synopsis in 20.3.1.3[unique.ptr.single] specifies:
constexpr unique_ptr(nullptr_t) noexcept
which looks correct to me. However the corresponding constructor in 20.3.1.4[unique.ptr.runtime] is missingnoexcept:
constexpr unique_ptr(nullptr_t) : unique_ptr() { }[Bloomington, 2011]
Closed as NAD Editorial.
Proposed resolution:
This wording is relative to the FDIS.
Modify the synopsis in 20.3.1.4[unique.ptr.runtime]:
namespace std { template <class T, class D> class unique_ptr<T[], D> { public: typedef see below pointer; typedef T element_type; typedef D deleter_type; // 20.7.1.3.1, constructors constexpr unique_ptr() noexcept; […] constexpr unique_ptr(nullptr_t)noexcept : unique_ptr() { } […] };}std::pair not C++03-compatible with defaulted copy c'torSection: 22.3.2[pairs.pair]Status:NADSubmitter: Daniel KrüglerOpened: 2011-06-18Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [pairs.pair].
View all otherissues in [pairs.pair].
View all issues withNAD status.
Discussion:
The specification of the copy semantics of the C++03 version ofstd::pairis defined by the class synopsis in [lib.pairs]:
template <class T1, class T2>struct pair { typedef T1 first_type; typedef T2 second_type; T1 first; T2 second; pair(); pair(const T1& x, const T2& y); template<class U, class V> pair(const pair<U, V> &p);};The effect of this specification is, that the copy constructor is compiler-declaredwith the proper form depending on the contained member types. In particular, theinstantiation ofpair is well-formed with an element type that has acopy constructor with non-const first parameter type like specialzations ofauto_ptror any user-defined type like the following one:
struct A { A(A&){}};In contrast to container types which requireCopyConstructible value types, the C++03pair does support these, albeit unusual, element types.
std::pair specification does specify the same semantics by defaulting the copy and move constructor in 22.3.2[pairs.pair]:template <class T1, class T2>struct pair { typedef T1 first_type; typedef T2 second_type; T1 first; T2 second;pair(const pair&) = default;pair(pair&&) = default; pair(); […]};But according to the current core rules this makes the instantiation of e.g.std::pair<A, int>ill-formed, because of theconst mismatch of the compiler-declared form of the copy constructorwith that of the defaulted declaration.
pair.pair specializations, but this would still not allow to copy them by the copy constructor.pair specializations and of these members. This would support all element types as it did in C++03, but all copy/move members would be non-trivial.pair, butstill keep the allocator support with the effect of removing all declarations of the specialcopy/move members. User code that needs to usetuple instead. But this would be a ratherdrastic step requiring further corrections of the draft, e.g. a change of the signature of the algorithmminmax (not the overload with theinitializer_list) with a different return type.This problem doesnot extend as backward-compatibility problem totuple, because the TR1 specification did explicitly declare copy constructor and copy assignment operator via the "normal" form:
tuple(const tuple&);tuple& operator=(const tuple&);
[Bloomington, 2011]
Closed as NAD.
This is an unfortunate change of behavior between C++03 and C++11, but is consistent withtuple. There is no desire to go to lengths supporting types likeauto_ptr now that rvalue references are in the language.
There may be an issue for Core/EWG to look at, so that some simple=default syntax could be used that would do the right thing. If such a facility became availabile, LWG might revisit this issue.
Proposed resolution:
Section: 19.2[std.exceptions], 19.5.8[syserr.syserr], 31.5.2.2.1[ios.failure]Status:NADSubmitter: Eelis van der WeegenOpened: 2011-08-16Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [std.exceptions].
View all issues withNAD status.
Discussion:
This is an extension issue for LWG to add constructor overloads that take astring by an rvalue reference in order to move the string into the exception.
[2012, Kona]
Move to NAD.
This was discussed during C++11 standardization, and deemed (at the time) to be a conformingextension that vendors are free to add, but there seemed no need to call it out in the standard.Since then it has been noted that the rvalue-reference overloads do not give you the move-semanticguarantee the proposer is thought to be looking for, as in order to meet the requirements thatcopy constructors do not throw (for standard exceptions) the exceptions that store strings mustactually store a reference-counted immutable string, rather than anstd::string internally.Therefore, an rvalue-reference overload is going to have to allocate memory in exactly the sameway as copying from aconst string& argument.
Proposed resolution:
pow() overloadsSection: 29.7[c.math]Status:NADSubmitter: Steve ClamageOpened: 2011-08-29Last modified: 2016-01-28
Priority:3
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
LWG issue550(i) removed the functions:
float pow(float, int);double pow(double, int);long double pow(long double, int);
from header<cmath>. This change does not seem to be mentioned in Annex C, C.2.14.
N3290 29.7[c.math]/p11 says:
Moreover, there shall be additional overloads sufficient to ensure:
- If any argument corresponding to a
doubleparameter has typelong double, then all arguments corresponding todoubleparameters are effectively cast tolong double.- Otherwise, if any argument corresponding to a
doubleparameter has typedoubleor an integer type, then all arguments corresponding todoubleparameters are effectively cast todouble.- Otherwise, all arguments corresponding to
doubleparameters are effectively cast tofloat.From C99 7.12.7.4 we have:
double pow(double, double);29.7[c.math]/p11/b2 says that if the client calls
pow(2.0f, 2), then theintfor second argument causes the following effective call to be made:pow(static_cast<double>(2.0f), static_cast<double>(2)) -> doubleThe first sentence of p11 implies that this is done by supplying the following additional overload:
double pow(float, int);If the client calls
pow(2.0, 2), then the same reasoning (b2 again) implies the following additional overload:double pow(double, int);If the client calls
pow(2.0l, 2), then b1 implies the following additional overload:long double pow(long double, int);In all, p11 implies hundreds (perhaps thousands?) of extra overloads. All but one of which is a superset of the overloads required by C++98/03 (that one being
In practice, at least some vendors implement p11 by using templated overloads as opposed to ordinary overloads.pow(float, int)which had its return type changed fromfloattodouble).
Steve Clamage:
Thanks. I didn't see that those extra overloads were actually implied by p11, despite the first sentence. Without examples, the point is a bit subtle (at least for me).
[2015-05-05 Lenexa: Move to NAD]
Billy: I believe this is NAD.
STL: Oh, Steve himself agrees.
Wakely: The issue marked as NAD will be sufficient.
STL: Yes, we should get rid of this.
Billy: I don't see any minutes from Issaquah.
Marshall: Since Steve agrees, does anyone object to marking as NAD?
Nope.
Proposed resolution:
<algorithm>Section: 26[algorithms]Status:NADSubmitter: Nicolai JosuttisOpened: 2011-09-02Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [algorithms].
View all otherissues in [algorithms].
View all issues withNAD status.
Discussion:
Thepartition_point() algorithm is specified with:
Complexity:O(log(last - first)) applications of
pred.
While this is correct, it gives the impression that this is a logarithmic algorithm.But unless random access iterators are used it is not logarithmic because for advancing the iterator we have last-first steps, which means that the complexity becomes linear here.
Shouldn't we clarify the complexity here to something like:Complexity: logarithmic for random-access iterators and linear otherwise (in any caseO(log(last - first)) applications of
pred).
Or should we even requireO(log(last - first) for random-access iterators only because for other iterators just iterating over all elements, while callingpred for each element, might often be faster.
Daniel Krügler:
I agree that especially this description is a bit misleading. I'm notconvinced that this is a real defect, because the whole bunch oftemplates within
I would like to see a wording improvement, but I would rather think thatthe complexity of the predicate should be mentioned first (as in otheralgorithms) and that a non-normative note could be added forspecifically this algorithm to point out that this does not implya logarithmic traversal complexity. The note could give more details,by explicity pointing out the linear traversal complexity fornon-random-Access iterators.<algorithm>document the complexity solely ofapplications* of predicates, assignment, or swaps, but never thecomplexity of traversal operations (e.g. increment or iteratorequality tests). This means, the standard is consistent for thisfunction template, even though it could say a bit more.
Howard Hinnant:
If we are going to make such improvements, they should be made across the board in
<algorithm>, not to justpartition_point. For example all 4 algorithms in 26.8.4[alg.binary.search] have the same issue, and have since C++98.stable_partitionandinplace_mergeshould be inspected as well.Perhaps a new paragraph in 26.1[algorithms.general], similar to p12 would be a better place to address this issue.
[2012, Kona]
Move to NAD.
There was some concern that the issue, if it were to be addressed, is much larger thanthe couple of algorithms called out here, and applies across the whole library. Thereis no interest in looking at this or similar issues without a paper addressing the wholelibrary. In fairness to anyone considering writing such a paper, it should be notedthat there was not much interest in such a paper in the group, although no strong oppositioneither.
Proposed resolution:
basic_string use ofcharT*Section: 27.4.3[basic.string]Status:NADSubmitter: Howard HinnantOpened: 2011-09-11Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD status.
Discussion:
For C++11 we gave all of the containers, including basic_string new generalized pointer types:
typedef typename allocator_traits<Allocator>::pointer pointer:typedef typename allocator_traits<Allocator>::const_pointer const_pointer;
However, the constructors, assignment, and member functions still traffic exclusively in terms ofconst charT*, for example:
basic_string(const charT* s, const Allocator& a = Allocator());
Was this an oversight? Did we mean instead:
basic_string(const_pointer s, const Allocator& a = Allocator());
Rationale:
It's intentional.char_traits assumes that all elements ofa string can be accessed indirect on plain pointers. Sobasic_string doesn't support allocators with fancy pointers or references. And we meant to do that.
basic_string(const charT* s, const Allocator& a = Allocator());
This constructor allows us to create abasic_string object from a string literal. If we were to change the pointer type, that would no longer be possible.
allocator::pointer type.Now what about the return value of 'c_str()', should that return anallocator::pointer?Again, the answer (I believe) is 'no' because this is the function that allows us to pass the string's contents to a legacy/OS 'C' API. It is deliberately returning a raw pointer for a reason.There was an issue wherevector::data was changed to return anallocator::pointerto the internal buffer, and this was changed back exactly because this was intended to support passing to external APIs.Do we have a use-case where the pointer type of internal data structures of our containers (notablybasic_string andvector) need to be exposed through a public API? All my current use-cases forallocator::pointer are specific to the implementation of containers themselves.Proposed resolution:
Section: 32.6.4.2[thread.mutex.requirements.mutex]Status:NADSubmitter: Pete BeckerOpened: 2011-10-17Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.mutex.requirements.mutex].
View all issues withNAD status.
Discussion:
32.6.4.2[thread.mutex.requirements.mutex]/6, fourth bullet requires the return type ofm.lock() to bevoid.
[2012, Kona]
This does not specify a concept; it specifies requirements on the concrete mutex types.
Proposed resolution:
Section: 24.3[iterator.requirements]Status:NADSubmitter: Jeffrey YasskinOpened: 2011-11-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [iterator.requirements].
View all issues withNAD status.
Discussion:
Many iterators guarantee that references and pointers returned fromtheir methods will outlive the iterator itself. Other useful iteratorscan't guarantee this, leading to the rule in 24.3[iterator.requirements] p9 that "Destruction of an iterator may invalidate pointers and references previously obtained from that iterator."
Some algorithms can take advantage of long-lived references byreturning them, while they can adapt to short-lived references byreturning by value instead. However, there doesn't seem to be a way inthe standard to distinguish between these two types of iterators.TheForwardIterator requirements come close by saying "Ifa andb areboth dereferenceable, thena == b if and only if*a and*b are boundto the same object." (24.3.5.5[forward.iterators] p6) However, there are somesubtle ways to satisfy this rule and still return a short-lived reference, meaning algorithms can't be guaranteed thatforward_iterator_tag will imply long-lived references.On the other hand, defect198(i), which added the invalidation wordingto iterator.requirements.general, refers to iterators with short-lived references being used as arguments to reverse_iterator, which requiresBidirectionalIterators. IfForwardIterator required long-lived references, this would be impossible.EitherForwardIterator should be clarified to require long-livedreferences, or a new category should be added that does.See also the discussion around c++std-lib-31477.Daniel: Related to this issue is that when applyingN3066we unintentionally lost some forward iterator requirements from C++03, where we had the post-conditionsa == X(a) ofX(a), andu == a of any copy operation froma tou. This wording must be restored as well.[2012, Kona]
Move to NAD.
This issue affects only Input Iterators, as all other categories are required to returna native reference, and are not (currently) allowed to return proxies. The issue withInput Iterators is known, and has been present since the original standard. Any changein this regard would be an extension requiring a more substantial paper than treatmentas a simple issue.
Proposed resolution:
final to non-polymorphic components?Section: 16.4.6[conforming]Status:NADSubmitter: Daniel KrüglerOpened: 2011-11-30Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [conforming].
View all issues withNAD status.
Discussion:
Related to LWG2112(i) the question has been raised whether a library implementationmay declarenon-polymorphic library components, such as class templatestd::vector orstd::basic_string,asfinal class types.
finalcould allow them to provide compile-modes that are intentionally restrictive to the advantage of user codethat want to be alterted about that. Any implementation that would be concerned about user complaints would not take advantage of this feature anyway.If agreement exists that such implementation freedom would be useful, wording likeAn implementation may declare additional non-virtual member function signatures within a class as
final.
or
An implementation may declare additional class without virtual member function signatures as
final.
should be added to 16.4.6[conforming] with corresponding exceptions of these rules (e.g.iterator,unary_function, orpair).
An implementation shall not declare any class or any member function signature as
final.
[2012, Kona]
Move to NAD.
Unless the library uses the keywordfinal in a specification, the user clearly hasfreedom to derive from such a class, and so equally clearly, the library vendor does not havefreedom to add afinal overrider or class attribute. Howard observed there may besome wiggle-room with 'unspecified types' such as those returned frombind expressions,or iterators, but we did not see a need to further clarify the issue. Note that, for example,avector::iterator may be implemented as a raw pointer, so users cannot generallyassume the ability to derive from unspecified library types.
Proposed resolution:
app for string streamsSection: 31.8.5.2[stringstream.cons]Status:NADSubmitter: Nicolai JosuttisOpened: 2012-01-15Last modified: 2018-06-07
Priority:3
View all issues withNAD status.
Discussion:
This issue was raised while discussing issue1448(i).
Note the following program:string s("s1: 123456789");ostringstream s1(s, ios_base::out|ios_base::app);s1 << "hello";cout << s1.str() << endl;With g++4.x it prints:
s1: 123456789hello
With VisualC++10 it prints:
hello23456789
From my intuitive understanding the flag "app" should result in the output of g++4.x.I also would read that from [ios::openmode] claiming:
appseek to end before each write
However in issue1448(i) P.J.Plauger comments:
I think we should say nothing special about
appat construction time (thus leaving the write pointer at the beginning of the buffer).Leave implementers wiggle room to ensure subsequent append writes as they see fit, but don't change existing rules for initial seekposition.
Note that the flagate on both platforms appends "hello" tos.
[2018-06; Rapperswil Wednesday evening]
MC: shouldn't this be Open?
BO: I think we changed it to do the same thing as gcc
JM: NAD - gcc is right
ACTION close as NAD, noting that gcc is right
Proposed resolution:
Section: 29.5.3.2[rand.req.seedseq]Status:NADSubmitter: Alberto Ganesh BarbatiOpened: 2012-01-16Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req.seedseq].
View all issues withNAD status.
Discussion:
The seed sequence requirements described in 29.5.3.2[rand.req.seedseq] appear to be over-specified. All seed sequence types are required to have aresult_type nested type, a specific set of constructors, function memberssize() andparam(), which are never used by the library. In fact, the only library components that actively use seed sequences are the random engines and all the engines need is thegenerate() member function. In particular, library components never attempts to construct seed sequence objects. These extraneous requirements are clearly written to describe the library provided typeseed_seq type; while it's good that seed_seq has all those constructors and members, it's not a compelling reason to require a user-provided seed sequence type to implement all of them.
class my_seed_seq{ /* internals */public: my_seed_seq(/* my own parameters */); template <class It> void generate(It first, It last);};my_seed_seq s(/* params */);std::default_random_engine e(s);The only reason to have these extra members would be to provide some support for generic serializability/persistence of seed sequence objects. I believe that would be out of the scope of the random library, so I doubt we will ever need those requirements in the future.
I therefore propose to remove all requirements from 29.5.3.2[rand.req.seedseq] except for the presence of thegenerate() function.[2012, Kona]
Move to Tenatively NAD. (Tentative as issue was not in pre-meeting mailing)
The 'overspecification', as such, was a deliberate intent to provide guarantees consumers of the wholerandom number framework may rely upon, especially in generic code. While the standard engines may bebuilt without relying on these guarantees, this specification is part of a commitment to a broaderframework, and Walter indicated future proposals in preparation for parallel generation of randomnumbers that may depend more inimately on these existing requirements.
Alisdair noted that theresult_type typedef was a call-back to how we used to specifyadaptable functors before TR1result_of and the addition ofstd::bind and isprobably not something we should be actively promoting in future libraries. However, it is toolate to remove this requirement from seed sequences unless we are doing further surgery, asrecommended by this issue.
Walter notes that theresult_type protocol has not been formally deprecated by thestandard. Alisdair replies that was the intent of deprecating thebind_1st/unary_function set of templates in C++11, although we did not say anything aboutresult_type in general.
Proposed resolution:
This wording is relative to the FDIS.
Edit 29.5.3.2[rand.req.seedseq] p2 as indicated:
A class
Ssatisfies the requirements of a seed sequence if the expressions shown in Table 115 are valid andhave the indicated semantics, and ifSalso satisfies all other requirements of this section 29.5.3.2[rand.req.seedseq]. In that Table and throughout this section:
Tis the type named byS's associatedresult_type;qis a value ofSand;andris a possibly const value ofSibandieare input iterators with an unsigned integervalue_typeof at least 32 bits;rbandreare mutable random access iterators with an unsigned integervalue_typeof at least 32 bits;obis an output iterator; andilis a value ofinitializer_list<T>.
Ditto, in Table 115, remove all rows except the one describingq.generate(rb, re):
| Expression | Return type | Pre/Post-condition | Complexity |
|---|---|---|---|
S::result_type | T | T is an unsigned integertype (6.9.2[basic.fundamental]) of at least 32 bits. | |
S() | the same initial state as all other default-constructed seed sequences of type S. | ||
S(ib,ie) | internal state that depends on some or all of the bits of the supplied sequence [ib, ie). | 𝒪(ie - ib) | |
S(il) | S(il.begin(),. | S(il.begin(), | |
q.generate(rb,re) | void | Does nothing ifrb == re.Otherwise, fills the supplied sequence [rb, re) with 32-bitquantities that depend on the sequence supplied to the constructor and possibly also depend on the history of generate's previousinvocations. | 𝒪(re - rb) |
r.size() | size_t | would be copied by a call to r.param. | |
r.param(ob) | void | can be provided to the constructor of a second object of type S, and that wouldreproduce in that second object a state indistinguishable from the state of the first object. | 𝒪(r.size()) |
TimedMutex specification problemSection: 32.6.4.3[thread.timedmutex.requirements], 32.6.4.3.2[thread.timedmutex.class]Status:Pending NAD EditorialSubmitter: Vicente J. Botet EscribaOpened: 2012-01-01Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.timedmutex.requirements].
View all issues withPending NAD Editorial status.
Discussion:
32.6.4.3.2[thread.timedmutex.class] says:
The class
timed_mutexshall satisfy all of theTimedMutexrequirements (32.6.4.3[thread.timedmutex.requirements]). It shall be a standardlayout class (Clause 11[class]).
Problem here is that 32.6.4.3[thread.timedmutex.requirements] does not define a requirement set named "TimedMutex",it only refers to "timed mutex types"
[2012, Portland: move to Tentatively NAD Editorial]
We have timed mutex type, but it is labeled timed mutex requirements
We can make a suggestion, but will send to the editor as it seems purely editorial.There is a typo, and we don't have the timed mutex but 32.6.4.3[thread.timedmutex.requirements] alreadysays timed mutex type, and we need to reuse that term down in the class to fulfil the mutex requirement.
[To Editor:]
Replace this one with timed mutex type.
Proposed resolution:
Section: 32.6.4[thread.mutex.requirements], 32.6.4.2.2[thread.mutex.class], 32.6.4.2[thread.mutex.requirements.mutex], 32.6.4.2.3[thread.mutex.recursive], 32.6.4.3[thread.timedmutex.requirements], 32.6.4.3.2[thread.timedmutex.class], 32.6.4.3.3[thread.timedmutex.recursive]Status:Pending NAD EditorialSubmitter: Pete BeckerOpened: 2012-01-16Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [thread.mutex.requirements].
View all otherissues in [thread.mutex.requirements].
View all issues withPending NAD Editorial status.
Discussion:
32.6.4.2.2[thread.mutex.class]/3 says that the class mutex "shall satisfy all theMutex requirements (32.6.4[thread.mutex.requirements])". 32.6.4.2.2[thread.mutex.class] is part of 32.6.4[thread.mutex.requirements], so at the very least, this requirement is recursive. But worse, there is nothing that says what "theMutex requirements" refers to. For example, the "Lockable requirements" section starts with "A typeL meets theLockable requirements if …". There is no such statement for "theMutex requirements".
recursive_mutex).32.6.4.3[thread.timedmutex.requirements], Timed mutex types, also needs the same rearrangement: its introductory requirements should be moved into a subclause, and the first sentences of 32.6.4.3.2[thread.timedmutex.class]/2 and 32.6.4.3.3[thread.timedmutex.recursive]/2 should be turned into notes that refer to this new subclause and to the new subclause in 32.6.4.2[thread.mutex.requirements.mutex].[2012, Portland: move to Tentatively NAD Editorial]
Seems no real ambiguity. May need some reorg of text rather then changing the wording.
Is there much that needs to be changed? But Pete's suggestion of putting requirement in separate sub section is good.Should be the direction to editor.
Suggest this is an editorial change. Happy with Pete's comments.
Proposed resolution:
Section: 31.7.5.4[istream.unformatted]Status:NADSubmitter: Loïc JolyOpened: 2012-03-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [istream.unformatted].
View all issues withNAD status.
Discussion:
I think the following code should be legal:
void f(std::istream& is){ std::string s; is.getline(s); // Would be equivalent to std::getline(is, s)}[2013-04-20, Bristol]
Unanimous that this is a new feature request and not a issue.
Resolution: Tentatively NADProposed resolution:
This wording is relative to N3376.
Change the class templatebasic_istream synopsis, 31.7.5.2[istream], as indicated
namespace std { template <class charT, class traits = char_traits<charT> > class basic_istream : virtual public basic_ios<charT,traits> { public: […]// 27.7.2.3 Unformatted input: […] basic_istream<charT,traits>& getline(char_type* s, streamsize n); basic_istream<charT,traits>& getline(char_type* s, streamsize n, char_type delim);template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str); template<class Allocator> basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str, char_type delim); […] };}Insert the following two new prototype descriptions after 31.7.5.4[istream.unformatted] paragraph 24:
basic_istream<charT,traits>& getline(char_type* s, streamsize n);-24-Returns:
getline(s,n,widen('\n'))template<class Allocator>basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str);-??-Returns:
std::getline(*this, str)template<class Allocator>basic_istream<charT,traits>& getline(basic_string<charT,traits,Allocator>& str, char_type delim);-??-Returns:
std::getline(*this, str, delim)
Section: 32.6.4.2[thread.mutex.requirements.mutex]Status:Pending NAD EditorialSubmitter: Pete BeckerOpened: 2012-03-05Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [thread.mutex.requirements.mutex].
View all issues withPending NAD Editorial status.
Discussion:
32.6.4.2[thread.mutex.requirements.mutex]/11 says that prior unlock operationssynchronize withm.lock().
m.try_lock() succeeds, prior unlock operationssynchronize with the operation.32.6.4.2[thread.mutex.requirements.mutex]/25 says thatm.unlock()synchronizes with subsequent successful lock operations.Does the third requirement add anything to the first two? If not, it should probably be a non-normative note.[2012, Portland: move to Tentatively NAD Editorial]
Agree that third note should be non-normative and adds nothing.
Seems An Editorial change, but does changing a normative to non-normative wording makes it a non-editorial change?
Ask the editor. If not editorial, then we will agree on the fix as removal of the third point,then we will put it in ready state for Bristol.
Proposed resolution:
const equivalence ofstd::mapSection: 23.4[associative], 23.5[unord]Status:NADSubmitter: Bjarne StroustrupOpened: 2012-06-18Last modified: 2016-08-02
Priority:2
View all otherissues in [associative].
View all issues withNAD status.
Discussion:
As described in the reflector discussion c++std-core-21860 consider the following example:
map<const int, int> mci{};map<int, int> mi = mci; // ??mci[1] = 2;mi[1] = 2;Should it be required that the marked initialization is well-formed? As a possible solutionthis could be realized by an alias template:
template <class K, class T>struct OriginalMap { […] };template <class K, class T>using ImprovedMap = OriginalMap<const K, T>;[2016-08 Chicago]
Recommend NAD. No other container supports conversion from differentcontainer specializations, so adding support directly might be moresurprising than the omission.
We would welcome papers on the convertibility of containers of differentelement types directed to the LEWG in the future.
Proposed resolution:
Section: 23.2.2[container.requirements.general]Status:NADSubmitter: Dean Michael BerrisOpened: 2012-07-13Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [container.requirements.general].
View all otherissues in [container.requirements.general].
View all issues withNAD status.
Discussion:
Table 96 defines the general requirement for copy assignment (row 23, page 704) as:
| Expression | Return type | Operational semantics | Assertion/note pre-/post-condition | Complexity |
|---|---|---|---|---|
r = a | X& | | post:r == a. | linear |
However there is no requirement thatT isCopyInsertable intoX.
[2012, Portland: Move to Tentatively NAD]
Howard notes that this may be a difficult requirement forstd::array
We already have this requirement for allocator aware containers, andstd::array already adds the appropriate extra requirement.
We say the necessary things in the necessary places, but the container requirementscontinue to cause confusion in where we sometimes say things. Consensus is thatthis issue remains NAD though.
Proposed resolution:
This wording is relative to N3376.
Change Table 96 — "Container requirements" in 23.2.2[container.requirements.general]:
| Expression | Return type | Operational semantics | Assertion/note pre-/post-condition | Complexity |
|---|---|---|---|---|
r = a | X& | | Requires:T isCopyInsertable intoX.post: r == a. | linear |
Section: 16.4.4.3[swappable.requirements]Status:NADSubmitter: Robert ShearerOpened: 2012-07-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [swappable.requirements].
View all issues withNAD status.
Discussion:
Paragraph 16.4.4.3[swappable.requirements] p4 states:
An rvalue or lvalue
tisswappable if and only iftis swappable with any rvalue or lvalue, respectively, of typeT.
This paragraph seems to establish two disjoint definitions of "swappable" — one for lvalues and one for rvalues — with neither definition including the case of swapping an rvalue with an lvalue.
Resolution proposal:Delete the word "respectively".[2012-10 Portland: Close as NAD]
The current wording does intentionally specify two families of 'swappable' behaviors, for lvaluesand for rvalues, and not for mixed behavior. The need to support rvalues is for types likevector<bool>::reference. Likewise, library types likestring provide aswap for values, but not a mixed-modeswap between lvalues and rvalues, whichwere deliberately removed from C++11 after initally being part of the standard.
Accepting this resolution would break the library specification, as no current library type wouldmeet the new requirements.
Proposed resolution:
This wording is relative to N3376.
Change 16.4.4.3[swappable.requirements] p4 as indicated:
An rvalue or lvalue
tisswappable if and only iftis swappable with any rvalue or lvalue, respectively,of typeT.
Allocator requirement changes not mentioned Annex CSection: 16.4.4.6[allocator.requirements], C.8[diff.library]Status:Pending NAD EditorialSubmitter: Nevin LiberOpened: 2012-08-14Last modified: 2016-11-21
Priority:3
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withPending NAD Editorial status.
Discussion:
Given that a number of things were removed from the allocator requirements (reference,const_reference,address() in 16.4.4.6[allocator.requirements]), it seems that these incompatible changes should be mentioned in Annex C.8[diff.library], more specifically in [diff.cpp03].
[2012-10 Portland: Move to Open ]
It was clearly pointed out by Bill during the C++11 process that our change to allocator requirementspotentially broke 3rd party user containers written to expect C++03 allocators, or rather, anallocator written to the minimal requirements of C++11 might not be guaranteed to work with a containerwritten to the previous rules. This was a trade-off in making allocaters easier to write by use oftheallocator_traits framework.
This probably does merit a write-up in Annex C, and we look forward to seeing wording. Until then,the best we can do is move the issue to Open.
[2016-11-12, Issaquah]
Sat PM: JW to provide Annex C wording Status to "Pending NAD Editorial".
Proposed resolution:
Section: 23.2.8[unord.req]Status:NADSubmitter: Alisdair MeredithOpened: 2012-10-09Last modified: 2016-11-21
Priority:3
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
The default constructor, allocator-aware constructor, and range-based constructorsfor the unordered containers do not offer a means to control the initialmax_load_factor, so the standard mandates the value 1.0. This seems overlyrestrictive, as there is plenty of research suggesting a value between 0.5 and 1.0is more often optimal for unique-key containers, and perhaps a slightly highervalue might be appropriate for multi-containers.
Rather than guess at the appropriatemax_load_factor, it seems reasonablethat the standard should allow vendors to pick a value at their discretion, withperhaps a note of advice. It is less clear whether the default value should beimplementation-defined or unspecified, given the ease of a user determining thisby querying this attribute immediately after construction.
[2013-03-15 Issues Teleconference]
Moved to Open.
Alisdair to provide wording.
Marshall: It seems to me that what you really want is to be able to pass a max load factor in theconstructor, but that's a different issue.
Alisdair agrees in principle, but concerned with adding yet more constructors to these classes.
[2016-11-12, Issaquah]
NAD - if someone wants to come back with a paper exploring design alternatives, we can re-open.
Proposed resolution:
Section: C.8[diff.library]Status:NAD EditorialSubmitter: Kevin McCartyOpened: 2012-02-03Last modified: 2016-11-28
Priority:2
View all otherissues in [diff.library].
View all issues withNAD Editorial status.
Discussion:
It seems that in C.8[diff.library], Table 150 the following macros from [c.limits], Table 31 are missing:
LLONG_MIN LLONG_MAXULLONG_MAX
In addition in C.8[diff.library], Table 150 the following macros from [c.limits], Table 32 are missing:
DECIMAL_DIG FLT_EVAL_METHOD
Furtheron it seems that in C.8[diff.library], Table 149/150 further macros are missing as well, e.g.HUGE_VALF,INFINITY, etc.
[2014-02 Issaquah:]
This is an issue, all of C has not been updated for C99, C99 functions are missing, whole section needs to be overhauled.
The issue needs to be updated for functions and other missing items and when that happens the issue title is wrong andneeds to be adapted.[2016-08 Chicago: Zhihao Yuan comments]
We suggest to either:
Having a paper to rewrite C.5 C standard library by strikingthe content shared by C and C++ and leave only thedifferences;
Having a paper, or a complete proposed wording to fixthe missing names added between C89 and C99.
For 1), some C11 headers being excluded from C++ (such asthread.h) need to be added to this section.
[2016-11-12, Issaquah]
Sat PM: Thomas will attempt to fix this editorially If he cannot, we will reexamine.
[2016-11-16]
Resolved as NAD Editorial
Proposed resolution:
reverse_iterator should not require a second copy of the base iteratorSection: 24.5.1.6[reverse.iter.elem]Status:NADSubmitter: David AbrahamsOpened: 2012-10-30Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [reverse.iter.elem].
View all issues withNAD status.
Discussion:
This note in [reverse.iter.op.star]/2:
[Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]
is incorrect because such iterator implementations are ruled out by24.3.5.5[forward.iterators]/6, where it says:
Ifaandbare both dereferenceable, thena == bif and only if*aand*bare bound to the same object.
[2013-04-20, Bristol]
Alisdair: sugested to strike the "exposition only" member.
Daniel: we must check that it wouldn't conflict with a previous solution to another issue.Dietmar: This is an issue but the proposing word is not correct. When we have proxies inside the sequence.Solution: NAD thanks to a contrieved example by Dietmar.Proposed resolution:
Strike the note, [reverse.iter.op.star]/2:
[Note: This operation must use an auxiliary member variable rather than a temporary variable to avoid returning a reference that persists beyond the lifetime of its associated iterator. (See 24.2.) —end note ]
wstring_convert methods do not take allocator instanceSection: 99 [depr.conversions.string]Status:NADSubmitter: Glen FernandesOpened: 2012-12-14Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [depr.conversions.string].
View all issues withNAD status.
Discussion:
Thewstring_convert class template, described in 99 [depr.conversions.string], does not support custom stateful allocators. It only supports custom stateless allocators.
to_bytes member function returnsbasic_string<char, char_traits<char>, Byte_alloc> but it does not take an instance ofByte_alloc to pass to the constructor of thebasic_string.Similarly thefrom_bytes member function returnsbasic_string<Elem, char_traits<Elem>, Wide_alloc> but it does not take an instance ofWide_alloc to pass to the constructor of thebasic_string.This makes these two member functions and thewstring_convert class template not usable whenWide_alloc orByte_alloc are stateful allocators.[2013-01-22, Glen provides wording]
[2013-03-15 Issues Teleconference]
Moved to NAD Future.
This is clearly an extension that the LEWG may want to take a look at, once we have more experiencewith appropriate use of allocators with the C++11 model.
[LEWG Kona 2017]
Recommend NAD: Does this follow the pattern? Should be discussed as a group. Do we have the experience with the C++11 allocator model to know that this is the addition to make?
Shouldto_string() also take an allocator?substr()? Any function that returns a string?
This suggests a larger change.
[Kona 2019]
Jonathan points out: The wstring_convert type is deprecated now.
Proposed resolution:
This wording is relative to N3485.
In 99 [depr.conversions.string]/2 and /6 "Class templatewstring_convert synopsis" change the overloads of the member functionfrom_bytes() so that all four overloads take an additional parameterwhich is an instance ofWide_alloc:
wide_string from_bytes(char byte, const Wide_alloc& alloc = Wide_alloc());wide_string from_bytes(const char *ptr, const Wide_alloc& alloc = Wide_alloc());wide_string from_bytes(const byte_string& str, const Wide_alloc& alloc = Wide_alloc());wide_string from_bytes(const char *first, const char *last, const Wide_alloc& alloc = Wide_alloc());
In 99 [depr.conversions.string] /8 specify that thisWide_alloc allocator parameter is used toconstruct thewide_string object returned from the function:
-7-Effects: The first member function shall convert the single-element sequencebyte to a wide string.The second member function shall convert the null-terminated sequence beginning atptr to a widestring. The third member function shall convert the sequence stored instr to a wide string. The fourthmember function shall convert the sequence defined by the range[first, last) to a wide string.
If thecvtstate object was not constructed with an explicit value, it shall be set to its default value(the initial conversion state) before the conversion begins. Otherwise it shall be left unchanged.
The number of input elements successfully converted shall be stored incvtcount.
TheWide_alloc allocator parameter is used to construct thewide_string object returned from the function.
In 99 [depr.conversions.string]/2 and /12 "Class templatewstring_convert synopsis" change the overloads of the member functionto_bytes() so that all four overloads take an additional parameterwhich is an instance ofByte_alloc:
byte_string to_bytes(Elem wchar, const Byte_alloc& alloc = Byte_alloc());byte_string to_bytes(const Elem *wptr, const Byte_alloc& alloc = Byte_alloc());byte_string to_bytes(const wide_string& wstr, const Byte_alloc& alloc = Byte_alloc());byte_string to_bytes(const Elem *first, const Elem *last, const Byte_alloc& alloc = Byte_alloc());
In 99 [depr.conversions.string] /13 specify that thisByte_alloc allocator parameter is used toconstruct thebyte_string object returned from the function:
-12-Effects: The first member function shall convert the single-element sequencewchar to a byte string.The second member function shall convert the null-terminated sequence beginning atwptr to a bytestring. The third member function shall convert the sequence stored inwstr to a byte string. Thefourth member function shall convert the sequence defined by the range[first, last) to a byte string.
If thecvtstate object was not constructed with an explicit value, it shall be set to its default value(the initial conversion state) before the conversion begins. Otherwise it shall be left unchanged.
The number of input elements successfully converted shall be stored incvtcount.
TheByte_alloc allocator parameter is used to construct thebyte_string object returned from the function.
[uninitialized_]copy_n() defectSection: 26.7.1[alg.copy], 26.11.5[uninitialized.copy]Status:NADSubmitter: Sean ParentOpened: 2013-02-14Last modified: 2017-06-05
Priority:2
View otheractive issues in [alg.copy].
View all otherissues in [alg.copy].
View all issues withNAD status.
Discussion:
copy_n() anduninitialized_copy_n() only return the output iterator, and not the input iterator. Likely the interface was simply copied from the original STL. Unfortunately the interface in the original STL contains a bug.
copy_n() anduninitialized_copy_n() must return the resulting input iterator as well as the output iterator (I would suggest returning a pair). Without this, there is no way to continue reading from an actual input iterator — and if it is really a forward iterator, it will costn increments to get back to where you were.[2016-08 Chicago]
Tues PM: refer to LEWG
[2017-02 in Kona, LEWG recommends NAD]
Potentially breaks lots of things. Cannot overload on return type. Pair, tuple, or struct return? New name? Needs paper with a new algorithm (copy_n_works)? Not an issue for istream iterators (can get stream and get a new iterator). Don’t use this function, use ranges.
[2017-06-02 Issues Telecon]
This change has been made in the Ranges TS.
Resolve as NAD
Proposed resolution:
ssize_tSection: 17.2[support.types]Status:NADSubmitter: Matt AusternOpened: 2013-04-19Last modified: 2016-01-28
Priority:3
View all otherissues in [support.types].
View all issues withNAD status.
Discussion:
The C++ standard library definessize_t, a typedef for an implementation defined unsigned integer type that can represent the sizes of objects. The POSIX standard augments this withssize_t, a typedef for a signed integer type that corresponds tosize_t.
ssize_t typedef is useful — useful enough that the C++ standard even refers to it. (In a non-normative footnote in 31.2.2[stream.types].) Also, lots of OS vendors add it to their headers anyway, even though it isn't part of the C or C++ standards, because those vendors are trying to define headers that conform to multiple standards at once. We should make users' and implementers' lives easier by addingssize_t to 17.2[support.types].[2013-09-29, Suggested wording from Jayson Oldfather]
I decided to use the phrase to describessize_t below because of the text describing it in thePOSIX standard. In it, it describesssize_t with the value range of[-1,{SSIZE_MAX}].SSIZE_MAX is specified in thePOSIX standard as a minimum value of_POSIX_SSIZE_MAX. This macro is referenced in the wording below.
[Lenexa 2015-05-05: NAD - no consensus for a change]
Billy : ssize_t that was promised to be signed, was based on rsize_t from safe secure C
NM : ssize_t s ptrdif_t
Z : ptrdiff_t is full range, ssize_t has only -1 as negative value
Billy : motivations for ptrdiff_T, ssize_t and rsize_T all fuzzy. - Reads rsize max -
NM : ptrdiff_T not big enough to rep difference of pointers anymore
STL : description incorporates posixisms
Billy : Don't need it
NM : rather remove it from footnote
Z : Name has precise meaning
STL : everyone understands ptrdiff_t is signed counterpart to size_t
Billy : Not in all implementations anymore
DK : footnote says something different from ...
Z/NM : off_t historically tainted
STL : we have a type trait to make signed version of size_t. we should just use that
MC : NAD; is feature request
TP : It's not cstdsef
Proposed resolution:
Ammend 17.2[support.types], Table 30 as indicated:
Table 30 — Header <cstddef>synopsisType Name(s) Macros: NULL offset_tTypes: ptrdiff_tssize_t size_t max_align_t nullptr_t
Add the following paragraph to describessize_t
-?- The type
ssize_tis an implementation-defined signed integer type that shall contain the minimum range[-1, {SSIZE_MAX}]whereSSIZE_MAXis specified at a minimum of_POSIX_SSIZE_MAX.
Ammend p7 as follows:
-7- [Note: It is recommended that implementations choose types for
ptrdiff_t, ssize_t,andsize_twhose integer conversion ranks …
dynarray should state which container requirements aren't metSection: 99 [arrays.ts::dynarray.overview]Status:NAD ArraysSubmitter: Jonathan WakelyOpened: 2013-04-23Last modified: 2016-10-31
Priority:0
View all issues withNAD Arrays status.
Discussion:
Addresses: arrays.ts
99 [arrays.ts::dynarray.overview] p2 says:
"Unless otherwise specified, all
dynarrayoperations have the same requirements and semantics as specified in99 [arrays.ts::container.requirements]."
Some differences from 99 [arrays.ts::container.requirements] are not explicitly specified, including atleast the lack of a default constructor, copy assignment andswap member.
swap does not have constant complexity."[2013-09 Chicago:]
Move to Deferred. This feature will ship after C++14 and should be revisited then.
[2014-06-06 pre-Rapperswil]
This issue has been reopened as arrays-ts.
[2014-06-16 Rapperswil]
Move to Ready
[2014/11 Urbana]
Held at Ready status, pending clarification of Arrays TS
Proposed resolution:
Add to 99 [arrays.ts::dynarray.overview] p2:
-2-Adynarray satisfies all of the requirements of a container and of a reversible container (99 [arrays.ts::container.requirements]), except for default construction, assignment andswap. Unless otherwise specified, alldynarray operations have the same requirements and semantics as specified in 99 [arrays.ts::container.requirements].
dynarray an allocator-aware container?Section: 99 [arrays.ts::container.requirements.general]Status:NAD ArraysSubmitter: Jonathan WakelyOpened: 2013-04-23Last modified: 2016-10-31
Priority:3
View all issues withNAD Arrays status.
Discussion:
Addresses: arrays.ts
99 [arrays.ts::container.requirements.general] p3 says:
"All of the containers defined in this Clause and in (21.4) except
arraymeet the additional requirements of an allocator-aware container, as described in Table 99."
Is this true ofdynarray? I believe the answer must be no becausedynarray has noallocator_type, and morally should be no, so that operations are defined in terms ofstd::allocator<T>, which p13 saysdoesn't actually need to be used (which allows the elements to be default-initialized as is intended, rather than "default-inserted into the container" using an allocator.)
X" requirements for allocator-aware containers, allowing an allocator to control construction of thedynarray elements.[2013-09 Chicago]
Move to Deferred. This feature will ship after C++14 and should be revisited then.
[2014-06-06 pre-Rapperswill]
This issue has been reopened as arrays-ts.
Proposed resolution:
Change to 99 [arrays.ts::container.requirements.general] p13:
-13- All of the containers defined in this Clause and in (21.4) exceptarrayanddynarray meet the additional requirements of an allocator-aware container, as described in Table 99.
dynarray constructor ambiguitySection: 99 [arrays.ts::dynarray.cons]Status:NAD ArraysSubmitter: Jonathan WakelyOpened: 2013-04-23Last modified: 2016-03-08
Priority:0
View all issues withNAD Arrays status.
Discussion:
Addresses: arrays.ts
These constructors can interact badly::
template<class Alloc> dynarray(size_type c, const Alloc& alloc);dynarray(size_type c, const T& v);
Unless the second argument is a value of exactly the typeT you will get the first constructor, i.e. all of these will fail to compile:
dynarray<long> dlong(1, 1); // 1 is not longdynarray<float> dflt(1, 1.0); // 1.0 is not floatdynarray<int*> dptr(1, nullptr); // nullptr is not int*dynarray<void*> doh(1, 0); // 0 is not void*
Thenullptr case is particularly annoying, a user trying to do the right thing by sayingnullptr instead ofNULL still gets the wrong result.
Alloc shall meet the requirements for an Allocator" but doesn't actually say "shall not participate in overload resolution unless ..."I believe we have no precedent for using SFINAE to check "the requirements for an Allocator" because it's a pretty complicated set of requirements. We could say it shall not participate in overload resolution ifAlloc is implicitly convertible tovalue_type.Alternatively, we could follow the same approach used by other types that can be constructed with an unconstrained allocator type and usestd::allocator_arg_t as the first argument instead of adding an allocator after the other arguments.[2013-09 Chicago:]
Move to Deferred. This feature will ship after C++14 and should be revisited then.
[2014-06-06 pre-Rapperswil]
This issue has been reopened as arrays-ts.
[2014-06-16 Rapperswil]
Move to Ready for alternative A
Previous resolution [SUPERSEDED]:
Either use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the constructors to take
dynarray(std::allocator_arg_t, const Alloc&, ...)by modifying both the synopsis99 [arrays.ts::dynarray.overview] p2 and 99 [arrays.ts::dynarray.cons] before p9 like so:template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,size_type c, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,size_type c, const T& v, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,const dynarray& d, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,initializer_list<T>, const Alloc& alloc);or constrain the problematic constructor by adding a new paragraph to 99 [arrays.ts::dynarray.cons]:
template <class Alloc> dynarray(size_type c, const Alloc& alloc);template <class Alloc> dynarray(size_type c, const T& v, const Alloc& alloc);template <class Alloc> dynarray(const dynarray& d, const Alloc& alloc);template <class Alloc> dynarray(initializer_list<T>, const Alloc& alloc);-9-Requires:
-10-Effects: Equivalent to the preceding constructors except that each element is constructed with uses-allocatorconstruction (20.2.8.2[allocator.uses.construction]).-?-Remarks: The first constructor shall not participate in overload resolution unlessAllocshall meet the requirements for an Allocator (16.4.4.6[allocator.requirements]).Allocis not implicitly convertible toT.
[2014/11 Urbana]
Held at Ready status, pending clarification of Arrays TS
Proposed resolution:
Use the correct way to unambiguously call a constructor taking any type of allocator, i.e. change the constructors to takedynarray(std::allocator_arg_t, const Alloc&, ...) by modifying both the synopsis99 [arrays.ts::dynarray.overview] p2 and 99 [arrays.ts::dynarray.cons] before p9 like so:
template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,size_type c, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,size_type c, const T& v, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,const dynarray& d, const Alloc& alloc);template <class Alloc> dynarray(allocator_arg_t, const Alloc& a,initializer_list<T>, const Alloc& alloc);
vector iterator invalidationSection: 23.3.13.5[vector.modifiers]Status:NADSubmitter: Howard HinnantOpened: 2013-04-29Last modified: 2020-05-08
Priority:3
View all otherissues in [vector.modifiers].
View all issues withNAD status.
Discussion:
23.3.13.5[vector.modifiers]/p3 says:
iterator erase(const_iterator position);iterator erase(const_iterator first, const_iterator last);Effects: Invalidates iterators and references at or after the point of the erase.
Consider this example:
#include <vector>#include <cassert>int main(){ typedef std::vector<int> C; C c = {1, 2, 3, 4}; C::iterator i = c.begin() + 1; C::iterator j = c.end() - 1; assert(*i == 2); assert(*j == 4); c.erase(c.begin());assert(*i == 3); // Why is this not perfectly fine?!}Why has the iteratori been invalidated? It still refers to a perfectly reasonable, fully constructed object. Ifvector::iterator were to be implemented as a pointer (which is legal), it is not possible for that last line to do anything but run fine.
j on the other hand now points at end, and any iterators that may now point beyondend(), into uninitialized memory, are clearly invalid.But why do we say that an iterator thatmust point to a valid object is invalid? This looks to me like we simply got sloppy in our specification.[2016-05 Issues Telecon]
[2017-03-04, Kona]
NAD. "Works as designed" Also, the example does not work in today's world oflaunder.
Proposed resolution:
std::dynarray defines its initializer-list constructor in terms of a non-existent constructorSection: 99 [arrays.ts::dynarray], 99 [arrays.ts::container.requirements]Status:NAD ArraysSubmitter: Povilas KanapickasOpened: 2013-05-22Last modified: 2016-03-08
Priority:1
View all issues withNAD Arrays status.
Discussion:
Addresses: arrays.ts
std::dynarray member listing at 99 [arrays.ts::dynarray.overview] includes this constructor:
dynarray(initializer_list<T>);
Also, 99 [arrays.ts::dynarray.overview] p. 2 says:
Unless otherwise specified, all
dynarrayoperations have the same requirements and semantics as specified in 23.2.
The constructor in question isn't mentioned in 99 [arrays.ts::dynarray.cons] or anywhere else. This means requirements from 99 [arrays.ts::container.requirements] apply. However, Table 100 in 23.2.4[sequence.reqmts] says:
X(il)Equivalent toX(il.begin(), il.end())
std::dynarray does not provide this constructor.
The proposed resolution below adds the missing constructor and a complementary constructor with an allocator parameter. The new constructors, differently from the rest of containers, accept iterators that have forward iterator category. This is needed because the size requirements must be known in order to allocate appropriately-sized storage.
An alternative resolution could be to properly specify the initializer-list constructor.[2013-09 Chicago:]
Move to Deferred. This feature will ship after C++14 and should be revisited then.
[2014-06-06 pre-Rapperswill]
This issue has been reopened as arrays-ts.
Proposed resolution:
Add the following to thestd::dynarray synopsis at 99 [arrays.ts::dynarray.overview]:
namespace std { template <class T> class dynarray { […]// 23.3.4.2 construct/copy/destroy: […]template <class ForwardIterator>dynarray(ForwardIterator first, ForwardIterator last);template <class ForwardIterator, class Alloc>dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc); […] };}Add the following to 99 [arrays.ts::dynarray.cons] after p. 8:
template <class ForwardIterator>dynarray(ForwardIterator first, ForwardIterator last);-?-Requires:
-?-Effects: Allocates storage forTshall meet theCopyConstructiblerequirements.distance(first, last)elements.Thedistance(first, last)elements of the dynarray are direct-initialized (9.5[dcl.init]) with the corresponding elements from the range[first,last). May or may not invoke the globaloperator new.-?-Complexity:distance(first, last).-?-Throws:std::bad_array_lengthwhen the size requested is larger than implementable,std::bad_allocwhen there is insufficient memory.
Add the following to the list of constructors at 99 [arrays.ts::dynarray.cons] before p. 9:
template <class Alloc>dynarray(size_type c, const Alloc& alloc);template <class Alloc>dynarray(size_type c, const T& v, const Alloc& alloc);template <class Alloc>dynarray(const dynarray& d, const Alloc& alloc);template <class Alloc>dynarray(initializer_list<T>, const Alloc& alloc);template <class ForwardIterator, class Alloc>dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc);
to_string overloadsSection: 27.4.5[string.conversions]Status:NADSubmitter: Raf SchietekatOpened: 2013-07-02Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [string.conversions].
View all issues withNAD status.
Discussion:
For internal consistency,to_string() should either list all relevant types (includingbool,char, etc.), or only those that are the destination types of integral or floating-point promotion (float not being among them).
float overloads anyway could be to exactly mirror the adjacent sets ofstoX() function overloads (even without round-trip fidelity for floating-point numbers).Unfortunately, that reveals a bigger issue than redundant overloads: the glaring and indefensible omission of an overloaded functionstoui(). Adding that is not as trivial as removing redundant overloads, of course, because it requires everybody to take action. Still, it is the preferable remedy for the present situation.As far as I can tell from easily accessible information, C++ has already created the precedent withstoi(), which is not the equivalent of a pair of functionsstrtoi()/wcstoi() in C, but it would be if such functions existed. The functionatoi() may look similar, but it does not qualify because it is as different from a hypotheticalstrtoi() asatol() currently is fromstrtol(), with the latter two both Standard C. It is only logical to act on this one-sided precedent by completing the set. Whether or not Standard C leads the way (or follows suit) is immaterial, but an invitation could be extended.[2013-09 Chicago]
These overloads were very carefully and experimentally determined to be the minimal set, when all (known) promotion andconversion scenarios were considered. Removing superfluous-looking overloads is likely to result in ambiguities.
Proposed resolution:
This wording is relative to N3691.
Modify 27.4[string.classes], header<string> synopsis, as indicated:
#include <initializer_list>namespace std { […] string to_string(int val); string to_string(unsigned val); string to_string(long val); string to_string(unsigned long val); string to_string(long long val); string to_string(unsigned long long val);string to_string(float val); string to_string(double val); string to_string(long double val); […] […] wstring to_wstring(int val); wstring to_wstring(unsigned val); wstring to_wstring(long val); wstring to_wstring(unsigned long val); wstring to_wstring(long long val); wstring to_wstring(unsigned long long val);wstring to_wstring(float val); wstring to_wstring(double val); wstring to_wstring(long double val); […]}Modify 27.4.5[string.conversions] p7+14 as indicated:
string to_string(int val);string to_string(unsigned val);string to_string(long val);string to_string(unsigned long val);string to_string(long long val);string to_string(unsigned long long val);string to_string(float val);string to_string(double val);string to_string(long double val);-7-Returns: Each function returns a
[…]stringobject holding the character representation of the value ofits argument that would be generated by callingsprintf(buf, fmt, val)with a format specifier of"%d","%u","%ld","%lu","%lld","%llu","%f","%f", or"%Lf", respectively, wherebufdesignates an internal character buffer of sufficient size.wstring to_wstring(int val);wstring to_wstring(unsigned val);wstring to_wstring(long val);wstring to_wstring(unsigned long val);wstring to_wstring(long long val);wstring to_wstring(unsigned long long val);wstring to_wstring(float val);wstring to_wstring(double val);wstring to_wstring(long double val);-14-Returns: Each function returns a
wstringobject holding the character representation of the value ofits argument that would be generated by callingswprintf(buf, buffsz, fmt, val)with a format specifier ofL"%d",L"%u",L"%ld",L"%lu",L"%lld",L"%llu",L"%f",L"%f", orL"%Lf", respectively, wherebufdesignates an internal character buffer of sufficient sizebuffsz.
<dynarray> is missing in 24.7/1Section: 99 [arrays.ts::iterator.range]Status:NAD ArraysSubmitter: Cassio NeriOpened: 2013-07-31Last modified: 2016-03-08
Priority:3
View all issues withNAD Arrays status.
Discussion:
Addresses: arrays.ts
Section 99 [arrays.ts::iterator.range] p1 specifies header files that, in addition to<iterator>, make available the function templates in 24.7(begin,end, etc.) but it fails to mention<dynarray>. This seems to be just an oversight.
[2013-09 Chicago:]
Move to Deferred. This feature will ship after C++14 and should be revisited then.
[2014-06-06 pre-Rapperswill]
This issue has been reopened as arrays-ts.
Proposed resolution:
This wording is relative to N3691.
Modify 99 [arrays.ts::iterator.range] p1 as indicated:
-1- In addition to being available via inclusion of the
<iterator>header, the function templates in 24.7 areavailable when any of the following headers are included:<array>,<deque>,<dynarray>,<forward_list>,<list>,<map>,<regex>,<set>,<string>,<unordered_map>,<unordered_set>, and<vector>.
list::splice functionSection: 23.3.11.5[list.ops], 23.3.7.6[forward.list.ops]Status:NADSubmitter: Arseny KlimovskyOpened: 2013-08-15Last modified: 2023-02-07
Priority:Not Prioritized
View all otherissues in [list.ops].
View all issues withNAD status.
Discussion:
I think that the effects oflist::splice function should be stated more carefully.
void splice(const_iterator position, list& x, const_iterator i);void splice(const_iterator position, list&& x, const_iterator i);Effects: Inserts an element pointed to by
ifrom listxbefore position and removes the element fromx. The result is unchanged ifposition == iorposition == ++i. Pointers and references to*icontinue to refer to this same element but as a member of*this. Iterators to*i(includingiitself)continue to refer to the same element, but now behave as iterators into*this, not intox.
But it is incorrect to talk aboutoperator== for iterators that are not from the same container (after acceptance ofN3066, 24.3.5.5[forward.iterators] p2). So, the text operates with an undefined behaviour.
One is formally allowed to have list implementation where two iterators from different lists return true tooperator==.For example, this can only happen to non-dereferenceable iterators, andposition and++i can be non-dereferenceable. So, literally according to the standard, it is not allowed in this implementation to transfer such elements withsplice function.
[2013-09 Chicago (late night issues)]
Moved to NAD.
The condition under which thelist is unchanged is not program code, so there is no undefined behavior to protect against.Rather, the precondition that the evaluation can be performed is implicit if determining when the condition applies.
Proposed resolution:
This wording is relative to N3691.
Modify [forwardlist.ops] p6 as indicated:
void splice_after(const_iterator position, forward_list& x, const_iterator i);void splice_after(const_iterator position, forward_list&& x, const_iterator i);[…]
-6-Effects: Inserts the element followingiinto*this, followingposition, and removes it fromx. The result is unchanged if&x == thisand the following condition is satisfied:position == iorposition == ++i. Pointers and references to*++icontinue to refer to the same element but as a member of*this. Iterators to*++icontinue to refer to the same element, but now behave as iterators into*this, not intox.
Modify 23.3.11.5[list.ops] p7 as indicated:
void splice(const_iterator position, list& x, const_iterator i);void splice(const_iterator position, list&& x, const_iterator i);-7-Effects: Inserts an element pointed to by
ifrom listxbefore position and removes the element fromx. The result is unchanged if&x == thisand the following condition is satisfied:position == iorposition == ++i. Pointers and references to*icontinue to refer to this same element but as a member of*this. Iterators to*i(includingiitself) continue to refer to the same element, but now behave as iterators into*this, not intox.
Section: 16.4.3.3[using.linkage]Status:NAD EditorialSubmitter: Chris SharpeOpened: 2013-08-23Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [using.linkage].
View all issues withNAD Editorial status.
Discussion:
There is a footnote at section 16.4.3.3[using.linkage]/2 that reads:
"The only reliable way to declare an object or function signature from the Standard C library is by including the header that declares it, notwithstanding the latitude granted in 7.1.7 of the C Standard."
There is no section 7.1.7 in the C99 Standard (or C11 final draft). I think the relevant section is:
"Provided that a library function can be declared without reference to any type defined in a header, it is also permissible to declare the function and use it without including its associated header."
at 7.1.4/2 from C99.
[2013-09 Chicago]
Moved to NAD Editorial.
Proposed resolution:
This wording is relative to N3691.
Edit footnote 182, 16.4.3.3[using.linkage] as indicated:
The only reliable way to declare an object or function signature from the Standard C library is by including the headerthat declares it, notwithstanding the latitude granted in
7.1.77.1.4 of the C Standard.
std::exchangeSection: 22.2.3[utility.exchange]Status:NADSubmitter: Alisdair MeredithOpened: 2013-09-22Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [utility.exchange].
View all issues withNAD status.
Discussion:
Addresses GB 5
The wording describes example code including the call of a move constructor, but there is no requirement stated thatT be move constructible.
Requires: Type
Tshall beMoveConstructible(Table 20) andMoveAssignable(Table 22).
However theMoveAssignable concept currently does not cover cases where the source and destination types may differ.
[2013-09 Chicago]
The requirements are implicit according to 16.3.2.4[structure.specifications]p4. There is no desire to redundantlyrepeat a set of requirements.
Proposed resolution:
Section: 17.6.3.4[new.delete.placement]Status:Pending NADSubmitter: Marc GlisseOpened: 2013-09-12Last modified: 2017-09-07
Priority:2
View all otherissues in [new.delete.placement].
View all issues withPending NAD status.
Discussion:
Based onthis discussion and as discussed inc++std-core-23998 andc++std-lib-34442, calling placement new currently forces the compiler to check if the pointer is null before initializing the object (a non-negligible cost). It seems many people were not aware of this and they consider it a user error to pass a null pointer to it.
Proposed resolution: foroperator new andoperator new[], add:Requires:
ptrshall not be a null pointer.
[2014-02-15 post-Issaquah session : move to Tentatively NAD]
AJM to supply the rationale...
Proposed resolution:
This wording is relative to N3691.
Change 17.6.3.4[new.delete.placement] as indicated:
void* operator new(std::size_t size, void* ptr) noexcept;-?-Requires:
-2-Returns:ptrshall not be a null pointer.ptr.-3-Remarks: Intentionally performs no other action.-4- [Example: This can be useful for constructing an object at a known address:void* place = operator new(sizeof(Something));Something* p = new (place) Something();—end example]
void* operator new[](std::size_t size, void* ptr) noexcept;-?-Requires:
-5-Returns:ptrshall not be a null pointer.ptr.-6-Remarks: Intentionally performs no other action.
optional forwarding construction/assignmentSection: 5.3.1[fund.ts::optional.object.ctor]Status:NADSubmitter: Cassio NeriOpened: 2013-09-23Last modified: 2015-10-26
Priority:4
View all issues withNAD status.
Discussion:
Addresses: fund.ts
Consider:
struct foo { foo(std::initializer_list<int>&); // 1 foo(const std::initializer_list<int>&); // 2 foo(std::initializer_list<int>&&); // 3 foo(const std::initializer_list<int>&&); // 4};std::initializer_list<int> il{0, 1, 2};foo foo_0{1, 2, 3}; // calls 3foo foo_1{il}; // calls 1foo foo_2((const std::initializer_list<int>&) il); // calls 2foo foo_3{(std::initializer_list<int>&&) il}; // calls 3foo foo_4((const std::initializer_list<int>&&) il); // calls 4Although the constructors offoo are unusual (initializer_lists arenormally passed byvalue) users ofoptional could naturally expect perfect forwarding ofinitializer_lists. However,all lines below end up calling 1.
optional<foo> opt0{in_place, {1, 2, 3}};optional<foo> opt1{in_place, il}; optional<foo> opt3{in_place, (const std::initializer_list<int>&) il};optional<foo> opt2{in_place, (std::initializer_list<int>&&) il};optional<foo> opt4{in_place, (const std::initializer_list<int>&&) il};opt0.emplace({1, 2, 3});opt0.emplace(il);opt0.emplace((const std::initializer_list<int>&) il);opt0.emplace((std::initializer_list<int>&&) il);opt0.emplace((const std::initializer_list<int>&&) il);The constructor
template <class... Args> constexpr explicit optional(in_place_t, Args&&... args);
can handle all constructor calls above, except the one taking{1, 2, 3}. Hence, a simplemodification of
template <class U, class... Args>constexpr explicit optional(in_place_t, initializer_list<U>&& il, Args&&... args);
allows perfect forwarding ofstd::initializer_list<U>s to be complete.
[2014-06-06 pre-Rapperswil]
This issue has been reopened as fundamentals-ts.
[2014-06-17, Rapperswil]
Move to NAD
Proposed resolution:
This wording is relative to N3691.
Change 5.3.1[fund.ts::optional.object.ctor] as indicated:
template <class U, class... Args> constexpr explicit optional(in_place_t, initializer_list<U>&& il, Args&&... args);-27-Requires:
-28-Effects: Initializes the contained value as if constructing an object of typeis_constructible<T, initializer_list<U>&&, Args&&...>::valueistrue.Twith the arguments,ilstd::move(il)std::forward<Args>(args)....[…]-31-Remarks: The function shall not participate in overload resolution unlessis_constructible<T, initializer_list<U>&, Args&&...>::valueistrue.
Change 5.3.3[fund.ts::optional.object.assign] as indicated:
template <class U, class... Args>void optional<T>::emplace(initializer_list<U>&& il, Args&&... args);-27-Requires:
-28-Effects: Callsis_constructible<T, initializer_list<U>&&, Args&&...>::valueistrue.*this = nullopt. Then initializes the contained value as if constructing an object oftypeTwith the arguments,ilstd::move(il)std::forward<Args>(args)....[…]-32-Remarks: This function shall not participate in overload resolution unlessis_constructible<T, initializer_list<U>&, Args&&...>::valueistrue.
Section: 16.4.4.6[allocator.requirements]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-09-21Last modified: 2016-01-28
Priority:2
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withNAD status.
Discussion:
C++11's minimized allocator requirements are great, but they're still requiring more things from users than absolutely necessary.
They requireX::value_type, but that can be deduced fromSomeAllocator<T, Args>.
They requirea1 == a2, but that could default totrue as most allocators are stateless.
They requirea1 != a2, but if we start requiring STL implementations to go throughallocator_traits to provide anop== default, we won't need to requireop!= from users at all. (std::allocator, of course, would continue to provideop!=. Note that this is analogous toreference/const_reference —std::allocator still provides them, but we don't require them from users, and in fact we don't require them to be consistent or meaningful if present.)
They requirea == b anda != b. This requirement was not present in C++98/03, it is not necessary (a == b is always required to be equivalent to rebind-then-compare), and STL implementations don't even need to compare allocators of different types directly.
[2014-02-14 Issaquah: Close as NAD]
Different vendors rely on each of the different elements suggested to be removed.
Whilevalue_type my be deduced as suggested, far too much wording relies on it being available,and the standard churn is likely to be much harder than presented here.
Proposed resolution:
This wording is relative to N3691.
Change in 16.4.4.6[allocator.requirements], Table 28 — "Allocator requirements" as indicated:
Table 28 — Allocator requirements (continued) Expression Return type Assertion/note pre-/post-condition Default …X::value_typeIdentical to TSee Note B, below. …a1 == a2boolreturns trueonly if storage
allocated from each can be
deallocated via the other.operator==shall be reflexive,
symmetric, and transitive, and
shall not exit via an exception.truea1 != a2boolsame as!(a1 == a2)a == bboolsame asa ==
Y::rebind<T>::other(b)a != bboolsame as!(a == b)…X a(b);Shall not exit via an exception.
post:Y(a) == b,a == X(b)…X a(move(b));Shall not exit via an exception.
post:aequals the prior value ofX(b).…
After 16.4.4.6[allocator.requirements] p3, add a new paragraph:
Note B: If
Allocatoris a class template instantiation of the formSomeAllocator<T, Args>, whereArgsis zero or more type arguments, andAllocatordoes not supply a nested type namedvalue_type, the standardallocator_traitstemplate usesTin place ofAllocator::value_typeby default. For allocator types that are not template instantiations of the above form, no default is provided.
In the example provided in 16.4.4.6[allocator.requirements]/5, delete as indicated:
template <class Tp>struct SimpleAllocator {typedef Tp value_type; SimpleAllocator(ctor args); template <class T> SimpleAllocator(const SimpleAllocator<T>& other); Tp *allocate(std::size_t n); void deallocate(Tp *p, std::size_t n);};template <class T, class U>bool operator==(const SimpleAllocator<T>&, const SimpleAllocator<U>&);template <class T, class U>bool operator!=(const SimpleAllocator<T>&, const SimpleAllocator<U>&);Edit 20.2.9[allocator.traits]p1, class templateallocator_traits synopsis, as indicated:
namespace std { template <class Alloc> struct allocator_traits { typedef Alloc allocator_type; typedeftypename Alloc::value_typesee below value_type; […] static Alloc select_on_container_copy_construction(const Alloc& rhs);static bool equal(const Alloc& a1, const Alloc& a2) noexcept; };}At the beginning of 20.2.9.2[allocator.traits.types], add a new paragraph:
typedefsee below value_type;Type:
Alloc::value_typeif such a type exists; otherwise,TifAllocis a class template instantiation of the formAlloc<T, Args>, whereArgsis zero or more type arguments; otherwise, the program is ill-formed.
At the end of 20.2.9.3[allocator.traits.members], add a new paragraph:
static bool equal(const Alloc& a1, const Alloc& a2) noexcept;-?-Returns:
a1 == a2if that expression is well-formed; otherwise,true.
basic_string's move constructor should not benoexceptSection: 27.4.3.3[string.cons]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-09-21Last modified: 2017-03-21
Priority:1
View all otherissues in [string.cons].
View all issues withNAD status.
Discussion:
In debugging implementations, containers (includingbasic_string) may need to own dynamically allocated helper objects at all times, including in their default-constructed and moved-from states. This means that their default constructors and move constructors may throw exceptions. Therefore, the Standard should not mark them asnoexcept. (Other implementations will still be permitted to addnoexcept.)
[2014-02, Issaquah : move to Ready]
The issue discussion was highly controversial: The arguments in favour was that implementations exist that always need to allocatememory even for the move operations (similar as for some other containers) and that this cleans up an inconsistency betweenstd::stringand other container types. Counter arguments were that potentially throwing move operations reduce much of the advantages of move-support,e.g. invector<string>.
straw poll: accept wording in the issue
SF 4 WF 4 N 0 WA 1 SA 1
straw poll: 14 or 17?
C++14: 4 C++17: 4
Move to Ready for C++17, as too close to 14 DIS without strong consensus.
It was suggested to introduce a special library vocabulary that specifies a "normative encouragement to not throw exceptions" for functions like these.
NJ: I offer to write a proposal to add encouragement for not throwing ... "noexcept in italics means should not throw"
[2014/11 Urbana]
Resolved by paperN4258
[2015-10]
Richard Smith pointed out thatN4258explicitly decided not to change this call; leaving it as noexcept. In response, I am changing the resolution ofthis issue from 'Resolved' to 'NAD'
Proposed resolution:
This wording is relative to N3691.
In 27.4.3[basic.string]/5, class templatebasic_string synopsis, and 27.4.3.3[string.cons]/2 change as indicated:
basic_string(basic_string&& str)noexcept;
Edit 27.4.3.3[string.cons]/17 as indicated:
basic_string(const basic_string& str, const Allocator& alloc);basic_string(basic_string&& str, const Allocator& alloc);[…]
-17-Throws: The second form throws nothing if.alloc == str.get_allocator().
uniform_int_distribution<unsigned char> should be permittedSection: 29.5.3.1[rand.req.genl]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-09-21Last modified: 2017-02-02
Priority:2
View all otherissues in [rand.req.genl].
View all issues withNAD status.
Discussion:
29.5.3.1[rand.req.genl]/1 says: "Throughout this subclause 26.5, the effect of instantiating a template [...] that has a template type parameter namedIntType is undefined unless the corresponding template argument iscv-unqualified and is one ofshort,int,long,long long,unsigned short,unsigned int,unsigned long, orunsigned long long." 29.5.9.2.1[rand.dist.uni.int] specifiestemplate<class IntType = int> class uniform_int_distribution, so this forbidsuniform_int_distribution<char/signed char/unsigned char>.
<random> that works with 16-bit integers but fails with 8-bit integers, so I suspect thatIntType andUIntType could simply be extended to permit thechar family. Alternatively, this change could be limited touniform_int_distribution alone, where it is definitely safe. A<random> expert should decide which change is best.[2015-04-04 Geoffrey provides wording]
I think it's time to call the question; it's just silly that we have a random number library with no natural way to generate random bytes. However, I don't think it's sufficient to fix onlyuniform_int_distribution, or even all ofIntType. At a bare minimum we need to also fixindependent_bits_engine (arguably the cleanest way of generating a random byte) and that's specified in terms ofUIntType.
unsigned char to item "f" and addingsigned char andunsigned char to item "e". That means it still excludeschar, but I'm OK with that. If you want to generate a 1-byte number, you should probably pick a signedess, and if you want to generate a raw byte, the "true" raw byte type isunsigned char. This also excludes extended integral types and wide char types, which seem like nice-to-haves at best. I have no objection to supporting any of those types; I just picked this to simplify the wording and hopefully maximize consensus. Note that if we want to broadenIntType to permit any integral type, we'll need to decide if we want to excludebool.For reference,IntType is used as a parameter of the following templates:uniform_int_distributionbinomial_distributiongeometric_distributionnegative_binomial_distributionpoisson_distributiondiscrete_distribution
andUIntType is used as a parameter of the following templates:
linear_congruential_enginemersenne_twister_enginesubtract_with_carry_engineindependent_bits_engine
[2015-9-11, Telecon]
Walter feels very strongly that this is not a defect, but a feature request.
In a previous telecon, Aaron offered to write a paper proposing this.
Jonathan offered to help.
Closing as NAD
Proposed resolution:
This wording is relative to N4296.
Change in 29.5.3.1[rand.req.genl] p1 as indicated:
-1- Throughout this subclause 26.5, the effect of instantiating a template:
[…]
that has a template type parameter namedIntType is undefined unless the corresponding templateargument is cv-unqualified and isa standard integer type (6.9.2[basic.fundamental])one of.short,int,long,long long,unsigned short,unsigned int,unsigned long, orunsigned long long
that has a template type parameter namedUIntType is undefined unless the corresponding templateargument is cv-unqualified and isa standard unsigned integer type (6.9.2[basic.fundamental])one of.unsigned short,unsigned int,unsigned long, orunsigned long long
Section: 29.5.3.3[rand.req.urng]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-09-21Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [rand.req.urng].
View all issues withNAD status.
Discussion:
29.5.3.3[rand.req.urng] allows URNGs with non-power-of-two (NPOT) ranges, like[0, 1729]. This is unnecessarily permissive (I cannot imagine a realistic source of randomness that would generate such a range) and has real costs for implementers, asuniform_int_distribution must be prepared to accept such URNGs. The most efficient way to accumulate randomness is to concatenate random bits, so NPOT randomness is not just useless, it is actively harmful (to avoid bias, if a URNG generates a random number outside of a power-of-two range, the number must be discarded).
min() to be0, but this is not necessary; it is simple for implementations to sayg() - G::min() and this will optimize away ifmin() is0. (It is vaguely plausible for a URNG to have a nonzero minimum; I can imagine something that simply masks off low-order bits without shifting the rest downwards.) What is important is for the entire range to have a power-of-two width;[1729, 1984] is acceptable as its size is 256.[2013-10-12: Howard presents a counterexample]
Consider:
#include <random>#include <string>#include <iostream>template <class Int>bool is_power_2m1(Int i){ return (i & (i + 1)) == 0;}template <class URNG>void test(const std::string& urng){ using namespace std; typename URNG::result_type rng = URNG::max() - URNG::min(); if (!is_power_2m1(rng)) { cout << hex; cout << urng << " : min = " << URNG::min() << ", max = " << URNG::max() << ", max-min = " << rng << '\n'; }};int main(){ using namespace std; test<minstd_rand0>("minstd_rand0"); test<minstd_rand>("minstd_rand"); test<mt19937>("mt19937"); test<mt19937_64>("mt19937_64"); test<ranlux24_base>("ranlux24_base"); test<ranlux48_base>("ranlux48_base"); test<ranlux24>("ranlux24"); test<ranlux48>("ranlux48"); test<knuth_b>("knuth_b");}Which for me outputs:
minstd_rand0 : min = 1, max = 7ffffffe, max-min = 7ffffffdminstd_rand : min = 1, max = 7ffffffe, max-min = 7ffffffdknuth_b : min = 1, max = 7ffffffe, max-min = 7ffffffd
We do not want to outlaw these three URNG's, and the proposed wording would do that.
[Issaquah 2014-02-10: Moved to NAD]
STL withdraws the issue, non-power-of-2 URNGs are used in the field, it is too late to consider removing them.
Proposed resolution:
This wording is relative to N3691.
Add a new paragraph at the end of 29.5.3.3[rand.req.urng] as indicated:
-3- The following relation shall hold:
-?-G::min() < G::max().G::max() - G::min()shall be 2n- 1 for somen > 0.
array<array<int, 3>, 4> should be layout-compatible withint[4][3]Section: 23.3.3[array]Status:NADSubmitter: Jeffrey YasskinOpened: 2013-10-04Last modified: 2020-11-09
Priority:3
View all otherissues in [array].
View all issues withNAD status.
Discussion:
In order to replace some uses of C arrays withstd::array, we need itto be possible to cast from astd::array<> to an equivalent C array.Core wording doesn't appear to be in quite the right state to allowcasting, but if we specify that appropriate types arelayout-compatible, we can at least write:
union { array<array<array<int, 2>, 3>, 4> arr; int carr[4][3][2];};to view memory as the other type: C++14 CD [class.mem]p18.
I believe it's sufficient to add "array<T, N> shall belayout-compatible (6.9[basic.types]) withT[N]." to 23.3.3.1[array.overview], but we might also need some extension to 11.4[class.mem] to address the possibility of layout-compatibility between struct and array types.I checked that libc++ on MacOS already implements this, although itwould be good for someone else to double-check; I haven't checked anyother standard libraries.
[2020-02-14, Prague]
LWG discussions and decision for NAD.
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Rationale:
The desire to usestd::array like this seems like an "XY problem". The goal should be "replace C arrays" not "replace C arrays withstd::array", becausestd::array is not suitable here. There are superior solutions being proposed, and will be available in a future version of C++ (e.g. usingmdspan as a multi-dimensional view on an array).Proposed resolution:
shared_ptr operator*() should not benoexceptSection: 20.3.2.2.6[util.smartptr.shared.obs]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-10-05Last modified: 2017-07-17
Priority:2
View all otherissues in [util.smartptr.shared.obs].
View all issues withNAD status.
Discussion:
20.3.1.3.5[unique.ptr.single.observers]/3: "pointer operator->() const noexcept;Requires:get() != nullptr."
T& operator*() const noexcept;Requires:get() != 0."20.3.2.2.6[util.smartptr.shared.obs]/5: "T* operator->() const noexcept;Requires:get() != 0."Narrow-contract functions should not benoexcept.[2014-02-15 Issaquah]
Issue is contentious, raise to P2.
[2015-02 Cologne]
AM: This ship has sailed. JM: What's the issue? AM:operator-> has narrow contract and should never have hadnoexcept. DK: Not quite. We explicitly called out that forshared_ptr this is fine. You said so in your "narrow contract" paper. GR: This would be a fairly major regression in the design of {unique,shared}_ptr over raw pointers; raw pointer dereferencing isnoexcept. It's not a performance regression but a usability regression. AM: Do we expect users to querynoexpect on dereference expressions? Room: Yes. VV: We don't just expect it, we have seen it. JM: Yes, users may be querying something likenoexcept(x->y) and expect to be checkingy, but silently end up checkingx->.
This wording is relative to N3691.
In 20.3.1.3[unique.ptr.single]/1, class template
unique_ptrsynopsis for single objects, change as indicated:pointer operator->() constnoexcept;In 20.3.1.3.5[unique.ptr.single.observers] change as indicated:
pointer operator->() constnoexcept;-3-Requires:
-4-Returns:get() != nullptr.get().-?-Throws: Nothing.-5-Note: use typically requires thatTbe a complete type.In 20.3.2.2[util.smartptr.shared]/1, class template
shared_ptrsynopsis, change as indicated:T& operator*() constnoexcept;T* operator->() constnoexcept;In 20.3.2.2.6[util.smartptr.shared.obs] change as indicated:
T& operator*() constnoexcept;-2-Requires:
-3-Returns:get() != 0.*get().-?-Throws: Nothing.-4-Remarks: WhenTisvoid, it is unspecified whether this member function is declared. If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily thedefinition) of the function shall be well formed.T* operator->() constnoexcept;-5-Requires:
-6-Returns:get() != 0.get().-?-Throws: Nothing.
[2015-03-03, Geoffrey provides rationale]
Rationale:
It is by design that these members are
It is notable that N3279, which proposed this policy, did not propose strikingnoexcept, and changing that now would be a substantial regression in functionality. These classes were designed to substitute for plain pointers as transparently as possible, so since those operations are effectivelynoexcepton plain pointers, they should benoexceptonunique_ptrandshared_ptras well. This matters in practice because we expect these members to be used fairly often inside thenoexceptoperator, and such code could be broken by this change. These design considerations override our general policy againstnoexceptfor narrow-contract functions.noexceptfrom these operations. It's not clear if the omission ofoperator*andoperator->was an oversight, or an intentional reflection of the above considerations. N3279 was based on N3248 by the same authors, which states that:"Most applications of
noexceptforunique_ptrandshared_ptrare on functions with wide contracts. However, there are preconditions on the atomic access functions, so these should lose the specification."
Proposed resolution:
integer_sequence should have a self-typedef::typeSection: 21.2.2[intseq.intseq]Status:NADSubmitter: Stephan T. LavavejOpened: 2013-11-01Last modified: 2016-01-28
Priority:2
View all issues withNAD status.
Discussion:
21.3.4[meta.help] says thatintegral_constant<T, v> provides::value_type (forT) and::type (for itself).
integer_sequence<T, I...> provides::value_type (forT), but nothing for itself.Self-typedefs can be useful when users create chains of derived classes, then want to get the Standard base type. This is especially relevant tointeger_sequence, as variadic templates encourage recursive inheritance.[2014-02-13 Issaquah: Close as NAD]
AJM: My own implementation used a different alias for types representing parameter packs, and specificallydidnot definetype. I tried it both ways, and found bugs more quickly whentype wasnot defined.
Proposed resolution:
This wording is relative to N3797.
Edit 21.2.2[intseq.intseq] as indicated:
namespace std { template<class T, T... I> struct integer_sequence { typedef T value_type;typedef integer_sequence<T, I...> type; static constexpr size_t size() noexcept { return sizeof...(I); } };}reverse_iterator::operator[] calls const version ofcurrent[]Section: 24.5.1.6[reverse.iter.elem]Status:NADSubmitter: Timo BingmannOpened: 2013-11-11Last modified: 2021-06-06
Priority:2
View all otherissues in [reverse.iter.elem].
View all issues withNAD status.
Discussion:
Currentlyreverse_iterator::operator[]() returns "current[-n-1]" and hasan "unspecified" return type.
Iterator is a mutable random access iterator, the expression"current[-n-1]" calls "Iterator::operator[] const", which returns aconst reference. This const reference cannot be converted back to amutable reference.This issue is related to the "unspecified" return value ofreverse_iterator::operator[], see defect386(i).The -1 is due to "current" pointing one item beyond thereverse_iterator's real current value.The current libstdc++ implementation reads "*(current + n)" forreverse_iterator::operator[].This copiedcurrent, advances (backwards) viaoperator+ anddereferences. It bypasses the issues due toreverse_iterator::operator[]being const by copying the iterator.[2014-02-13 Issaquah : close as NAD]
Proposed resolution:
This wording is relative to N3797.
Edit 24.5.1.2[reverse.iterator], class templatereverse_iterator synopsis, as indicated:
namespace std { template <class Iterator> class reverse_iterator : public iterator<typename iterator_traits<Iterator>::iterator_category, typename iterator_traits<Iterator>::value_type, typename iterator_traits<Iterator>::difference_type, typename iterator_traits<Iterator>::pointer, typename iterator_traits<Iterator>::reference> { public: […]unspecifiedreference operator[](difference_type n) const; […] }; […]}Edit [reverse.iter.opindex] as indicated:
unspecifiedreference operator[]( typename reverse_iterator<Iterator>::difference_type n) const;-1-Returns:
.current[-n-1]*(current + n)
.seed() completely reset state of engine?Section: 29.5.4[rand.eng]Status:NADSubmitter: Thomas PlumOpened: 2013-12-02Last modified: 2016-01-28
Priority:2
View all otherissues in [rand.eng].
View all issues withNAD status.
Discussion:
With regard to Random number engine class templates 29.5.4[rand.eng],the Standard can be read in two different ways: when the member function
.seed(result_type s = default_seed)
is invoked, is all associated state (such as carry) reset to the samestate that would have been created by the constructor
explicitengine-type(result_type s = default_seed)
or is the exact state unspecified?
Implementations differ.[2014-02-13, Issaquah]
Walter Brown says that Table 117 makes this very clear, and that the answer is "Yes"
Suggested resolution: NAD[2015-05-05 Lenexa: Move to NAD]
Proposed resolution:
Suggested resolution: NAD
std::seed_seq intended to produce a predictable.generate()?Section: 29.5.8.1[rand.util.seedseq]Status:NADSubmitter: Thomas PlumOpened: 2013-12-02Last modified: 2022-08-24
Priority:2
View all otherissues in [rand.util.seedseq].
View all issues withNAD status.
Discussion:
With respect to classseed_seq 29.5.8.1[rand.util.seedseq], is a default-constructedstd::seed_seq intended to produce a predictable.generate() sequence?
[2014-02-10]
Priority set to 2
[2022-08-24 Status changed: New → NAD.]
Discussed in LWG telecon.The default constructor effects are clear. Implementations agree.
Proposed resolution:
"s" UDL suffix should be reserved for a compile-time string library typeSection: 27.4.7[basic.string.literals]Status:NADSubmitter: Michael PriceOpened: 2014-01-18Last modified: 2016-01-28
Priority:1
View all issues withNAD status.
Discussion:
The current draft uses the"s" UDL suffix as a UDL forbasic_string<charT> (27.4.7[basic.string.literals]). In light of EWG active issue66 (concerning N3599), the"s" suffix (when applied to character string literals) should be reserved for a compile-time string library type.
[Issaquah 2014-10-12: Move to NAD]
We discussed leaving thes UDL suffix forstring_view in Portland, and voted strongly in favor of using it forstd::string.string is also an extremely widely used type, and the difference is observable in type deduction cases.In addition, a compile-time string is likely to cost significant compile time, which we don't want to make the default withs.
| SF | F | N | A | SA |
| 8 | 4 | 0 | 2 | 0 |
Proposed resolution:
std::stringSection: 27.4.3[basic.string]Status:NADSubmitter: Andrzej KrzemieńskiOpened: 2014-03-13Last modified: 2018-06-23
Priority:4
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD status.
Discussion:
The following code works in C++:
int i = 300;std::string threeHundred;threeHundred = i;
"Works" == "Compiles and doesn't have an undefined behavior". But it may not be obvious and in fact misleading what it does. This assignment converts anint tochar and then usesstring's assignment fromchar. While the assignment fromchar can be considered a feature, being able to assign from an int looks like a safety gap. Someone may believe C++ works like "dynamically typed" languages and expect a lexical conversion to take place.
char could be deprecated and later removed, but as a less intrusive alternative one could consider adding a SFINAEd deleted function template:template <typename IntT> // enable if is_integral<IntT>::valuebasic_string& operator=(IntT) = delete;
[Lenexa 2015-06-06: Move to LEWG]
RS:std::string x('0' + n); broken by this.
MC: This is an extension, move to LEWG.
Move to LEWG, consensus.
Previous resolution [SUPERSEDED]:
This wording is relative to N3936.
To 27.4.3[basic.string], class template
basic_stringsynopsis, add as indicated:basic_string& operator=(const basic_string& str);basic_string& operator=(basic_string&& str) noexcept;basic_string& operator=(const charT* s);basic_string& operator=(charT c);template <class IntT> basic_string& operator=(IntT i) = delete;basic_string& operator=(initializer_list<charT>);Add after 27.4.3.3[string.cons] p26 as indicated:
basic_string& operator=(charT c);-26-Returns:
*this = basic_string(1,c).template <class IntT> basic_string& operator=(IntT i) = delete;-?-Remarks: This signature shall not participate in overload resolution unless
is_integral<T>::valueistrue.
[LEWG: 2016-03, Jacksonville]
is_integral<T>::value →is_arithmetic<tmpl-arg>::value
+= andpush_back.Proposed resolution:
This should be addressed by a paper addressed to LEWG.
std conforming extensionsSection: 16.4.6[conforming]Status:NADSubmitter: Chandler CarruthOpened: 2014-03-22Last modified: 2015-05-22
Priority:3
View all otherissues in [conforming].
View all issues withNAD status.
Discussion:
Technically, right now, it is not a conforming extension to add a new function to namespacestd. Doing so could cause unqualified lookup on the name of that function in the presence of a using directive to find a different function. This seems an unreasonable restriction on library vendors providing conforming extensions, as such a using directive seems inherently risky in unqualified name lookup.
16.4.6.5[member.functions] implies that adding overloads to a methodis a conforming extension, and within some limits the same is true for global functions due to 16.4.6.4[global.functions].
It would likely be useful to specify that other new entities are valid conforming extensions, or preclude them where they pose serious compatibility problems.[Lenexa 2015-05-06: Move to NAD]
JY: It's a design question, move to LEWG?
AM: NAD: extensions led to us being unable to use the names hash_map, leading to unordered_map etc. Will result in collisions between members.
MC: Agrees, implementations that extend std:: must use __ugly_names for this reason.
JY: I would not oppose NAD.
Move to NAD, consensus.
Proposed resolution:
Section: 32.2.3[thread.req.native], 32.4.5[thread.thread.this]Status:NADSubmitter: Matt AusternOpened: 2014-03-31Last modified: 2015-10-21
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Classthread contains an implementation-defined typethread::native_handle_type, and an implementation-defined functionthread::native_handle() that returns a value of that type. The presence and semantics of those members is implementation-defined; the intention is that they can be used for interoperability with libraries that rely on operating system specific features. (Posix libraries that accept arguments of typepthread_t, for example.)
pthread_self(). We can usethis_thread::get_id() to obtain thethread::id of the current thread, but there is no mechanism for converting athread::id to athread::native_handle.Proposed wording:In 32.4.5[thread.thread.this] add:thread::native_handle_type native_handle();// See 30.2.3
to thethis_thread namespace synopsis.
this_thread or by providing a mechanism for converting betweenthread::id andthread::native_handle. I propose the former because it seems more localized, and doesn't involve saying anything more about implementation defined native functionality than we currently do.It's intentional that the proposed resolution adds a declaration ofnative_handle() without adding a paragraph explaining what it does. This is because everything aboutnative_handle() is implementation-defined. The standard does the same thing in 32.4.3.6[thread.thread.member].[2015-02 Cologne]
Handed over to SG1.
[2015-05 Lenexa, SG1 response]
Strong "don't care" reaction from SG1, after pointing out that this only matters in non-portable code, which can call pthread_self() or the like anyway, but the change also doesn't add any non-trivial implementation requirements. This defused initial strong opinions on both sides. Since this is essentially a feature request, we did not have sufficient consensus to proceed at this point. There was a feeling we should reconsider after making more sense out of the much more general TLS issues we have been discussing.
Proposed resolution:
This wording is relative to N3936.
Change 32.2.3[thread.req.native] p1 as indicated:
-1-
Several classes described in this Clause have membersThis Clause includes several members namednative_handle_typeandnative_handle. The presence of these members and their semantics is implementation-defined. […]
In 32.4[thread.threads], header<thread> synopsis, add:
namespace std { […] namespace this_thread { thread::id get_id() noexcept;thread::native_handle_type native_handle(); […] }}In 32.4.5[thread.thread.this] add:
namespace std { namespace this_thread { thread::id get_id() noexcept;thread::native_handle_type native_handle();// See 32.2.3[thread.req.native] […] }}Section: 16.4.6.9[reentrancy]Status:Pending NADSubmitter: Peter KastingOpened: 2014-05-06Last modified: 2014-11-04
Priority:2
View all otherissues in [reentrancy].
View all issues withPending NAD status.
Discussion:
The standard does not seem to discuss reentrant access to a container during removal of an element, leaving it unclear whether a removed object is destroyed before or after it is removed from the container. For example, the behavior of the following code seems to be unspecified:
#include <iostream>#include <map>#include <memory>struct T;typedef std::map<int, std::shared_ptr<T>> TMap;struct T { T(TMap* t_map, int index) : t_map(t_map), index(index) {} ~T() { std::cout << "Object " << index << " is "; if (t_map->count(index)) std::cout << "destroyed before being removed from the map" << std::endl; else std::cout << "removed from the map before being destroyed" << std::endl; } static void AddToMap(TMap* map, int index) { (*map)[index] = std::make_shared<T>(map, index); } TMap* t_map; int index;};int main(){ TMap t_map; T::AddToMap(&t_map, 0); T::AddToMap(&t_map, 1); t_map.erase(1); t_map.erase(0);}The output of this program in Visual Studio 2013 is:
Object 1 is removed from the map before being destroyedObject 0 is destroyed before being removed from the map
The core issue here is whether an object removed from a container should be destroyed before or after it is removed from the container. The current standard seems to be silent on this issue. The above output demonstrates that the behavior is actually inconsistent. (It's difficult to fully describe Visual Studio's behavior; for example, changingmain() in the above example to the following:)
int main(){ TMap t_map; T::AddToMap(&t_map, 0); T::AddToMap(&t_map, 1); T::AddToMap(&t_map, 2); T::AddToMap(&t_map, 3); t_map.erase(3); t_map.clear();}(...gives this output:)
Object 3 is removed from the map before being destroyedObject 2 is destroyed before being removed from the mapObject 1 is destroyed before being removed from the mapObject 0 is removed from the map before being destroyed
In my opinion, the standard should explicitly describe when objects are destroyed as part of removal from a container. To me, it makes the most sense to say that objects should be removed from the container before they are destroyed.
[2014-05-07, Jeffrey Yasskin comments]
I think there are two main points here beyond this writeup:
We can't make recursive use of a standard library container validin all cases.
If recursion through especiallyerase() is undefined behavior,that's pretty scary for existing large applications with code indestructors. Of course, "scary" doesn't mean we have to define thebehavior.
I'll add a third: The language in 16.4.6.9[reentrancy] nearly makes thisundefined behavior already. I think any fix is probably going to livethere, and extend the current "implementation-defined" on recursivereentrancy for individual functions to recursive reentrancy on classinstances. I'm not sure exactly how to word that.
[2014-06 Rapperswil]
STL: We need more wording about how container methods can be reentrency.
Jeffrey: The title for this issue is confusing, what we really want is "reentrancy for objects".Alisdair: Should we then close 2382 as NAD with a link to the new issue?Proposed resolution:
function::operator= handles allocators incorrectlySection: 22.10.17.3.2[func.wrap.func.con]Status:NADSubmitter: Pablo HalpernOpened: 2014-05-23Last modified: 2015-05-05
Priority:1
View all otherissues in [func.wrap.func.con].
View all issues withNAD status.
Discussion:
TheEffects clauses for the assignment operator for class templatefunction arewritten as code that constructs a temporaryfunction and then swaps it with*this.The intention appears to be that assignment should have the strong exception guarantee, i.e.,*this is not modified if an exception is thrown. However, the current description is incorrect when*this was constructed using an allocator.
swap, which does not state the allocator requirements or allocator postconditions. Ifswap behaves like the rest of the standard library, swapping function objects constructed with different allocators would be undefined behavior. Alternativelyswap could exchange the allocators, though I would argue against this specification.For either specification ofswap, the currentEffects clauses foroperator= areincorrect. Ifswap does not exchange the allocators, thenoperator= would have undefined behavior, which is clearly not desired. Ifswap does exchange the allocators, thenoperator= would always leave the left-hand side (lhs) of the assignment with a default allocator. The latter would be surprising behavior, as the allocator instance is normally unchanged for the lifetime of an object (for good reason), and is certainly not reset to default arbitrarily.The desired behavior is that assignment would leave the allocator of the lhsunchanged. The way to achieve this behavior is to construct the temporaryfunction using the original allocator. Unfortunately, we cannot describe the desired behavior in pure code, because there is no way to name the type-erased value of the allocator. (N3916 would improve this situation for the Library Fundamentals TS, but even with those changes, there is no way to recover the original type of the allocator.) The PR below, therefore, uses pseudo-code, inventing a fictitiousALLOCATOR_OF(f) expression that evaluates to the actual allocator type, even if that allocator was type erased. I have implemented this PR successfully.Previous resolution [SUPERSEDED]:
This wording is relative to N3936.
Change 22.10.17.3.2[func.wrap.func.con] as indicated:
In the following descriptions,
ALLOCATOR_OF(f)is a copy of the allocator specified in the construction offunctionf, orallocator<char>()if no allocator was specified.function& operator=(const function& f);-12-Effects:
-13-Returns:function(allocator_arg,ALLOCATOR_OF(*this), f).swap(*this);*thisfunction& operator=(function&& f);-14-Effects:
-15-Returns:Replaces the target of*thiswith the target off.function(allocator_arg,ALLOCATOR_OF(*this), std::move(f)).swap(*this);*thisfunction& operator=(nullptr_t);-16-Effects: If
-17-Postconditions:*this != nullptr, destroys the target ofthis.!(*this).The allocator is unchanged.-18-Returns:*this-?-Throws: Nothing.template<class F> function& operator=(F&& f);-19-Effects:
-20-Returns:function(allocator_arg,ALLOCATOR_OF(*this), std::forward<F>(f)).swap(*this);*this-21-Remarks: This assignment operator shall not participate in overload resolution unlessdeclval<typename decay<F>::type&>()isCallable(20.9.11.2) for argument typesArgTypes...and return typeR.template<class F> function& operator=(reference_wrapper<F> f);-22-Effects:
-23-Returns:function(allocator_arg,ALLOCATOR_OF(*this), f).swap(*this);*this
[2015-05, Lenexa]
STL: think this is NAD, don't think this is implementable or even should be.
STL: think this issue should be dealt with the same as 2370, don't think this should be done ever.
STL: NAD because there is nothing broken here.
STL: already fixedoperator= noexcept soThrows nothing is not needed
STL: nothing to salvage here
MC: consensus for NAD
Proposed resolution:
There was consensus by the committee that the issue does not constitute as defect.
std::exchangeSection: 22.2.3[utility.exchange]Status:NADSubmitter: Nick CalusOpened: 2014-05-09Last modified: 2015-05-05
Priority:2
View all otherissues in [utility.exchange].
View all issues withNAD status.
Discussion:
In paperN3668, the addition of a template functionstd::exchange had been proposed. In the rationale provided by the paper, we find the following:
I chose the name for symmetry with
atomic_exchange, since they behave the same except for this function not being atomic.
and:
Atomic objects provide an
But the specified semantics ofatomic_exchangefunction ([atomics.types.operations.req]p18) thatassigns a new value to the object and returns the old value. This operation is also useful on non-atomic objects, and this paper proposes adding it to the library.std::exchangeis defined as follows:
template <class T, class U=T> T exchange(T& obj, U&& new_val);Effects: Equivalent to:
T old_val = std::move(obj);obj = std::forward<U>(new_val);return old_val;
When looking at the post-condition of thestd::exchange function, one would expect the return value to be the old value ofobj and also thatobj now contains the value ofnew_value.This post-condition is violated whenobj is a reference to the same object asnew_value and typeT has move semantics.
std::exchange is meant to be used with types that have move semantics.Therefore, the post-condition is violated for self-assignments.Suppose the following situation:You have a vector of objects. The objects implement move semantics and are emptied when moved from.You provide a function that allows you to replace an object at a specific index by a new object (provided by reference as an argument to your function). When replacing an object, your function calls a member-functiondo_something_fancy on the old object.void your_function(int i, X& new_val) { std::exchange(vec[i], new_val).do_something_fancy();}Your function gets called with a given index and the corresponding element of said vector. (by coincidence or by purpose, it doesn't really matter)
your_function(5, vec[5]);
This will cause the object atvec[5] to be in an empty state.If this object would not implement move semantics, assignment performance is potentially worse, but at least it is not in an empty (to my business logic, invalid) state.
std::exchange does not have the behavior it is expected to have.[2014-12-18 Telecon]
MC: does this resolution solve the problem?
JW: and is the cost of the extra construction and move acceptable?AM: not all moves are cheapVV: seems like a design changeJW: maybe this should be rolled into my unwritten paper on self-swap, so we deal with them consistentlyVV: we should update the issue saying something like that and maybe NAD FutureMC: instead, add Requires clause saying the arguments are not the same.JW: interesting, that can even be checked in a debug mode assertionMC: ACTION: send alternative P/R that we can considerPrevious resolution [SUPERSEDED]:
This wording is relative to N3936.
Change 22.2.3[utility.exchange] as indicated:
template <class T, class U=T> T exchange(T& obj, U&& new_val);-1-Effects: Equivalent to:
T tmp = std::forward<U>(new_val);T old_val = std::move(obj);obj =std::forward<U>(new_val)std::move(tmp);return old_val;
Previous resolution from Marshall [SUPERSEDED]:
This wording is relative to N4296.
Change 22.2.3[utility.exchange] as indicated:
template <class T, class U=T> T exchange(T& obj, U&& new_val);-?-Requires:
-1-Effects: Equivalent to:objandnew_valshall not refer to the same object.T old_val = std::move(obj);obj = std::forward<U>(new_val);return old_val;
[2015-03-30, Marshall provides alternative wording]
[2015-05, Lenexa]
MC: selfexchange does not work
MC: PR is just to add requires
STL: what if the new thing is a subobject, isn't that just as bad, any aliasing
STL: don't know that we need to do anything here if we aren't changing the implementation
NM: should remove the requires
MC: so NAD
STL: could add note
NM: remove requires
DK: requires isn't already there
RL: no note?
STL: no note, NAD, burden for next person that asks about aliasing
DK: what do we do forswap?
STL: selfswap has always been noop,exchange could do something bad because it clears out
MC: alright, NAD it is
Proposed resolution:
The current specification is clear about the implications described by the issue example and is as intended.basic_string(const basic_string& str, size_type pos, size_type n = npos) shouldn't useAllocator()Section: 27.4.3.3[string.cons]Status:NADSubmitter: Stephan T. LavavejOpened: 2014-06-14Last modified: 2023-08-06
Priority:3
View all otherissues in [string.cons].
View all issues withNAD status.
Discussion:
27.4.3.3[string.cons] p3 specifies:
basic_string(const basic_string& str, size_type pos, size_type n = npos, const Allocator& a = Allocator());But this implies that
27.4.3.2[string.require] p3 says "Thebasic_string(str, pos)andbasic_string(str, pos, n)useAllocator()instead of getting an allocator fromstr.Allocatorobject used shall be obtained as described in 23.2.1." 23.2.2[container.requirements.general] p8 says "Copy constructors for these container types obtain an allocator by callingallocator_traits<allocator_type>::select_on_container_copy_constructionon the allocator belonging to the container being copied.", but this isn't exactly a copy constructor. Then it talks about move constructors (which this definitely isn't), and finally says that "All other constructors for these container types take aconst allocator_type&argument. […] A copy of this allocator is used for any memory allocation performed".
[2015-05-06 Lenexa: move to Open]
STL: there an allocator right there in str, why default-construct one
STL: my fix, which may not be right, splits out functions with and without allocators
JW: there are other ways to propagate the allocator from str to the new object
PJP: hard to get motivated about this one
JW: I think this is not a copy operation, this is init'ing a string from a range of characters which happens to originate in a string. It makes it inconsistent with the similar ctor taking a const char pointer, and if we had a std::string_view we wouldn't even have this ctor, and it wouldn't be possible to propagate the allocator.
STL: but people with stateful allocators want it to propagate
JW: I think the people using stateful allocators will alter the default behaviour of select_on_container_copy_construction so that it doesn't propagate, but will return a default-constructed one (to ensure a stateful allocator referring to a stack buffer doesn't leak to a region where the stack buffer has gone). So for those people, your proposed change does nothing, it changes one default-constructed allocator to a call to select_on_container_copy_construction which returns a default-constructed allocator. For other people who have different stateful allocators they can still provide the right allocator (whatever that may be) by passing it in.
STL: OK, that's convincing.
PJP: I agree with Jonathan
JW: would like to run both our arguments by Pablo in case I'm totally misrepresenting the expected users of allocator-traits stuff
[2015-10, Kona Saturday afternoon]
Everyone thinks this seems right.
STL: It'd be really weird if you copy from a string with a stateful allocator and you'd just default-construct a new allocator.
EF: We definitely need this for polymorphic allocators.
TK: Whether you think this is kind of copy-constructor or a constructor from raw string data, the new form in the PR is more flexible. You can still get the default-constructed allocator if you want, but conversely, getting the select_on_container_copy is really hard to type in the old form.
JW has objections (written in the issue) but won't block "Review" status.
Move to Review, hopefully to be made ready at a telecon.
[2015-11-22, Pablo comments]
I like the direction of the PR, but it is incomplete. Consider the following (assuming the PR):
typedef basic_string<char, char_traits<char>, A<char>> stringA;vector<stringA, scoped_allocator_adaptor<A<stringA>>> vs;stringA s;vs.emplace_back(s, 2); // Ill-formed
The problem is that uses-allocator construction requires that we be able to pass an allocator to the constructorstringA(s, 2, allocator), but no such constructor exists. I think this defect already exists, but we should fix it a the same time that we fix 2402. So, I would say we need a third constructor:
basic_string(const basic_string& str, size_type pos, const Allocator& a);
[2016-01-05, Pablo comments]
I've reconsidered and I think that the issue as stated, is NAD. I do not like the PRat all. In fact, I think it reverses a previous fix and it could break existing code.
There are two patterns that are at work here:Every constructor needs a version with and without an allocator argument (possibly through the use of default arguments).
Every constructor except the copy constructor for which an allocator is not provided uses a default-constructed allocator.
The constructors in question are not copy constructors. I do not think it is compelling that the allocator should come from its argument any more than it should come from any other object that happens to supply characters for a string constructor.
[2016-03 Jacksonville]
Closed as NAD, noting that2583(i) is a related issue.
[2023-08-5; Arthur O'Dwyer comments]
P2438 added a constructor frombasic_string&& which also default-constructs the allocator. JW's second argument above ("[the] proposed change does nothing") does not apply after P2438, but his first ("this is not a copy operation") is unchanged.
Previous resolution [SUPERSEDED]:
This wording is relative toN3936.
Change 27.4.3[basic.string] p5, class template
basic_stringsynopsis, as indicated:[…]// 21.4.2, construct/copy/destroy:[…]basic_string(basic_string&& str) noexcept;basic_string(const basic_string& str, size_type pos, size_type n = npos);basic_string(const basic_string& str, size_type pos, size_type n= npos, const Allocator& a= Allocator());[…]Change 27.4.3.3[string.cons] around p3 as indicated:
basic_string(const basic_string& str, size_type pos, size_type n = npos);basic_string(const basic_string& str, size_type pos, size_type n= npos, const Allocator& a= Allocator());[…]
-5-Effects: Constructs an object of classbasic_stringand determines the effective lengthrlenof theinitial string value as the smaller ofnandstr.size() - pos, as indicated in Table 65.The first constructor obtains an allocator by callingallocator_traits<allocator_type>::select_on_container_copy_constructionon the allocator belonging tostr.Table 65 —basic_string(const basic_string&, size_type, size_type)andbasic_string(const basic_string&, size_type, size_type, const Allocator&)effects
Proposed resolution:
The existing wording is intended.
rotate()'s return value is incorrect whenmiddle == firstSection: 26.7.11[alg.rotate]Status:NADSubmitter: Stephan T. LavavejOpened: 2014-06-14Last modified: 2014-06-17
Priority:Not Prioritized
View all otherissues in [alg.rotate].
View all issues withNAD status.
Discussion:
When LWG488(i) was resolved, the intention was to return "where the subrange[first, middle) starts after the rotate is performed". However, this wasn't achieved in one case.
middle == last,rotate() does nothing and returnsfirst. This is good.Whenmiddle == first,rotate() does nothing and returnslast. This is bad. In addition to being inconsistent with the other do-nothing case, it preventsrotate() from providing the useful guarantee that LWG488(i) wanted: when[first, last) is non-empty,rotate()'s return value should always be dereferenceable to get the originally-first element.Howard Hinnant:As the author of LWG488(i) I can assure everyone that the edge cases the proposed resolution specifies were not specified by accident.rotate(i, i, j) should returnj androtate(i, j, j) should returni. Doing otherwise will break working code. These return values were motivated by the uses ofrotate in the implementation of algorithms such asstable_partition andinplace_merge. The results of these edge cases were not chosen lightly.Also a good read:notes-on-programming-2006-10-13Summary: NAD.[2014-06-16 Rapperswill]
Closed as NAD.
Proposed resolution:
This wording is relative to N3936.
Change 26.7.11[alg.rotate] p2 as indicated:
-2-Returns:If
middle == first, returnsfirst. Otherwise, returnsfirst + (last - middle).
assert macro is overconstrainedSection: 19.3[assertions]Status:NADSubmitter: David KraussOpened: 2014-06-25Last modified: 2023-06-13
Priority:4
View all otherissues in [assertions].
View all issues withNAD status.
Discussion:
WhenNDEBUG is defined,assert must expand exactly to the token sequence((void)0), with no whitespace (C99 §7.2/1 and also C11 §7.2/1). This is a lost opportunity to pass the condition along to the optimizer.
#define directive. There is little chance of practical code doing such things. It's reasonable to allow any expansion that is avoid expression with no side effects or semantic requirements, for example, an extension keyword or an attribute-specifier finagled into the context.Conforming optimizations would still be limited to treating the condition as hint, not a requirement. Nonconformance on this point is quite reasonable though, given user preferences. Anyway, it shouldn't depend on preprocessor quirks.As for current practice, Darwin OS<assert.h> provides a GCC-style compiler hint__builtin_expect but only in debug mode. Shouldn't release mode preserve hints?Daniel:The corresponding resolution should take care not to conflict with the intention behind LWG2234(i).[2023-06-13, Varna; Status changed: New → NAD.]
Only observable by stringifying an assert expression anyway,so arguably allowed by implementations anyway.Needs a paper to make changes here, or incorporate intoP2884.
Proposed resolution:
std::experimental::optional::operator< andLessThanComparable requirementSection: 5.7[fund.ts.v2::optional.relops], 5.9[fund.ts.v2::optional.comp_with_t]Status:NADSubmitter: Daniel KrüglerOpened: 2014-06-20Last modified: 2025-03-13
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: fund.ts.v2
Currently,std::experimental::optional::operator== imposes theEqualityComparable requirement which providestwo guarantees: It ensures thatoperator!= can rely on the equivalence-relation property and more importantly, thattheBooleanTestable requirements suggested by issue2114(i) are automatically implied.
std::experimental::optional::operator< doesn't provide aLessThanComparable requirement, but there was quitean historic set of changes involved with that family of types: As ofN3527this operator was defined in terms ofoperator< of the contained typeT and imposed theLessThanComparablerequirement. In the final acceptance step ofoptional by the committee, the definition was expressed in terms ofstd::lessand theLessThanComparable requirement had been removed.The inconsistency betweenoperator== andoperator< should be removed. One possible course of action would beto add theLessThanComparable tostd::experimental::optional::operator<. TheEqualityComparable requirementofoperator== could also be removed, but in that case both operators would at least need to require theBooleanTestablerequirements (see2114(i)) for the result type ofT'soperator== andoperator<.Arguably, corresponding operators forpair andtuple do not imposeLessThanComparable (norEqualityComparable), albeit the definition of the "derived" relation functions depend on properties ensured byLessThanComparable. According to theSGI definition, the intention wasto imposed bothEqualityComparable andLessThanComparable. If this is not intended, the standard should clarifythis position.[2015-02 Cologne]
VV, DK, JY discuss why and whenLessThanComparable was removed. AM: Move to LEWG. Please tell LWG when you look at it.
[2016-11-08, Issaquah]
Not adopted during NB comment resolution
[LEWG Kona 2017]
Recommend NAD: We've done a lot of work getting the C++17 semantics we want in this area; we're not going to changethem 3 days from DIS or change the TSv2 behavior to be different from '17.
Proposed resolution:
std::basic_ostringstream is missing an allocator-extended constructorSection: 31.8.4[ostringstream]Status:NADSubmitter: Markus KempOpened: 2014-09-03Last modified: 2017-03-21
Priority:Not Prioritized
View all otherissues in [ostringstream].
View all issues withNAD status.
Discussion:
I initially brought this issue up onStack Overflow, where I was then told to make a topic about this problem onstd-discussion, where I was then in turn asked to report the issue.
The problem: Thestd::basic_ostringstream class template can be instantiated with an allocator type, but none of the constructors provided accept an allocator argument, which means it's impossible to usestd::basic_ostringstream with stateful allocators. The C++ Standard Library Defect Report List seems to already mention a similar issue (2210(i)).[2014-11 Urbana]
Closed as NAD
This is not a rejection of the suggestion, but an observation that simply adding an allocator-awareconstructor is only part of the problem.stringstream returns thestring assembledin its buffer by value, as the result of a call tostr, and typically this will not use thesame allocator as would be supplied at construction.
The appropriate way to make progress on this issue, if motivated, is to submit a paper to LEWGaddressing the larger design concerns in addition to 'just' adding an (optional) allocator tothe constructors.
Proposed resolution:
Section: 23.2.7[associative.reqmts]Status:NADSubmitter: Tomasz KamińskiOpened: 2014-07-14Last modified: 2018-06-23
Priority:Not Prioritized
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
Currently the heterogeneous lookup in associative container areenabled by presence ofis_transparent nested type in the comparatortype (23.2.7[associative.reqmts]). This complicates the definitionof call wrapper types that want to defineis_transparent if they wrapa callable type that definesis_transparent, and requires the targetto be a complete type in cases where an incomplete type would otherwise be ok.
is_transparent member toa third-party comparison type that they do not control, even if theyknow it supports heterogeneous comparisons.If the associative containers used a trait instead of checking for anis_transparent member type then it would avoid the requirement forcomplete types, and would allow customization of the trait withoutmodifying the comparator type. This would also be consistent with thetraitsis_placeholder andis_bind_expression.For backward compatibility with the existing design, the defaultimplementation of theis_transparent trait could depend on thepresence of theis_transparent nested type.[2014-11 Urbana]
Move to LEWG
Request for a new metafunction should first be responded to by LEWG.
[2017-02 in Kona, LEWG recommends NAD]
In all discussions of heterogeneous lookup, the entire set of those discussions has been different integer types or string_view vs string. There actually hasn't been an example, that we are aware of, besides those two. -- Could always wrap the third-party type with the comparator? -- Could benefit from a motivating example. -- is_transparent<>, what does it mean?
[2017-06-02 Issues Telecon]
The advantages of changing the API now are not sufficiently clear. We invite a paper presenting motivating examples and more details of the proposed change, but at present consider this Not A Defect.
Resolve as NAD
Proposed resolution:
initializer_list assignabilitySection: 17.11[support.initlist]Status:NADSubmitter: David KraussOpened: 2014-09-30Last modified: 2023-11-13
Priority:2
View otheractive issues in [support.initlist].
View all otherissues in [support.initlist].
View all issues withNAD status.
Discussion:
std::initializer_list::operator= 17.11[support.initlist] is horribly broken and it needs deprecation:
std::initializer_list<foo> a = {{1}, {2}, {3}};a = {{4}, {5}, {6}};// New sequence is already destroyed.Assignability ofinitializer_list isn't explicitly specified, but most implementations supply a default assignment operator. I'm not sure what 16.3[description] says, but it probably doesn't matter.
[Lenexa 2015-05-05: Send to EWG as discussed in Telecon]
[2022-08-24; Reflector poll]
Set status to Tentatively NAD after reflector poll in October 2021.
"If somebody wants to revisit it, they'll need to write a paper to demonstratewhat the change would break, whether that would be a problem in practice,and convince the evolution groups to make a change. But it's not an LWG issue."
[2022-11-25; seeEWG 1369]
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
[Varna 2023-06-12; EWG discussed the issue again]
EWG consensus:"Send LWG2432 back to LWG to encourage them to either add a note for theirimplementer to issue a warning as QoI, or to use the tools(explicit convertible_to operator=) at their disposal to accomplish their goal"
Theoperator= suggestion refers to:
initializer_list& operator=(convertible_to<initializer_list> auto&& rhs) { /* ... */ }initializer_list& operator=(initializer_list const&) requires false = default;Proposed resolution:
Edit 17.11[support.initlist] p1, class templateinitializer_list synopsis, as indicated:
namespace std { template<class E> class initializer_list { public: […] constexpr initializer_list() noexcept;initializer_list(const initializer_list&) = default;initializer_list(initializer_list&&) = default;initializer_list& operator=(const initializer_list&) = delete;initializer_list& operator=(initializer_list&&) = delete; constexpr size_t size() const noexcept; […] }; […]}std::tuple_size should be definedSection: 22.4.1[tuple.general]Status:NADSubmitter: Nevin LiberOpened: 2014-10-10Last modified: 2018-06-23
Priority:Not Prioritized
View all otherissues in [tuple.general].
View all issues withNAD status.
Discussion:
In 22.4.1[tuple.general] paragraph 2, the unspecializedstd::tuple_size is undefined. It would be a lot more useful with SFINAE if it were defined as an empty struct; that way, it can be used withenable_if for determining whether or not it is valid to usetuple_size,tuple_element and get on the corresponding data structure.
[2014-11 Urbana]
Moved to LEWG 42.
This request goes beyond simply making an API respond well to SFINAE, but coupling that with animplication for other tuple APIs. The proper place for such design discussions is LEWG.
[2017-02 in Kona, LEWG recommends NAD]
We believe there are other ways to achieve the same results (at least for all of the use cases we could see). We invite Nevin to provide more details / motivations if this is necessary, not just helpful in a limited number of cases.If the dr is raised, variant_size should be considered for the same change as well.
[2017-06-02 Issues Telecon]
It's unclear what benefit this change would have, but making it complete wouldhave very undesirable interactions with structured bindings. The current Corewording for structured bindings depends on tuple_size being an incomplete type.
Resolve as NAD
Proposed resolution:
This wording is relative to N3936.
Change 22.4.1[tuple.general] p2, header<tuple> synopsis, as indicated
[…]//20.4.2.5, tuple helper classes:template <class T> class tuple_size;// undefined[…]
Change 22.4.7[tuple.helper] as indicated
[…]template <class T> struct tuple_size{ };[…]vector::insert invalidatesend()?Section: 23.3.13.5[vector.modifiers]Status:NADSubmitter: Marc GlisseOpened: 2014-10-21Last modified: 2017-03-14
Priority:3
View all otherissues in [vector.modifiers].
View all issues withNAD status.
Discussion:
this issue is based on the discussionhere.
23.3.13.5[vector.modifiers] says aboutvector::insert: "If no reallocation happens, all the iterators and references before the insertion point remain valid." This doesn't seem to guarantee anything about the iteratorat the point of insertion.The question comes from people asking if the following is valid, assuming a sufficient call toreserve() was done first:v.insert(v.end(), v.begin(), v.end());
It could fail for an implementation using a sentinel for the end of the vector, but I don't know of any (it would be quite inconvenient). And for any implementation using a simple position as iterator (pointer (possibly in a wrapper), or base+offset), this is needlessly restrictive. The fact that this alternative:
v.insert(v.end(), &v[0], &v[0]+v.size())
is arguably valid (again assuming a large enoughreserve()) makes it a bit confusing that the first version isn't (23.2.4[sequence.reqmts] has a precondition that iterator arguments toinsert() do not point into the sequence, butvector::insert is more refined and seems to give enough guarantees that it cannot fail).
vector iterators act as positions, and that after a reallocation-free operation an iterator points to the same position, whatever may be there now…[2017-03-04, Kona]
NAD. The problem description is incorrect; it is a violation of table entry 87 a.insert(p, i, j) - "i and j are not iterators into a".
Proposed resolution:
std::begin() andstd::end() do not support multi-dimensional arrays correctlySection: 24.7[iterator.range]Status:NADSubmitter: Janez ŽemvaOpened: 2014-11-16Last modified: 2024-06-24
Priority:3
View otheractive issues in [iterator.range].
View all otherissues in [iterator.range].
View all issues withNAD status.
Discussion:
The following code:
#include <algorithm>#include <iterator>#include <iostream>#include <cassert>int main() { int a[2][3][4] = { { { 1, 2, 3, 4}, { 5, 6, 7, 8}, { 9, 10, 11, 12} }, { {13, 14, 15, 16}, {17, 18, 19, 20}, {21, 22, 23, 24} } }; int b[2][3][4]; assert(std::distance(std::begin(a), std::end(a)) == 2 * 3 * 4); std::copy(std::begin(a), std::end(a), std::begin(b)); std::copy(std::begin(b), std::end(b), std::ostream_iterator<int>(std::cout, ","));}does not compile.
A possible way to remedy this would be to add the following overloads ofbegin,end,rbegin, andrend to 24.7[iterator.range], relying on recursive evaluation:namespace std { template <typename T, size_t M, size_t N> constexpr remove_all_extents_t<T>* begin(T (&array)[M][N]) { return begin(*array); } template <typename T, size_t M, size_t N> constexpr remove_all_extents_t<T>* end(T (&array)[M][N]) { return end(array[M - 1]); } template <typename T, size_t M, size_t N> reverse_iterator<remove_all_extents_t<T>*> rbegin(T (&array)[M][N]) { return decltype(rbegin(array))(end(array[M - 1])); } template <typename T, size_t M, size_t N> reverse_iterator<remove_all_extents_t<T>*> rend(T (&array)[M][N]) { return decltype(rend(array))(begin(*array)); }}[2023-04-06; LWG reflector poll in November 2021]
Changed to Tentatively NAD after 12 votes in favour.Useviews::join ormdspan instead.
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
<cmath> functions unfriendly tointegral_constant argumentsSection: 29.7[c.math]Status:NADSubmitter: Matheus IzvekovOpened: 2015-02-13Last modified: 2015-12-17
Priority:4
View all otherissues in [c.math].
View all issues withNAD status.
Discussion:
Using numeric wrappers with<cmath> functions is currently troublesome.Code such as: "std::exp2(std::integral_constant<int, 5>{})" will fail to compile because of ambiguity.
<cmath> equivalents in their own namespace which are not more specialized than the ones provided in<cmath>. If the changes proposed are implemented, then cases where the user brings those into scope through ADL might become ambiguous.It's hard to assess how much breakage this would cause in the wild, and how much work it would take to fix. Should this be determined to be a problem, it's possible to make the new behaviour optional, and disabled by default for all user-defined types.[2015-10, Kona Saturday afternoon]
STL: This should be NAD, NAD-future and NAD-go-away. Users can already solve this using Walter's call syntax.
VV: I don't personally have this problem, but the proposed resolution seems frightening to me.
VV: There's a related issue, 2294, and also 2192.
STL: 2086 is about user-defined types in <cmath>, fixed in C++14. The PR for 2474 wants to undo the fix.
Proposed resolution:
This wording is relative to N4296.
Change 29.7[c.math] p11 b2 as indicated:
-11- Moreover, there shall be additional overloads sufficient to ensure:
[…]
Otherwise, if any arithmetic argument corresponding to a
doubleparameter has typedoubleoran integer typea type which is not floating-point, but which is implicitly convertible todouble, then all arithmetic arguments corresponding todoubleparameters are effectively cast todouble.[…]
ostream::write andostream::operator<<Section: 27.4.4.4[string.io], 31.7.6.4[ostream.unformatted]Status:NADSubmitter: Marshall ClowOpened: 2015-09-10Last modified: 2016-07-13
Priority:2
View all otherissues in [string.io].
View all issues withNAD status.
Discussion:
Consider the following program:
#include <iostream>#include <ostream>#include <string>template <class CharT>class testbuf : public std::basic_streambuf<CharT> {public: testbuf() {}protected: virtual std::streamsize xsputn(const CharT *s, std::streamsize n) { std::cout << "xsputn('" << s << "', " << n << ")\n"; return n; }};int main () { testbuf<char> sb; std::ostream os (&sb); std::string s1{"abc"}; os.write(s1.data(), s1.size()); os.write(s1.data(), 0); std::string s2{"def"}; os << s2; std::string s3{""}; os << s3; os << "";}What should it print?
libc++:xsputn('abc', 3)xsputn('def', 3)libstdc++:
xsputn('abc', 3)xsputn('abc', 0)xsputn('def', 3)xsputn('', 0)xsputn('', 0)VS:
xsputn('abc', 3)xsputn('def', 3)xsputn('', 0)xsputn('', 0)27.4.4.4[string.io]/5 seems to say that an implementation is required to callsputn (which callsxsputn) even if there's nothing to output (in the case ofostream::operator<<(basic_string)).
sputn if there's nothing to output (in the case ofostream::write)Backstory: A user has aostream with a subclass ofbasic_streambuf. it creates an output file on first write. Sometimes, he callsostream::write(p, 0), and expects this to create the file. This doesn't work in libc++, and then he pointed out the inconsistency betweenoperator<< andwrite.For reference to a bug reportsee here.There are two obvious possible resolutions:a) require all output functions to callsputn, even if there are no characters to output. In practice, this reduces to "string-like" things which are empty (string,string_view,char*, etc), andwrite(ptr, len).
b) remove the requirement thatostream::operator<< callsputn when there are no characters to output.
[06-2016 Oulu, Saturday morning]
MC: Problem is this program produces different outputs on different platforms. The issue is what happens when you write 0 bytes: do you have to call xsputn? This affects a real customer.
NJ: Why is this a problem? Why not QOI?
DKu: I don’t think it’s a problem.
MC: Making your own streambuf is an explicit customization point.
DKu: But you should expect different numbers of calls.
NJ: They may even split the input, and call xsputn more than once for an input.
MC: Do we actually say that anywhere?
DKu: I think so.
MC: If you can find that, I’d be OK with NAD. The other thing that bothers me is that in one case it says you’re required to call sputn even if there’s no input, but the other wording doesn’t contain that requirement.
DKu: The first wording says “as if by”, which may give wiggle room to not call it.
DKu: In the second wording, sputc will never call sputn; it puts character into buffer, and calls overflow if the buffer is full. sputn is strictly an optimization.
MC: OK, I’m convinced this could be NAD, that the standard simply gives no guarantees about this. Are we OK with this lack of precision and implementation variance, or does the spec need to be more precise?
DKu: If you look at [ostream]/p2, it deliberately doesn’t specify how the functions are called. Even if sputn is called, no guarantee that xsputn is called at all: if there’s space in the buffer, the implementation may just put the characters in the buffer. This flexibility makes user implementations nicer, so I think this is definitely NAD
BD: This stuff is incredibly chewed-over. There used to always be a group working on this stuff; it’s hard to believe there’s anything in here that’s not deliberate, so you can’t change it with this small group; you need to talk to all the implementers.
MC: Any objections to NAD?
no objections.
Closing as NAD.Proposed resolution:
Section: 99 [parallel.ts::parallel.alg.general.exec]Status:NADSubmitter: Robert GevaOpened: 2015-09-22Last modified: 2015-10-21
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: parallel.ts
Parallel algorithms as ofN4352 in general need to assume that iterator operations andswap have the expected data race behavior. For example,sort would not work if the exchange operation were thread-unsafe and, for example, always updated a single unprotected global counter, independent of the objects being swapped. A parallelsort has to be able to assume that disjoint pairs of objects can be swapped concurrently, i.e. that elemental functions have the same sort of thread-safety behavior that we generally promise for the standard library versions. I don't see that assumption stated anywhere.
Function objects passed into parallel algorithms as objects of type
BinaryPredicate,Compare, andBinaryOperationshall not directly or indirectly modify objects via their arguments.
But that only seems to cover the easy cases.
Proposed resolution:
priority_queue doesn't work with move-only typesSection: 23.6.4[priority.queue]Status:NADSubmitter: Matt AusternOpened: 2015-10-27Last modified: 2016-02-07
Priority:3
View all otherissues in [priority.queue].
View all issues withNAD status.
Discussion:
Suppose we want to remove and process the topmost element of apriority_queue<T>. For a copyable type we might write
auto tmp = q.top();q.pop();
but of course that doesn't work ifT is move-only. Nothing of that sort can work, since moving out oftop() would make the subsequent call topop() fail.
pop() is defined to performpop_heap(c.begin(), c.end(), comp);c.pop_back();
so the removed value continues to exist between the first and second lines but there isn't any access to it. The sort of primitive that would allow consuming and removing the topmost element would be some variation on this, e.g.
pop_heap(c.begin(), c.end(), comp);auto tmp = move(c.back());c.pop_back();return tmp;
[2016-02, Issues Telecon]
This should be addressed by a paper addressed to LEWG.
Proposed resolution:
basic_string_view substring constructorSection: 7.3[fund.ts.v2::string.view.cons]Status:NADSubmitter: Evan TeranOpened: 2015-10-29Last modified: 2018-06-23
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: fund.ts.v2
string_view can be tremendously useful for dealing with sub-strings without copying. However, thecurrent proposal forbasic_string_view, has no constructor which provides a direct way of creating a view of a sub-string of abasic_string. Instead, we construct a view of the wholebasic_string, and then as a second step create a sub-string, for example usingsubstr. To simplify what I believe to be a common use case, I suggest adding an additional constructor.
template <class Allocator>basic_string_view(const basic_string<charT, traits, Allocator>& str, size_type pos, size_type count = npos);Throws:
Effects: Determines the effective lengthout_of_rangeifpos >= str.size().rlenof the string to reference as the smaller ofcountandsize() - pos.Postcondition:
data_ = str.data() + possize_ = rlen
In other words, the result is as if constructed via:basic_string_view(basic_string_view(str).substr(pos, count));
template <class Allocator>basic_string_view(const basic_string<charT, traits, Allocator>& str, size_type pos, size_type count = npos) : data_(nullptr), size_(0) { basic_string_view(str).substr(pos, count).swap(*this);}Note that while we have a default parameter forcount,pos does not. I believe that it is best to have this as a separate overload, as opposed to default parameters on the current constructor for two reasons:
The current constructor taking abasic_string does not throw, this overload can throw ifpos >= str.size().
This constructor performs slightly more work, it is not necessary to impose this extra work on the basic case of constructing a view of a whole string.
This has been briefly discussed in theisocpp forums. There were no obvious objections to this small improvement. Additionally, another reason to consider this addition is to provide a more consistent interface. With raw strings, we have the ability to construct abasic_string_view which is a sub-string. For example:
const char* s = "hello world";auto v = string_view(s + 6);
But there is no constructor which easily does the same when starting with abasic_string.
void print_string(string_view v) { std::cout << v << '\n';}int main() { std::string s = "hello world"; // for example, we want to print the sub-string "world", without copies // current method: print_substring(string_view(s).substr(6)); // suggested method: print_substring(string_view(s, 6);}Previous resolution [SUPERSEDED]:
This wording is relative toN4529.
Insert between 7.3[fund.ts.v2::string.view.cons] p5 and p6 the following sequence of paragraphs:
template <class Allocator>basic_string_view(const basic_string<charT, traits, Allocator>& str, size_type pos, size_type count = npos);-?-Throws:
-?-Effects: Determines the effective lengthout_of_rangeifpos >= str.size().rlenof the string to reference as the smaller ofcountandsize() - pos.-?-Postcondition: Constructs abasic_string_view, with the postconditions in Table ?
Table ? — basic_string_view(const basic_string<charT, traits, Allocator>&, size_type, size_type)effectsElement Value data_str.data() + possize_rlen
[2016-03, Jacksonville]
Change status to "LEWG"LEWG: Do we want this constructor?
SF F N A SA0 3 2 13 1Proposed resolution:
Not a defect. The LWG believes this missing feature is not sufficiently serious to constitute a defect.
Section: 16.4.6.5[member.functions]Status:NADSubmitter: Ville VoutilainenOpened: 2015-11-29Last modified: 2018-11-12
Priority:2
View otheractive issues in [member.functions].
View all otherissues in [member.functions].
View all issues withNAD status.
Discussion:
The combination of 16.4.6.5[member.functions], paragraphs 2 and 3 that LWG2259(i) does seems to drop a requirement that any call behaves as if no overloads were added. Paragraph 3 used to say"A call to a member function signature described in the C ++ standardlibrary behaves as if the implementationdeclares no additional member function signatures."whereas the new wording says"provided that any call to the member function that would select anoverload from the set of declarations described in this standardbehaves as if that overload were selected."
This can be read as meaning that if there's no default constructorspecified, like for instance forstd::ostream, an implementation is free toadd it. It can also be read as meaning that an implementation is free toadd any overloads that wouldn't change the overload resolution resultof any call expression that would select a specified overload. That'svastly different from allowing extensions that add new functions ratherthan new overloads.Was this relaxation intentional?[2016-04, Issues Telecon]
Ville provides a motivating example.
#include <iostream>class my_stream : std::ostream{};int main(){ my_stream ms;}This example is accepted by libstdc++, msvc rejects it, and clang+libc++segfault on melpon.org/wandbox o_O. An earlier clang+libc++ just acceptsit. I don't think the implementation divergence is caused by the acceptanceof the referred-to2259(i), but it certainly seems to increasingly blessthe implementation divergence.
[2016-05 Issues Telecon]
This is related to issue2695(i).
[2018-08 Batavia Monday issue discussion]
Ville to provide wording.
[2018-08 Batavia Monday issue discussion]
Ville recommends NAD; because closing this would outlaw conforming extensions.
[2018-11 San Diego Thursday night issue processing]
Status to NAD
Proposed resolution:
operator= orassign?Section: 27.4.3.3[string.cons], 27.4.3.7.3[string.assign], 28.6.7.3[re.regex.assign]Status:NADSubmitter: Marshall ClowOpened: 2016-01-05Last modified: 2016-11-12
Priority:4
View all otherissues in [string.cons].
View all issues withNAD status.
Discussion:
There are two "containers" in the standard who have member functions namedassign that take parameters of the type of the container (as opposed to iterators, pointers, what have you).
string's case, we defineassign in terms ofoperator=.Inregex's case, we defineoperator= in terms ofassign.We should pick a style and use use it.In 27.4.3.3[string.cons], we have:basic_string& operator=(const basic_string& str);-17-Effects: If
-18- If*thisandstrare not the same object, modifies*thisas shown in Table 70.*thisandstrare the same object, the member has no effect.-19-Returns:*thisbasic_string& operator=(basic_string&& str) noexcept(allocator_traits<Allocator>::propagate_on_container_move_assignment::value || allocator_traits<Allocator>::is_always_equal::value);-20-Effects: Move assigns as a sequence container (23.2), except that iterators, pointers and references may be invalidated.
-21-Returns:*this
In 27.4.3.7.3[string.assign], we have:
basic_string& assign(const basic_string& str);-1-Effects: Equivalent to
-2-Returns:assign(str, 0, npos).*this.basic_string& assign(basic_string&& str) noexcept(allocator_traits<Allocator>::propagate_on_container_move_assignment::value || allocator_traits<Allocator>::is_always_equal::value);-2-Effects: Equivalent to
-3-Returns:*this = std::move(str).*this.
Marshall says: There is another issue2579(i) here, to change /1 to be similar to /2.
In 28.6.7.3[re.regex.assign], we have:basic_regex& operator=(const basic_regex& e);-1-Effects: returns
assign(e).basic_regex& operator=(basic_regex&& e) noexcept;-2-Effects: returns
assign(std::move(e)).
and
basic_regex& assign(const basic_regex& that);-7-Effects: copies
-8-Postconditions:thatinto*thisand returns*this.flags()andmark_count()returnthat.flags()andthat.mark_count(), respectively.basic_regex& assign(basic_regex&& that) noexcept;-9-Effects: move assigns from
-10-Postconditions:thatinto*thisand returns*this.flags()andmark_count()return the values thatthat.flags()andthat.mark_count(), respectively, had before assignment.thatis in a valid state with unspecified value.
[2016-02, Issues Telecon]
Marshall to see if this can be dealt with editorially. Change Regex so that assign is in terms of op=
[2016-02]
Changedbasic_regex to matchstring as an editorial change. Closing as NAD
Proposed resolution:
ios_base must store inaccessible iostate flagsSection: 31.5.2.6[ios.base.storage]Status:NADSubmitter: David KraussOpened: 2016-03-14Last modified: 2019-02-26
Priority:Not Prioritized
View all otherissues in [ios.base.storage].
View all issues withNAD status.
Discussion:
DR41(i), "Ios_base needsclear(),exceptions()" stopped short of providing the interface suggested in its title, but it did require the underlying state to be stored inios_base. Becauserdstate() is also missing,ios_base manipulators relying oniword andpword cannot detect failure. The only safe alternative is to manipulate a derived class, which must be a template.
[2016-04, Issues Telecon]
This is really a request for an (feature) API. Passing to LEWG.
[LEWG Kona 2017]
Recommend NAD: iostreams aren't used in this way enough to spend committee time on it. However, a paper could change our minds.
Proposed resolution:
Section: 4.14 [filesys.ts::fs.def.parent]Status:NADSubmitter: CH-3Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
The concept of a parent directory for dot or dotdot exists, but the definition doesn't apply.
Suggested action:
Remove the paragraph. This concept does not apply to dot and dot-dot. Add a definition for dot and dot-dot.
[2014-02-07, Beman Dawes comments]
Suggest it is editorial and should be passed to the project editor.
[ 2014-02-11 Issaquah: Beman to provide wording for review next meeting. Also see related issue 5. ]
[22 May 2014 Beman Dawes comments:]
I've now reviewed this issue carefully and believe it is NAD. "parent" is used in four places in the WP, and so deserves a definition. The current definition is copied word-for-word and in its entirety from the POSIX definition. I believe strongly that the File System TS needs to stay in alignment with POSIX on this matter, and that the best way to do that is simply to use the POSIX wording.
[17 Jun 2014 Rapperswil LWG closes as NAD. No concensus for change.]
Proposed resolution:
Section: 6 [filesys.ts::fs.filesystem.synopsis]Status:NADSubmitter: FI-4Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.filesystem.synopsis].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
It is unclear whycopy,copy_file andcopy_symlink have different return types,and why the attribute-version ofcreate_directory has a different return type than thecreate_directory that takes no attributes. The status/error reporting in these functionsseems inconsistent.
[ 2014-02-11 Issaquah: NAD. LWG/SG-3 reviewed each function and return type, and found that since they have different functionality different return types are warranted.create_directory has an inconsistent return type between the synopsis and the description. This has subsequently been corrected editorially. ]
Proposed resolution:
relative() operation functionSection: 6 [filesys.ts::fs.filesystem.synopsis], 15 [filesys.ts::fs.op.funcs]Status:NAD FutureSubmitter: GB-1Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.filesystem.synopsis].
View all issues withNAD Future status.
Discussion:
Addresses: filesys.ts
There is norelative() operation, to complement bothabsolute() andcanonical()
The TS introduces relative paths.
They are defined in section 4.18 relative path [fs.def.relative-path]
A decomposition methodrelative_path() is described in section 8.4.9 path decomposition [path.decompose]
Two query methods to determine if a path eitherhas_relative_path() oris_relative() described in 8.4.10 path query [path.query]
However there is no way to create a relative path as a path relative to another. Methods are provided to create absolute and canonical paths.
In section 15.1 Absolute [fs.op.absolute]:
path absolute(const path& p,const path& base=current_path());
and in section 15.2 Canonical [fs.op.canonical]
path canonical(const path& p,const path& base = current_path());
path canonical(const path& p, error_code& ec);
path canonical(const path& p,const path& base, error_code& ec);
By providing a operations to achieve absolute and canonical paths there is no impediment to providing a similar operation relative() thatattempts to return a new path relative to some base path.
For example:
path relative(const path& p,const path& to = current_path());
path relative(const path& p, error_code& ec);
path relative(const path& p,const path& to, error_code& ec);
This would return a path, if possible, that is relative toto. The implementation can make use ofabsolute() andcanonical() to determine the relative path, if it exists.
The File System TS is based on theboost::filesystem library and it too suffers from this anomaly. There are open tickets for this inBoost Trac:
and it is the subject of several posts on StackOverflow for example:
http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path
http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths
Other languages typically provide a similar function. For example python provides:
os.path.relpath(path[, start])
Return a relative filepath to path either from the current directory or from an optional start directory. This is a path computation: the filesystem is not accessed to confirm the existence or nature of path or start. start defaults to os.curdir.
[2014-02-07, Beman Dawes comments]
Arelative() function is useful and much requested.I've seen such a function provided by users and have written it myself in app code.It is one of those things I've been meaning to do for years, and have just never gotten around to.
That said, my mild preference is to treat this as "NAD, Future" for File System TS1, but treat it as a priority for TS2.
[ 2014-02-11 Issaquah ]
The LWG/SG-3 voted strongly in favor of adding this functionality, and doing so in this TS. That implies quite a bit of work before the next meeting to validate that the proposed interface works as desired for various platforms. There was general agreement not to hold FS STS1 if this functionality isn't ready when the rest of the TS is ready.
[2014-05-19 Beman Dawes supplied wording.]
The design benefited from discussions with Jamie Allsop, who wasthe source of the original NB comment.Thanks to Bjorn Reese for corrections and suggestions. Although there was also discussion and experimentation with additionalrelative functions that took into account symlinks and normalization, these are not proposed here since even the proponentsof such functions were unsure of appropriate semantics.
[2014-06-17 Rapperswil LWG closes as NAD, Future.]
Although there is strong concensus for eventually providing both lexical and existence based flavors of relative() functionality, discussion of the many possible design choices led to the conclusion that more research and actual user experience is necessary before moving forward. Interested parties should submit papers.
Original proposed resolution:
Modify header<filesystem> synopsis, 6 [fs.filesystem.synopsis],by adding the operational functions aftercanonical:
path relative(const path& p, const path& to = current_path());path relative(const path& p, error_code& ec);path relative(const path& p, const path& to, error_code& ec);
Insert the section:
15.3 Relative [fs.op.relative]
path relative(const path& p, const path& to = current_path());path relative(const path& p, error_code& ec);path relative(const path& p, const path& to, error_code& ec);Overview: Return a relative path of p to the current directory or from an optional to path.
Returns: A relative path such that
canonical(to)/relative(p,to) == canonical(p),otherwisepath(). Ifcanonical(to) == canonical(p)the pathpath(".")is returned. For theoverload without atoargument,toiscurrent_path(). Signatures with argumentecreturnpath()if an error occurs.Throws: As specified in Error reporting.
Remarks:
!exists(p) or !exists(to) or !is_directory(to)is an error.
and bump all following sections up by 0.1. Update the contents and any cross-referencesaccordingly.
Question: Should Returns be specified in terms of equivalence? For example:equivalent( canonical(to)/relative(p,to), canonical(p) )
Question: Shouldcanonical(to) == canonical(p) returnpath(".") orpath()? Why?
Question: Shouldto be spelledstart?
Proposed resolution:
To 6 Header <experimental/filesystem> synopsis [fs.filesystem.synopsis], add:
path lexically_relative(const path& p, const path& base);
At the end of 8.6 path non-member functions [path.non-member], add
8.6.3
path lexically_relative(const path& p, const path& base);pathlexically_relative function [path.lexically.relative]Creates a path from the trailing elements of
pthat are lexically relative tobase, which must be a prefix ofp.Effects: If the number of elements in [
p.begin(), p.end()) is less than or equal to the number of elements in [base.begin(), base.end()), or if any element in [base.begin(), base.end()) is not equal to the corresponding element in [p.begin(), p.end()), throw an exception of typefilesystem_error.Remarks:Equality or inequality are determined by
path::operator==orpath::operator!=respectively.Returns:An object of class
pathcontaining the first element ofpthat does not have a corresponding element inbase,followed by the subsequent elements ofpappended as if bypath::operator/=.Throws:
filesystem_error.[Note: Behavior is determined by the lexical value of the elements of
pandbase- the external file system is not accessed. The case where an element ofbaseis not equal to corresponding element ofpis treated as an error to avoid returning an incorrect result in the event of symlinks. --end note]A possible implementation would be:
auto mm = std::mismatch( p.begin(), p.end(), base.begin(), base.end());if (mm.first == p.end() || mm.second != base.end()){throw filesystem_error("p does not begin with base, so can not be made relative to base",p, base,error_code(errc::invalid_argument, generic_category()));}path tmp(*mm.first++);for (; mm.first != p.end(); ++mm.first)tmp /= *mm.first;return tmp;
uintmax_t too small for large file sizesSection: 6 [filesys.ts::fs.filesystem.synopsis], 15.14 [filesys.ts::fs.op.file_size]Status:NAD FutureSubmitter: CH-8Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.filesystem.synopsis].
View all issues withNAD Future status.
Discussion:
Addresses: filesys.ts
uintmax_t is specified to hold at least 64 bit. This is not enough for sizesbeyond 4 [sic] exabytes.
Specify whether an implementation must provide auintmax_t that can hold the maximumpossible space and file size values.
[2014-02-06: Jeffery Yasskin points out 64-bits unsigned actually has a maximum value of "16 exabytes, not 4"]
[2014-02-07: Beman Dawes suggests: This should be NAD. Such ultra-large files are the province of enterprise-wide filesystems such as requested by IBM and others for a follow-on SG3 TS. That would be the best vehicle to address this concern IMO.]
[ 2014-02-11 Issaquah: NAD Future. ]
Proposed resolution:
Section: 7 [filesys.ts::fs.err.report]Status:NADSubmitter: CH 9Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.err.report].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
The specification of the actual error conditions for the functions that specify Throws: As specified in Error reporting. is missing.
Add those specifications.
[2014-02-07, Beman Dawes comments]
The actual error codes, and thus the error conditions, are determined by the operating system, and thus operating system dependent.
[2014-02-11 Issaquah]
There is no consensus for a change. LWG/SG3 requested a separate issue be opened to clarify 7 [fs.err.report]. See issue 55.Proposed resolution:
path memberswap() unnecessarySection: 8.4.5 [filesys.ts::path.modifiers]Status:NADSubmitter: CH-12Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
As we have move semantics, memberswap functions shouldn't be necessary any more.
[2014-02-12 LWG/SG-3 Issaquah ]
No consensus for change. STL pointed out that swap should be noexcept and will submit a separate issue.Proposed resolution:
Removeswap().
create_regular_file() and/ortouch()Section: 15 [filesys.ts::fs.op.funcs]Status:NADSubmitter: CH-14Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.op.funcs].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
Sincecreate_symlink(),create_hardlink(), andcreate_directory() exist, there'sno reason not to have acreate_regular_file() function.
Consider adding a functioncreate_regular_file() with the behaviour of the POSIXtouchcommand.
[Beman comments]
create_regular_file() andtouch() should be different functions sincetheir behavior would differ if the file already exists; touch() updates the last writedate.
I have often wantedcreate_regular_file() but never got around to adding it.
Whiletouch is quite useful from the command line, I'm less sure of its usefulness asa library function. It is trivial for a user to implement.
Whether or not it is appropriate to add operational functions this late in the PDTSprocess is questionable.
[2014-02-13 LWG/SG-3 Issaquah: No consensus for change at this time.]
Proposed resolution:
Section: 15.13 [filesys.ts::fs.op.equivalent]Status:NADSubmitter: CH-16Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
Equivalence is a volatile property.
Consider adding a note that equivalence cannot be determined race-free.
[2014-02-13 LWG/SG-3 Issaquah: No consensus for change. Section 2.1 description of races is sufficient.]
Proposed resolution:
last_write_time() postcondition?Section: 15.25 [filesys.ts::fs.op.last_write_time]Status:NADSubmitter: GB-15Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.op.last_write_time].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
The constraint onlast_write_time is too weak: It is noted that the postconditionoflast_write_time(p) == new_time is not specified since it might not hold for filesystems with coarse time granularity.
last_write_time(p) <= new_time ?Add postcondition:last_write_time(p) <= new_time
[2014-02-09, Beman Dawes comments:]
That assumes the file system rounds down. We don't know which direction a file system rounds. Nice try, but this one looks NAD to me.[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]
Proposed resolution:
remove() must avoid raceSection: 15.28 [filesys.ts::fs.op.remove]Status:NADSubmitter: CH-17Opened: 2014-01-20Last modified: 2016-08-10
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
The specification can be read to require the existence test. As this introduces arace, the existence test must not happen.
Change to: "Effects:p is removed as if by POSIXremove()."
[2014-02-13 LWG/SG-3 Issaquah: Insufficient consensus for change. Vote for NAD: 9 0 0 2 1.]
Proposed resolution:
This wording is relative toSG3 working draft.
Change 15.28 [filesys.ts::fs.op.remove] as indicated:
Effects:
Ifexists(symlink_status(p,ec)), itpis removed as if by POSIXremove().
rename()Section: 15.30 [filesys.ts::fs.op.rename]Status:NADSubmitter: CH-18Opened: 2014-01-20Last modified: 2016-08-12
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
POSIX guarantees some kind of atomicity forrename().
Clarify that POSIX'rename() guarantee "If therename() function fails for anyreason other than [EIO], any file named by new shall be unaffected." holds for C++ as well.
[2014-02-10 Beman Dawes]
Section 2.1, POSIX conformance, [fs.conform.9945] specifies the POSIX conformance requirements for TS implementations in carefully crafted and specific detail. Repeating a portion of the POSIX standard's specification for a particular TS function would do great harm as it would bring into question all of the portions of the POSIX specification for the function that were not repeated.Furthermore, all the caveats and other details of the 2.1 specification would have to be analyzed and possibly appended; it ties the hands of implementors if they are not given latitude to deviate as needed when working with non-POSIX operating systems.I strongly recommend NAD for this issue.[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]
Proposed resolution:
noexcept and droperror_code versionSection: 12.3 [filesys.ts::directory_entry.obs], 15.12 [filesys.ts::fs.op.exists], 15.16 [filesys.ts::fs.op.is_block_file], 15.17 [filesys.ts::fs.op.is_char_file], 15.18 [filesys.ts::fs.op.is_directory], 15.19 [filesys.ts::fs.op.is_empty], 15.20 [filesys.ts::fs.op.is_fifo], 15.21 [filesys.ts::fs.op.is_other], 15.22 [filesys.ts::fs.op.is_regular_file], 15.23 [filesys.ts::fs.op.is_socket], 15.24 [filesys.ts::fs.op.is_symlink], 15.33 [filesys.ts::fs.op.status], 15.35 [filesys.ts::fs.op.symlink_status], 99 [filesys.ts::fs.op.unique_path]Status:NADSubmitter: P.J. PlaugerOpened: 2014-01-30Last modified: 2016-08-12
Priority:Not Prioritized
View all otherissues in [filesys.ts::directory_entry.obs].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
exists(const path&) should benoexcept (droperror_code version).is_*(const path&) should benoexcept (droperror_code version).status(const path&) should benoexcept (droperror_code version).symlink_status(const path&) should benoexcept (droperror_code version).file_status::status() should benoexcept (droperror_code version).file_status::symlink_status() should benoexcept (droperror_code version).unique_path(const path&) should benoexcept (droperror_code version).
[2014-02-08: Daniel comments]
unique_path(const path&) cannot be declared asnoexcept, because it returns an objectduring whose construction a memory allocation request may fail, see the rationale provided in2637(i).
exists(const path&) and theis_*(const path&) functions cannot benoexcept, because they are specified in terms ofstatus(const path&), which again may throw an exception, which is explicitly described in the Effects (filesystem_error), because the non-throwing function (status(const path&, error_code&)) may fail to satisfy the request.symlink_status(const path&) may throw an exception for similar reasons thatstatus(const path&)could fail.The reference tofile_status::status()/symlink_status() looks like a typo to me (there are no such functionsinfile_status), presumablydirectory_entry::status()/symlink_status() was meant. In this case I see no reason how these could be marked asnoexcept, because these functions all may fail and may throw an exception.Based on this interpretation of the issue discussion I recommend to resolve this issue as NAD.[Beman Dawes 2014-02-27]
Issues2637(i),2638(i),2641(i), and2649(i) are concerned with signatures which should or should not benoexcept. I will provide unified proposed wording for these issues, possibly in a separate paper.[17 Jun 2014 Rapperswil LWG closes as NAD. Working paper correct as written.]
Proposed resolution:
permissions() is missing from synopsisSection: 6 [filesys.ts::fs.filesystem.synopsis]Status:NAD EditorialSubmitter: P.J. PlaugerOpened: 2014-01-30Last modified: 2016-08-12
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.filesystem.synopsis].
View all issues withNAD Editorial status.
Discussion:
Addresses: filesys.ts
permissions function is missing from the summary list.
Proposed resolution:
[2014-02-07: Beman Dawes comments: Fixed as Editorial.]
class path should have defaulted constructors/destructor/assignments.Section: 8 [filesys.ts::class.path]Status:NADSubmitter: P.J. PlaugerOpened: 2014-01-30Last modified: 2016-08-12
Priority:Not Prioritized
View all otherissues in [filesys.ts::class.path].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
class path should have defaulted constructors/destructor/assignments.
[2014-02-26 Beman Dawes comments]
Suggest NAD. Earlier versions did have defaulted constructors/destructor/assignments,but they were removed at the request of Alberto Ganesh Barbati (c++std-filesys January 8, 2013):Speaking of=default, we have to be careful not over-constrain the specification.I mean, if we just specify the intended meaning of those function with proper wording,the implementation is allowed to use=defaultin case it provides an equivalent behaviour,but if we put=defaultin the specification, the implementation is required to use it.However, we have to remember that "for exposition only" data members may not be anexhaustive list and that 17.5.2.3/2 allows implementations to provide an equivalentbehaviour using different members for which "default" construction/copy/assignmentmay not be appropriate.=defaultis what we want for tuple, atomics, etc. It might be appropriate forsimple types like file_status, but, for more complex types likepathitself,I'd remove it and add proper wording.
[17 Jun 2014 Rapperswil LWG closes as NAD. Ganesh's analysis is correct. WP correct as written.]
Proposed resolution:
path::compare(const string&) should bepath::compare(const string_type&)Section: 8 [filesys.ts::class.path]Status:DupSubmitter: P.J. PlaugerOpened: 2014-01-30Last modified: 2016-08-12
Priority:Not Prioritized
View all otherissues in [filesys.ts::class.path].
View all issues withDup status.
Discussion:
Addresses: filesys.ts
path::compare(const string&) should bepath::compare(const string_type&).
[2014-02-08 Daniel comments]
This issue is a duplicate of2650(i). The suggested wording of that issue would resolve this issue here as well.
[2014-02-13 LWG/SG-3 Issaquah: Agrees with Daniel.]
Proposed resolution:
generic*?Section: 8.4.7 [filesys.ts::path.generic.obs]Status:NADSubmitter: P.J. PlaugerOpened: 2014-01-30Last modified: 2016-08-12
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
Do we really needgeneric*?
[2014-02-08 Daniel comments]
These functions should exist for more than one reason.
First, thegeneric pathname format is a well-defined concept for thepath specificationand defining just a single way into apath but not out of it looks like an incomplete design.More importantly, the existence of these functions have demonstrated to be quite useful in practice,because thegeneric pathname format concept is popular for many tools such asmavenor the some configuration files for the Eclipse IDE do understand this syntax uniformly on all platformsand it allows to generate or modify such files using C++ code based onfilesystem::path. Thepractical problem of the non-portable root-names doesn't matter in such contexts, because theserialized path names are in general relative names or depend on initial parts that are determinedby properties or environment variables.In other words: I'm recommending NAD for this issue.[2014-02-13 LWG/SG-3 Issaquah: Withdrawn by submitter.]
Proposed resolution:
directory_iterator,recursive_directory_iterator,pointer/reference typedefs wrongSection: 13 [filesys.ts::class.directory_iterator], 14 [filesys.ts::class.rec.dir.itr]Status:DupSubmitter: Stephan T. LavavejOpened: 2014-02-03Last modified: 2016-08-11
Priority:Not Prioritized
View all otherissues in [filesys.ts::class.directory_iterator].
View all issues withDup status.
Discussion:
Addresses: filesys.ts
directory_iterator andrecursive_directory_iterator are constant iterators, but theirpointer/reference typedefs are wrong (std::iterator defaults to providing modifiableones).
[2014-02-08 Daniel comments]
I noticed the same problem when trying to resolve2652(i). The currently suggested wording for thatissue should fix the here mentioned problem as well.
I recommend to solve this issue as "Resolved by the proposed wording for2652(i)".[2014-02-13 LWG/SG-3 Issaquah: Daniel's resolution accepted.]
Proposed resolution:
Section: 1 [filesys.ts::fs.scope]Status:NAD FutureSubmitter: GoogleOpened: 2014-01-20Last modified: 2016-08-11
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.scope].
View all issues withNAD Future status.
Discussion:
Addresses: filesys.ts
We have two primary concerns with the interface as specified:
(a) its interface repeats the mistake of V7 Unix in 1979 by exposing access checking (and similarly file creation) independently from opening and mutating the file, and
(b) it provides no realistic means of testing a software library which uses the standard interface for accessing the filesystem under fault scenarios.
Due to the extent of (a), TOCTTOU [1] security vulnerabilities are guaranteed, if not during access checking[2], during other common operations such as temporary file creation[3].
Due to (b) it is impossible to portably test libraries using the proposed interface against critical correctness and security edge cases.
[1]: TOCTTOU: Time-of-check-to-time-of-use. Operating system integrity in OS/VS2
[2]:Fixing Races for Fun and Profit: How to use access(2)
[3]:Checking for Race Conditions in File Accesses
[Beman Dawes: 10 Feb 2014: Suggested response: NAD, Future]We share your concerns and look forward to receiving specific proposals to address them. Whether they will addressed by a revision of TS 18822 or a new TS will be decided as proposals progress through the committee process. SeeHow To Submit a Proposal.
[17 Jun 2014 Rapperswil LWG agrees NAD, Future with rationale as stated above.]
Proposed resolution:
Section: 10 [filesys.ts::fs.enum]Status:NAD EditorialSubmitter: Daniel KrüglerOpened: 2014-03-01Last modified: 2016-08-11
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Addresses: filesys.ts
copy_options is declared asenum class type that is a bismask type, but the specification repeatedly uses expressions that are invalid for scoped enums, such as:!(options)((options & copy_options::recursive) || !(options))"ifoptions & copy_options::create_symlinks [..]"because all rely on contextual conversion to bool. The only other specifically mention scoped enumeration in the standard that is also a bit mask type is thelaunch enum and the wording there always uses forms such as:"ifpolicy & launch::deferred is non-zero"which better acknowledges the fact that the obtained values does not necessarily undergo an implicit conversion.I think the current wording in the file system spec. must be changed, especially for invalid expressions of the form:((options & copy_options::recursive) || !(options))perms for the expression:((prms & add_perms) && (prms & remove_perms))((prms & perms::add_perms) != perms::none && (prms & perms::remove_perms) != perms::none)add_perms andremove_perms is incorrect[20 May 2014 Beman Dawes provides proposed wording. Fixing invalid C++ is editorial, but treating this as an issue ensures more people review the proposed changes.]
[17 Jun 2014 Rapperswil LWG requests issue be handled as editorial.]
Proposed resolution:
Change 15.3 Copy [fs.op.copy]:
Before the first use of
fandt:
- If
(options & copy_options::create_symlinks) != copy_options::none || (options & copy_options::skip_symlinks) != copy_options::none, thenauto f = symlink_status(from)and if neededauto t = symlink_status(to).- Otherwise,
auto f = status(from)and if neededauto t = status(to).Report an error as specified in Error reporting (7) if:
!exists(f), orequivalent(from, to), oris_other(f) || is_other(t), oris_directory(f) && is_regular_file(t).If
is_symlink(f), then:
- If
(options & copy_options::skip_symlinks) != copy_options::none, then return.- Otherwise if
!exists(t), thencopy_symlink(from, to, options).- Otherwise report an error as specified in Error reporting (7).
Otherwise if
is_regular_file(f), then:
- If
(options & copy_options::directories_only) != copy_options::none, then return.- Otherwise if
(options & copy_options::create_symlinks ) != copy_options::none, then create a symbolic link to the source file.- Otherwise if
(options & copy_options::create_hard_links) != copy_options::none, then create a hard link to the source file.- Otherwise if
is_directory(t), thencopy_file(from, to/from.filename(), options).- Otherwise,
copy_file(from, to, options).
Otherwise if
is_directory(f) && ((options & copy_options::recursive) != copy_options::none ||then:!(options == copy_options::none))
- If
!exists(t), thencreate_directory(to, from).- Then, iterate over the files in
from, as if byfor (directory_entry& x : directory_iterator(from)), and for each iterationcopy(x.path(), to/x.path().filename(), options | copy_options::unspecified).
Change 15.4 Copy file [fs.op.copy_file]:
If
exists(to) &&report a file already exists error as specified in Error reporting (7).!(options & (copy_options::skip_existing | copy_options::overwrite_existing | copy_options::update_existing)) == copy_options::noneIf
!exists(to) || (options & copy_options::overwrite_existing) != copy_options::none || ((options & copy_options::update_existing) != copy_options::none && last_write_time(from) > last_write_time(to)) ||copy the contents and attributes of the file!(options & (copy_options::skip_existing | copy_options::overwrite_existing | copy_options::update_existing)) == copy_options::nonefromresolves to the filetoresolves to.
Change 15.26 Permissions [fs.op.permissions]:
Requires:
!((prms &perms::add_perms)!= perms::none && (prms &perms::remove_perms)!= perms::none).
equivalent() behavior if neither file existsSection: 6 [filesys.ts::fs.filesystem.synopsis]Status:NADSubmitter: Beman DawesOpened: 2014-04-12Last modified: 2016-08-11
Priority:Not Prioritized
View all otherissues in [filesys.ts::fs.filesystem.synopsis].
View all issues withNAD status.
Discussion:
Addresses: filesys.ts
bool equivalent(const path& p1, const path& p2); has always thrown a exception if neither file exists, with rationale that if they don't exist, it isn't possible to tell if two paths are equivalent. Dave Abrahams has reported that this is counter-intuitive and hard to teach.
An alternative if neither path exists would be to return true if they are lexically equal (operator==), otherwise return false.
This was not a national body comment, and Dave is the only one I can recall ever complaining about the current behavior. On the other hand, any complaint from Dave deserves serious consideration.
[17 Jun 2014 Rapperswil LWG considers this NAD. Mixing lexical and existence based behavior is not desirable.]
Proposed resolution:
Section: 31.12[filesystems]Status:NAD EditorialSubmitter: Jonathan WakelyOpened: 2014-06-30Last modified: 2017-06-15
Priority:3
View all otherissues in [filesystems].
View all issues withNAD Editorial status.
Discussion:
C++14 17.5.2.1.3 Bitmask types [bitmask.types] paragraph 4 specifies:
The following terms apply to objects and values of bitmask types:The TS should use these forms where applicable throughout the document.
- Toset a valueY in an objectX is to evaluate the expressionX |= Y.
- Toclear a value Y in an objectX is to evaluate the expressionX &= ~Y.
- The value Yis set in the objectX if the expressionX & Y is nonzero.
[2016-02, Jacksonville]
This is an editoral change.
[Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS]
Proposed resolution:
path::operator+= is defined, but notoperator+Section: 31.12.6[fs.class.path]Status:NADSubmitter: Jonathan WakelyOpened: 2014-07-03Last modified: 2017-03-19
Priority:3
View all otherissues in [fs.class.path].
View all issues withNAD status.
Discussion:
This doesn't seem to be in Boost.Filesystem, so maybe it isn't needed,but sincepath += path2 works then it seems reasonable to expectpath1 + path2 to work as well.
[04 Jul 2014 Beman Dawes comments:]
The 12 overloads required by
basic_string operator+scared me off, and I never came back to the issue.
[22 Nov 2015 Beman supplies proposed resolution wording.]
[Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS]
[2016-11-12, Issaquah]
Sat PM: JW is no longer convinced that this is a good idea.
Proposed resolution:
NAD, Future.
It is not necessary to provide every possible string operation for class
pathbecause it is always possible to convert to a string, perform the operation, and convert back to a path. The most commonly needed string operations are provided for classpathas a convenience, but every added function comes at the cost of increased interface complexity. In this case, the cost is judged to outweigh the convenience.Future changes to the language, such as concepts, and changes to the library, such as
basic_string_view, may allow reduction of the complexity of the class path interface. The LWG may wish to reconsider this issue at that time.
Section: 16.3.3.3.3[bitmask.types]Status:NADSubmitter: Hubert TongOpened: 2016-04-14Last modified: 2017-07-17
Priority:3
View otheractive issues in [bitmask.types].
View all otherissues in [bitmask.types].
View all issues withNAD status.
Discussion:
The usual pattern now used for identifying where bitmask elements are declared, namely, as variables, preclude declaring them as enumerators.
Compare:ctype_base::space in C++03 subclause 22.2.1 [lib.category.ctype] versus the same in N4582 subclause 22.4.1 [category.ctype].It is unclear whether this is intentional. Further it is unclear if odr-use of bitmask elements is intended to be allowed.[2016-05 Issues Telecon]
Jonathan believes that this was intentional, and was done by N3110. Jonathan will provide more precise references.
Proposed resolution:
resource_adaptor went missingSection: 20.5[mem.res]Status:NADSubmitter: Jonathan WakelyOpened: 2016-05-04Last modified: 2016-11-26
Priority:1
View all otherissues in [mem.res].
View all issues withNAD status.
Discussion:
The alias templatestd::experimental::resource_adaptor is an importantpart of the polymorphic memory resources framework, but was notadopted into the WP along with the rest of LFTSv1. This seems to be anaccidental omission. It was present in P0220R0, but absent in P0220R1.There was no discussion of leaving it out in Jacksonville, it is oneof the "core features" discussed and intended for adoption.
[Oulu, 2016-06]
Tuesday night: This was not an accidental omission.
std::experimental::resource_adaptor will remain in the LFTS and we shall continue to gain implementation experience.
Proposed resolution:
Add section 8.7 fromN4562 (LFTSv2 DTS) into the WP.
Section: 20.5.2.3[mem.res.private]Status:NAD EditorialSubmitter: Jonathan WakelyOpened: 2016-05-04Last modified: 2017-06-15
Priority:3
View all otherissues in [mem.res.private].
View all issues withNAD Editorial status.
Discussion:
[memory.resource.private] says:
virtual void* do_allocate(size_t bytes, size_t alignment) = 0;-1-Requires: Alignment shall be a power of two.
Is that supposed to be a requirement on the alignment specified by thealignment parameter? If so the word "Alignment" should not becapitalized and in text font.
[2016-05 Issues Telecon]
The resolution should reference [basic.align]. Jonathan to update the wording.
[2016-08 - Chicago]
Thurs AM: Moved to NAD Editorial. Will change "Alignment" toalignment and add a reference to [basic.align]
Proposed resolution:
Modify [memory.resource.private] paragraph 1 as shown:
virtual void* do_allocate(size_t bytes, size_t alignment) = 0;-1-Requires:
AlignmentThe alignment specified byalignmentshall be a power of two.
scoped_allocator_adaptor usesforward to domove's jobSection: 20.6.4[allocator.adaptor.members]Status:NADSubmitter: Billy Robert O'Neal IIIOpened: 2016-05-24Last modified: 2017-07-17
Priority:Not Prioritized
View all otherissues in [allocator.adaptor.members].
View all issues withNAD status.
Discussion:
scoped_allocator_adaptor is specified to useforward whenwhat it is really doing is moving elements. It should usemove.
Previous resolution [SUPERSEDED]:
This wording is relative to N4582.
Edit 20.6.4[allocator.adaptor.members] p15 as indicated:
template <class T1, class T2, class U, class V> void construct(pair<T1, T2>* p, pair<U, V>&& x);Effects: Equivalent to
this->construct(p, piecewise_construct, forward_as_tuple(std::.forwardmove<U>(x.first)), forward_as_tuple(std::forwardmove<V>(x.second)))
Proposed resolution:
Withdrawn by the submitter, since the prerequisites were incorrect.
directory_entry comparisons are membersSection: 31.12.10.4[fs.dir.entry.obs]Status:NADSubmitter: Ville VoutilainenOpened: 2016-08-03Last modified: 2017-03-19
Priority:2
View all otherissues in [fs.dir.entry.obs].
View all issues withNAD status.
Discussion:
The comparison operators fordirectory_entry are member functions(31.12.10.4[fs.dir.entry.obs]).
directory_entry can be compared with apath,but apath cannot be compared with adirectory_entry, becausethe left-hand side is not subject to conversions. This seemsunfortunate.Note that the comparisons forpath are non-members (31.12.6.8[fs.path.nonmember]).The meta-p/r is to turn thedirectory_entry comparisons into non-member functions.[2016-08 Chicago]
Wed PM: Priority 2
[2016-10-05 Ville provides concrete wording]
[2016-10 Telecon]
This (comparing apath with adirectory_entry) works today w/o any changes. Closing as NAD.
Proposed resolution:
This wording is relative to N4606.
In [fs.class.directory_entry] synopsis, edit as follows:
namespace std::filesystem {class directory_entry {public: […]bool operator< (const directory_entry& rhs) const noexcept; bool operator==(const directory_entry& rhs) const noexcept; bool operator!=(const directory_entry& rhs) const noexcept; bool operator<=(const directory_entry& rhs) const noexcept; bool operator> (const directory_entry& rhs) const noexcept; bool operator>=(const directory_entry& rhs) const noexcept;private: path pathobject; // exposition only};bool operator< (const directory_entry& lhs, const directory_entry& rhs) noexcept;bool operator==(const directory_entry& lhs, const directory_entry& rhs) noexcept;bool operator!=(const directory_entry& lhs, const directory_entry& rhs) noexcept;bool operator<=(const directory_entry& lhs, const directory_entry& rhs) noexcept;bool operator> (const directory_entry& lhs, const directory_entry& rhs) noexcept;bool operator>=(const directory_entry& lhs, const directory_entry& rhs) noexcept;}In 31.12.10.4[fs.dir.entry.obs]/6-11, edit as follows:
bool operator==(const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-6-Returns:
.pathobjectlhs.path() == rhs.pathobjectpath()bool operator!=(const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-7-Returns::
.pathobjectlhs.path() != rhs.pathobjectpath()bool operator< (const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-8-Returns::
.pathobjectlhs.path() < rhs.pathobjectpath()bool operator<<=(const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-9-Returns::
.pathobjectlhs.path() <= rhs.pathobjectpath()bool operator> (const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-10-Returns::
.pathobjectlhs.path() > rhs.pathobjectpath()bool operator>=(const directory_entry& lhs, const directory_entry& rhs)constnoexcept;-11-Returns::
.pathobjectlhs.path() >= rhs.pathobjectpath()
<cstddint> macros optional?Section: 17.4.1[cstdint.syn]Status:DupSubmitter: Thomas KoeppeOpened: 2016-08-10Last modified: 2017-03-21
Priority:3
View all otherissues in [cstdint.syn].
View all issues withDup status.
Discussion:
Are the macrosINT[8, 16, 32, 64]_MAX etc. optional?
<cstddint> header is specified to have all types and macros "defined the same as in C". But C is also unclear about this: the fixed-width types likeint32_t are optional in C and in C++. The corresponding macroINT32_MAX is defined in terms of an expression of the same type as the "corresponding type converted according to the integral promotions". But if the "corresponding type" does not exist, then surely the macro too cannot exist? It seems that the macros should also be optional.Suggested resolution: See e.g.here, or equivalent wording to the effect that the macrosINT*_MAX etc are defined if and only if the corresponding integer type is defined.(Note that the typesintptr_t anduintptr_t are also optional.)[2016-08-11, Richard comments]
C allows other values forN in addition to 8, 16, 32, 64, whereas it appears that C++ does not. Is the difference intentional?
[2016-09-09 Issues Resolution Telecon]
We need to answer Richard's question before making this ready
[2017-03-04, Kona]
Close as a duplicate of2820(i) per Thomas' request.
Proposed resolution:
insert(node) interfaceSection: 23.2.7[associative.reqmts], 23.2.8[unord.req], 23.4.2[associative.map.syn], 23.5.2[unord.map.syn]Status:NADSubmitter: Tomasz KamińskiOpened: 2016-09-06Last modified: 2018-01-28
Priority:2
View otheractive issues in [associative.reqmts].
View all otherissues in [associative.reqmts].
View all issues withNAD status.
Discussion:
In C++17 the interface of the uniquemap was extended to include following function:
pair<iterator, bool> try_emplace(const key_type& k, Args&&... args); //and move versioniterator try_emplace(const_iterator hint, const key_type& k, Args&&... args); //and move versioniterator insert(const_iterator hint, node_type&& nh)insert_return_type insert(node_type&& nh);
All of the functions share a common property, that they are performing basically no-operation in case when element with given key (part of node) is already stored in the map. However there is major difference in their interface. The first three functions:
pair<iterator, bool> try_emplace(key_type&& k, Args&&... args); //and copy versioniterator try_emplace(const_iterator hint, key_type&& k, Args&&... args); //and copy versioniterator insert(const_iterator hint, node_type&& nh)
are guaranteeing that the value of the arguments (k, nh, args...) will not be changed if the map already contains a key with given value, so the programmer is free to reuse it for their own purpose.
insert_return_type insert(node_type&& nh);
Theinsert_return_type is an unspecified type that contains:
bool inserted;X::iterator position;X::node_type node;
As we can see, theinsert function is returning anode. This difference is actuallymisleading, as the programmer may start to wonder, why the function returns anode handle, instead of being guaranteed that the argument will not be modified (as other functions do). Most reasonable explanation is that, this function actually return a handle to a differentnode, that one passed as the argument, i.e. this function replaces an existing node with thenh argument and returns thehandle to the oldnode. However, this function actually has the same semantics as the otherinsert function and returns anode that was passed as argument.
insert function for the map inconsistent. Value inserting functions are returningpair<iterator, bool> while node inserting function is returning an unspecified type with guaranteed set of members.The only potential benefit of this signature is that it could potentially allow programmer to use decomposition declaration, so instead of:auto nh = node_provider();if (map.insert(std::move(nh)).second) handle_node_in_other_way(std::move(nh));
The user would be able to write:
if (auto [it, ins, nh] = map.insert(node_provider); ins) handle_node_in_other_way(std::move(nh));
However, theinsert_return_type is not currently required to work with decomposition declaration, so this is only "potential" benefit that could be added in future.
insert in generic code:template<typename UniqMap, typename Elem>void log_duplicate_insertion(UniqMap& map, Elem&& elem){ if (auto [it, ins] = map.insert(std::forward<Elem>(elem)); !ins) std::cout << "attempt to insert duplicate for " << *it;}Currently,log_duplicate_insertion will not work withnode_handle_type.
insert(node_handle) function for associative containers with unique keys, to be consistent with the otherinsert operation andtry_emplace function. I.e. change the signature to:std::pair<iterator, bool> insert(node_type&& nh);
and provide the guarantee thatnh will be unchanged if an element was not inserted.
[2016-09-06, Howard comments]
[2018-1-26 issues processing telecon]
Status to 'NAD'; this is "specified as designed". This was considered during the design, but not accepted.
Proposed resolution:
reverse_iterator is does not compile for fancy pointersSection: 24.5.1.6[reverse.iter.elem]Status:DupSubmitter: Billy Robert O'Neal IIIOpened: 2016-09-23Last modified: 2021-06-06
Priority:Not Prioritized
View all otherissues in [reverse.iter.elem].
View all issues withDup status.
Duplicate of:1052
Discussion:
std::reverse_iterator<Iterator>::operator->() is specified to calladdressof(operator*()),but it returnsiterator_traits<Iterator>::pointer, which may be a fancy pointer type from which noconversion fromT* is possible. It should instead delegate to the underlying iterator'soperator->().
[Issues processing Telecon 2016-10-7]
Set status to Duplicate
Proposed resolution:
This wording is relative to N4606.
Modify [reverse.iter.opref] as indicated:
constexpr pointer operator->() const;-1-
Returns:Effects: Ifaddressof(operator*()).Iteratoris a pointer type, as if by:Iterator tmp = current;return --tmp;Otherwise, as if by:
Iterator tmp = current;--tmp;return tmp.operator->();
Section: 27.4.3.3[string.cons]Status:NADSubmitter: Jonathan WakelyOpened: 2016-11-15Last modified: 2017-01-30
Priority:Not Prioritized
View all otherissues in [string.cons].
View all issues withNAD status.
Discussion:
The new constructor added for LWG2742(i) causes an ambiguity when attempting to construct from a (non-const)char*
char s[] = "whoops"; std::string str(s, 2, 4);
This is the same problem discussed in2758(i), and the fix is the same: disable that new constructor ifT is convertible toconst_pointer, so that the old constructor is used instead.
Previous resolution [SUPERSEDED]:
This wording is relative to N4606.
Modify the new
basic_string(const T& t, size_type pos, size_type n, const Allocator& a = Allocator());constructor in 27.4.3.3[string.cons] as shown:template<class T>basic_string(const T& t, size_type pos, size_type n, const Allocator& a = Allocator());-?-Effects: Creates a variable,
sv, as if bybasic_string_view<charT, traits> sv = t;and then behaves the same as:basic_string(sv.substr(pos, n), a)-?-Remarks: This constructor shall not participate in overload resolution unless
is_convertible_v<const T&, basic_string_view<charT, traits>>istrueandis_convertible_v<const T&, const charT*>isfalse.
[2016-12-21, Jonathan comments and reommends NAD]
Tim Song pointed out that this constructor isn't ambiguous, and I canno longer reproduce the errors I was getting, so I think this issueshould be resolved NAD. The code snippet in the issue discussioncompiles OK without the proposed change.
[2017-01-27 Telecon]
NAD
Proposed resolution:
<cstdalign> (following adoption of P0063r3)Section: 21.3.6.4[meta.unary.prop]Status:NAD EditorialSubmitter: Thomas KoeppeOpened: 2016-11-20Last modified: 2020-09-06
Priority:Not Prioritized
View otheractive issues in [meta.unary.prop].
View all otherissues in [meta.unary.prop].
View all issues withNAD Editorial status.
Discussion:
In Oulu, we adoptedP0063r3 to base C++ on C11. C11 is the first version of C that defines a header<stdalign.h>. However, C++11 (!) already seems to have defined headers<cstdalign> and<stdalign.h>, even though C99 does not have<stdalign.h>.
<cstdalign> and to rebase C++ onto C11. However, the latter part didn't happen, leaving the header dangling without a sensible specification.I suggest two actions:<cstdalign> and<stdalign.h>.<cstdalign> as a new feature; I would like to revert that decision and not add this header. Instead, P0063r3 shouldonly add<stdalign.h> (which should be done in Annex D) for compatibility with C.<cstdalign>, we should at least put the specification of<cstdalign> into Annex D.Moreover, I would like to ask LWG for editorial dispensation to move the specifications of<ccomplex>,<ctgmath> and<cstdbool> wholly into Annex D, too, since these are now deprecated features that are not otherwise referred to or needed by the main text. An example change is availableon github, which incorporates solution 2b. Wording for solution 2a can be produced on request.
[2017-01-27 Telecon]
NAD Editorial; Thomas will make the editorial changes (option 2B)
Proposed resolution:
operator== forstd::basic_strings andstd::basic_string_views aredifficult to conform toSection: 27.4.4.2[string.cmp], 27.4.3.8.4[string.compare]Status:NADSubmitter: Ahti LeppänenOpened: 2017-01-09Last modified: 2021-06-06
Priority:2
View all issues withNAD status.
Discussion:
Currently (N4618, 2016-11-28) the specification ofoperator==forstd::basic_string andstd::basic_string_view objects is clearly defined, but wheninterpreted as written, it may lead to comparison of strings of different sizes being a 𝒪(n) operationinstead of a simple size check. Actual implementations in standard libraries vary so that in practice theprogrammers can't rely neither on having the literal version of the standard specification nor reasonableperformance characteristics.
basic_string operator== in N4618 is as follows:[string.operator==]
bool operator==(const basic_string<charT, traits, Allocator>& lhs, const basic_string<charT, traits, Allocator>& rhs) noexcept;-1-Returns:
lhs.compare(rhs) == 0.
27.4.3.8.4[string.compare]
int compare(const basic_string& str) const noexcept;-6-Effects: Equivalent to:
return compare(basic_string_view<charT, traits>(str));
27.4.3.8.4[string.compare]
int compare(basic_string_view<charT, traits> sv) const noexcept;-1-Effects: Determines the effective length
-2-Returns: The nonzero result if the result of the comparison is nonzero. Otherwise, returns a value asindicated in Table 63.rlenof the strings to compare as the smaller ofsize()andsv.size(). The function then compares the two strings by callingtraits::compare(data(),sv.data(), rlen).
Table 63 — compare()resultsCondition Return Value size() < sv.size()< 0size() == sv.size()0size() > sv.size()> 0
From these it seems thatcompare() of strings of different sizes can't return zero andoperator==will returnfalse. However some implementations do not seem to calltraits::compare() forbasic_strings of different sizes even when the traits and it'scompare() are user-defined. And thosethat call, make theoperator== a worst case 𝒪(n) operation even for strings of different sizes.
operator== forbasic_string andbasic_string_view(others?) in such a way that it's performance characteristics are reasonable and the programmers can rely on havinga consistent behaviour across implementations. Perhaps the key issue here is thatoperator== is definedthroughcompare() == 0: while it returns the intended result, for some inputs it does computations thatare not needed byoperator==. There are also related specifications that may need to be revised, for exampleoperator!= forbasic_string_views is defined in 27.3.4[string.view.comparison] asReturns:
lhs.compare(rhs) != 0
[2017-01-26, Jonathan Wakely comments and provides proposed resolution]
As mentioned above, some implementations do not make a call toTraits::compare if the string lengths are not equal,even though in general this is an observable side effect. Some implementations only perform that optimisation forstd::string andstd::wstring, where we know that calls tostd::char_traits<char>::compareandstd::char_traits<wchar_t>::compare are not observable.
Traits::compare is already permitted. But if my reading is wrong we need to permit this obvious optimisation.[2017-01-27 Telecon]
Priority 2
[2017-02-04, Ahti Leppänen comments and recommends NAD]
While there seems to be varying interpretations of the standards wording, given the comments in this defect report anddefinitions in [structure.specification] (N4618):
Effects: the actions performed by the function
Returns: a description of the value(s) returned by the function
I fail to see that the specification ofoperator== "Returns:lhs.compare(rhs) == 0" would require calltocompare() and no longer consider the report valid.
[2016-07, Toronto Saturday afternoon issues processing]
Status to NAD; we accept Jonathan's reasoning. Note that several implementations do this today.
Proposed resolution:
This wording is relative toN4618.
Preferred: NAD
Alternative:
Modify [string.operator==] p1 as shown:
template<class charT, class traits, class Allocator> bool operator==(const basic_string<charT, traits, Allocator>& lhs, const basic_string<charT, traits, Allocator>& rhs) noexcept;-1-Returns:
lhs.size() == rhs.size() && lhs.compare(rhs) == 0.
Modify 27.3.4[string.view.comparison] as shown:
[Example: A sample conforming implementation for
operator==would be:template<class T> using __identity = decay_t<T>;template<class charT, class traits> constexpr bool operator==(basic_string_view<charT, traits> lhs, basic_string_view<charT, traits> rhs) noexcept { returnlhs.size() == rhs.size() && lhs.compare(rhs) == 0; }template<class charT, class traits> constexpr bool operator==(basic_string_view<charT, traits> lhs, __identity<basic_string_view<charT, traits>> rhs) noexcept { returnlhs.size() == rhs.size() && lhs.compare(rhs) == 0; }template<class charT, class traits> constexpr bool operator==(__identity<basic_string_view<charT, traits>> lhs, basic_string_view<charT, traits> rhs) noexcept { returnlhs.size() == rhs.size() && lhs.compare(rhs) == 0; }—end example]
template<class charT, class traits> constexpr bool operator==(basic_string_view<charT, traits> lhs, basic_string_view<charT, traits> rhs) noexcept;-2-Returns:
lhs.size() == rhs.size() && lhs.compare(rhs) == 0.template<class charT, class traits> constexpr bool operator!=(basic_string_view<charT, traits> lhs, basic_string_view<charT, traits> rhs) noexcept;-3-Returns:
lhs.size() != rhs.size() || lhs.compare(rhs) != 0.
wstring_convert provides no indication of incomplete input or outputSection: 99 [depr.conversions.string]Status:NADSubmitter: PowerGamerOpened: 2017-01-08Last modified: 2017-06-05
Priority:3
View all otherissues in [depr.conversions.string].
View all issues withNAD status.
Discussion:
Example:
// Input UTF-16 string is incomplete - only first half of// UTF-16 surrogate pair L"\xD843\xDEF9":wchar_t in_utf16[] = L"\xD843";std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> cvt;auto out_utf8 = cvt.to_bytes(in_utf16); // No error.
There is no indication that input was incomplete (the value returnedbycvt.state() is not documented and so cannot be examined by user forthat purpose). As such the user will not know that more input datashould be provided in additional call tocvt.to_bytes().
"\xF0" inout_utf8.Again, no indication of incomplete output produced is provided bystd::wstring_convert.IMO it makesstd::wstring_convert in its current state completelyuseless (it cannot be relied upon to either produce complete and validUTF sequence or throw an error in all situations).Imagine a file has UTF16 encoded text. You want to read all the datafrom a file at once and convert it into UTF8 usingstd::wstring_convert<std::codecvt_utf8_utf16<wchar_t>>.Now, if a file contains completelyinvalid UTF16 (for example,forbidden or incorrectly encoded Unicode code points) you will get anexception fromstd::wstring_convert<std::codecvt_utf8_utf16<wchar_t>>.But if a file containsincomplete (but in all other regardsvalid)UTF16 (for ex. file ends with only the first half of a valid surrogatepair) you willneither get an error exception fromstd::wstring_convert<std::codecvt_utf8_utf16<wchar_t>>nor anyindication that the input provided tostd::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> was incomplete.[2017-01-27 Telecon]
Priority 3; send to LEWG
[2017-02 in Kona, LEWG recommends NAD]
[2017-06-02 Issues Telecon]
This facility has a number of known problems, including poor error handling.The feature has been deprecated, and the plan is to replace it with betterfacilities with a better API.
Resolve as NAD
Proposed resolution:
launder and base class subobjectsSection: 17.6.5[ptr.launder]Status:NADSubmitter: Hubert TongOpened: 2017-01-31Last modified: 2020-09-06
Priority:2
View all otherissues in [ptr.launder].
View all issues withNAD status.
Discussion:
There is an apparent oversight in the wording forlaunder that allows it to return base class subobjects which differ in their polymorphic behaviour between calls tolaunder.
This can be fixed by restrictinglaunder from returning pointers to base class subobjects:
always, or
only for polymorphic class types.
[2017-03-04, Kona]
Set priority to 2. This was discussed in EWG (via a paper). Assign this (and2859(i)) to Core.
[2017-08-14, CWG telecon note]
Core recommends NAD after discussion in EWG.
Hubert Tong summarizes the outcome of that discussion as follows:launderdoes not provide positive confirmation of the dynamic type of the object; it is intended thatlaundercan be used to induce a devirtualization barrier even when the static type of the (sub)object to which the returned pointer refers is apparently consistent with prior accesses related to the source pointer.
[2020-02 Status to NAD on Thursday night in Prague.]
Proposed resolution:
This wording is relative toN4618.
Option 1:
Modify 17.6.5[ptr.launder] as indicated:
template <class T> constexpr T* launder(T* p) noexcept;-1-Requires:
prepresents the addressAof a byte in memory. An objectXthat is within its lifetime (6.8.4[basic.life]) and whose type is similar (7.3.6[conv.qual]) toTis located at the addressA.Xshall either be a most derived object, or pointer-interconvertible with a most derived object that is within its lifetime. All bytes of storage that would be reachable through the result are reachable throughp(see below).
Option 2:
Modify 17.6.5[ptr.launder] as indicated:
template <class T> constexpr T* launder(T* p) noexcept;-1-Requires:
prepresents the addressAof a byte in memory. An objectXthat is within its lifetime (6.8.4[basic.life]) and whose type is similar (7.3.6[conv.qual]) toTis located at the addressA.IfTis a polymorphic class type, thenXshall be a most derived object. All bytes of storage that would be reachable through the result are reachable throughp(see below).
Section: 16[library]Status:NADSubmitter: FinlandOpened: 2017-02-03Last modified: 2017-03-12
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Addresses FI 2
All open Library Issues should be resolved.
Proposed change:
As LWG sees fit.
[2017-03-12, post-Kona]
Closing as NAD; this issue was opened by an over-zealous LWG chair.
Proposed resolution:
Section: 21.3.3[meta.type.synop]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2020-09-06
Priority:Not Prioritized
View otheractive issues in [meta.type.synop].
View all otherissues in [meta.type.synop].
View all issues withNAD status.
Discussion:
Addresses US 10
A user specialization of any type trait should produce an ill-formed program, not merely one whose behavior is unspecified.See also the related comment re 26.3.6.2[execpol.type].
Proposed change:
Reword the paragraph as follows:
Unless otherwise specified, a program that adds specializations for any of the templates defined in this subclause is ill-formed; no diagnostic required.
[2017-07 Toronto Thurs Issue Prioritization]
NAD; what the standard says is that this is "undefined", not "unspecified".
Proposed resolution:
This wording is relative toN4618.
Modify 21.3.3[meta.type.synop] as indicated:
-1-
The behavior of a program that adds specializations for any of the templates defined in this subclause isundefined unless otherwise specifiedUnless otherwise specified, a program that adds specializations for any of the templates defined in this subclause is ill-formed; no diagnostic required.
optional andvariant completely reflect the semantics of the element types — this is inconsistent with other types in the librarySection: 23[containers], 22[utilities]Status:NADSubmitter: FinlandOpened: 2017-02-03Last modified: 2025-10-16
Priority:Not Prioritized
View otheractive issues in [containers].
View all otherissues in [containers].
View all issues withNAD status.
Discussion:
Addresses FI 17The relational operators of optional and variant completely reflect the semantics of the element types; this is inconsistent with other types in the library, likepair,tuple and containers. If we believe it's important that we don't synthesize relational operators for wrapper types, we should believe it's important for other types as well. Otherwise comparing containers of floating-point types and tuples/pairs etc. of floating point types will give incorrect answers.
Proposed change: Make the relational operators of containers and utility components reflect the semantics of the operators for the underlying element types.
[2017-07 Toronto Thurs Issue Prioritization]
Move to LEWG
[2025-10-16 Status changed: LEWG → NAD.]
No defect for LWG to address.
Proposed resolution:
empty() functions inanySection: 22.7.4.5[any.observers]Status:NADSubmitter: FinlandOpened: 2017-02-03Last modified: 2020-09-06
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses FI 7The proposalp0032 has multiple problems: 1) it turns member function.empty() into.has_value(), negating the logic. Refactoring e.g. existing uses ofstd::experimental::any to usestd::any thus involve non-trivial refactorings that are error- prone and can't be done via simple search-and-replace if there are containers in the same source files for which.empty() is used (based on the implementation experience of making the change in libstdc++ and refactoring the testsuite). Whilstany is not a container, the library is failing to go towards a direction where there would be a generic way to query for emptiness. 2) The use of function references for tag types makes the interface hard to use. The tag types do not have value semantics like every other tag type has, the tag types are hard to construct, and present surprises for certain kinds of overload sets. Furthermore, any attempts to decay the tag types produces a really surprising effect — as opposed to what the other tag types do, which is that the result of decaying them is the tag type itself, decaying these new tag types results in a pointer to function.
Proposed change: Keep the.empty() functions (and introduce them to all the types that are supposed to have a homogeneous interface), and make the tag types be regular tag types that are not references to functions.
[2017-02-03, Marshall notes]
P0504R0 (adopted in Issaquah) removed use of function references for tag types
[2017-06-26 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
Proposed resolution:
volatile typesSection: 16.4.6[conforming]Status:NADSubmitter: Great BritainOpened: 2017-02-03Last modified: 2017-07-15
Priority:Not Prioritized
View all otherissues in [conforming].
View all issues withNAD status.
Discussion:
Addresses GB 35Most implementations have poor testing and support for instantiating standard library templates withvolatile-qualified types. We should grant a library-freedom to conforming implementations so that support forvolatile (andconst volatile)qualified types in standard library templates is not required unless explicitly specified — and mandate such support for all templates in the<type_traits> header. Additional support is already specified in most places we would be interested (e.g., tuple API). We may want to additionally guarantee support through forwarding references.
Proposed change: add a new 17.6.5.x Volatile Qualified Types [res.on.volatile.type] describing the intended level of support forvolatile qualifiers.
[2017-07 Toronto Thurs Issue Prioritization]
This is not a defect, but a feature request (and a large one). Papers welcome, but closing as NAD
Proposed resolution:
constexprSection: 16.4.6.7[constexpr.functions]Status:NADSubmitter: Great BritainOpened: 2017-02-03Last modified: 2020-09-06
Priority:1
View all otherissues in [constexpr.functions].
View all issues withNAD status.
Discussion:
Addresses GB 38Relax the prohibition on libraries addingconstexpr; this was a constraint requested by library implementers whenconstexpr was new, and those same implementers now feel unduly constrained.
Proposed change: Rewrite the whole sub-clause to support libraries addingconstexpr in a compatible manner, much like the freedom to add anoexcept specification.
[2017-02-20, Marshall adds wording]
The simplest change would be to strike the sentence "An implementation shall not […] explicitly required". However, people seem to want a definite permission here, so I have provided one.
[2017-07 Toronto Thurs Issue Prioritization]
Priority 1
[2018-06 Rapperswil Thursday issues processing]
This is a feature request; not a defect. We've had two cross-group meetings over this, and there is no consensus for changing this. Closing as NAD.
Proposed resolution:
This wording is relative toN4640.
Modify 16.4.6.7[constexpr.functions] as indicated:
This International Standard explicitly requires that certain standard library functions are constexpr (7.1.5).An implementation may declare additional standard library function signatures as constexpr
An implementation shall not declare any standard library function signature as constexpr except for those where it is explicitly required. Within any header that provides any non-defining declarations of constexpr functions or constructors an implementation shall provide corresponding definitions.
Section: 22[utilities]Status:NADSubmitter: Great BritainOpened: 2017-02-03Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [utilities].
View all issues withNAD status.
Discussion:
Addresses GB 45IfP0067R4 is applied consider how to parse hexadecimally:
to_chars(beg, end, 42, 16);16 for hex
to_chars(beg, end, 4.2, true);true means hex
to_chars(beg, end, 4.2, chars_format::hex);
to_chars(beg, end, 4.2, chars_format::hex, 2);
That is: We have 3 different formats to specify hex depending on value types and whether to use precision.Which application programmer should remember this?
May be even worse (I am not sure):
to_chars(beg, end, 4.2, 16);would silently convert 4.2 to 4 and
to_chars(beg, end, 4, chars_format::hex);would silently convert 4 to 4.000000.
Proposed change: The various options should be harmonized, possibly by use of an extended enum approach, having the values:dec, hex, scientific, fixed, generalwith dec (new!) as default for integral values and general for floats
[2017-02-23, Jens Maurer comments]
This issue is NAD; the facility was redesigned with these considerationsin mind before it went into the working draft.
[2017-06-26 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
Proposed resolution:
<codecvt> are underspecifiedSection: 99 [depr.locale.stdcvt]Status:DupSubmitter: Great BritainOpened: 2017-02-03Last modified: 2017-04-22
Priority:Not Prioritized
View all otherissues in [depr.locale.stdcvt].
View all issues withDup status.
Discussion:
Addresses GB 57The contents of<codecvt> are underspecified, and will take a reasonable amount of work to identify and correct all of the issues. There appears to be a general feeling that this is not the best way to address unicode transcoding in the first place, and this library component should be retired to Annex D, along side<strstream>, until a suitable replacement is standardized
Proposed change: Deprecate and move the whole of clause [locale.stdcvt] to Annex D.
[2017-02-03, Daniel comments]
This issue unintentionally became added a second time, it should be considered as a pure duplicate of LWG2869(i). By a wit of fortuity, both issues can also be transformed into each other by transposing the last two digits of the issue numbers.
Proposed resolution:
This issue is a duplicate of LWG2869(i).
Section: 16[library]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2017-06-02
Priority:Not Prioritized
View otheractive issues in [library].
View all otherissues in [library].
View all issues withNAD status.
Discussion:
Addresses US 106Review the whole library for constructors using member typedefs to name constructor parameters rather than template type parameters, as this inhibits class template deduction. e.g., theunique_lock explicit constructor taking themutex_type typedef would be better served namingMutex directly, to preserve support for deduction.
Proposed change: Review each constructor of each library class template, and revise specification of parameter types as needed.
[2017-03-03, Kona Friday morning]
This is no longer true; core has fixed this
Setting to NAD
Proposed resolution:
variant should only support complete typesSection: 22.6.3[variant.variant]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2020-09-06
Priority:0
View all otherissues in [variant.variant].
View all issues withNAD status.
Discussion:
Addresses US 114variant needs to know the size of an object in order to compute the size of its internal buffer, so require that anycv-qualified object type inTypes... be a complete type.
Proposed change: Add 'complete' in p2
[2017-07-01, Daniel comments]
I recommend to close this issue as NAD: According to 16.4.5.8[res.on.functions] p2 plus bullet (2.5):
-2- In particular, the effects are undefined in the following cases:
— […]
(2.5) — if an incomplete type (6.9) is used as a template argument when instantiating a template component,unless specifically allowed for that component.
In other words: The standard currently already requires type completeness for all types inTypes... ofstd::variant<Types...>, we therefore should not repeat that again (Note that other templates — such asshared_ptr —grant typeincompleteness allowance for that reason).
Previous resolution [SUPERSEDED]:
This wording is relative toN4618.
Edit 22.6.3[variant.variant]/2 as indicated:
All types inTypes...shall be (possiblycv-qualified) complete object types that are not arrays.
[2017-07-06 Moved to Tentatively NAD after 5 positive votes on c++std-lib.]
Proposed resolution:
The lack of the explicit constraint in 22.6.3[variant.variant] is not a defect, because the general requirements in 16.4.5.8[res.on.functions] p2 already impose the requested type completeness constraints.
shared_ptr are unclearSection: 20.3.2.2.3[util.smartptr.shared.dest]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2025-03-18
Priority:Not Prioritized
View all otherissues in [util.smartptr.shared.dest].
View all issues withNAD status.
Discussion:
Addresses US 134The semantics for destroying the deleter and the control-block are unclear. In particular, it is not clear that we guarantee a lack of race conditions destroying the control-block and deleter. Possible race-free implementations might destroy the deleter after runningd(p), and before giving up the weak reference held by thisshared_ptr; running the destructor ford only when the lastweak_ptr is destroyed, potentially at a much later date, but ensuring thatd(p) completes before theshared_ptr gives up its weak reference; making a copy ofd in the destructor before manipulating the weak count, and then using this copy to rund(p), even while the control-block could be concurrently reclaimed with an expiringweak_ptr in another thread. Note that this may be related to LWG2751(i). (Also, see the note in 20.3.2.2.11[util.smartptr.getdeleter] p1)
Proposed change: Clarify that theshared_ptr weak ownership of the control block is released at the end of the destructor, and not as the destructor begins. Otherwise, the deleter might be destroyed even before the destructor gets to move a copy to call safely.
[2017-07 Toronto Thurs Issue Prioritization]
NAD; Alisdair to provide rationale
Proposed resolution:
is_execution_policy should be ill-formedSection: 26.3.6.2[execpol.type]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2017-07-16
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Addresses US 14A user specialization of anyis_execution_policy should produce an ill-formed program, not merely one whose behavior is unspecified. See also the related comment re [meta.type.synop] (20.15.2). (US 10)
Proposed change: Reword the paragraph as follows:
See also LWG2871(i).Unless otherwise specified, a program that adds specializations for
is_execution_policyis ill-formed; no diagnostic required.
[2017-03-03, Kona Friday AM]
Jonathan: This breaks all known implementations of parallel algorithms, since they use custom execution policies.
Alisdair to check with SG1 to see if that's what they meant.
[2017-07 Toronto Thurs Issue Prioritization]
NAD; what the standard says is that this is "undefined", not "unspecified".
Proposed resolution:
integral_constantSection: 21.3.3[meta.type.synop]Status:DupSubmitter: United StatesOpened: 2017-02-03Last modified: 2020-09-06
Priority:Not Prioritized
View otheractive issues in [meta.type.synop].
View all otherissues in [meta.type.synop].
View all issues withDup status.
Discussion:
Addresses US 142An alias template using the new template template auto deduction would makeintegral_constant slightly easier to use.
[2017-07 Toronto Thurs Issue Prioritization]
Proposed resolution:
This wording is relative toN4618.
Add to the synopsis of<type_traits>:
template <auto N>using integer_constant = integral_constant<decltype(N), N>;
Section: 24.5.2[insert.iterators]Status:NADSubmitter: United StatesOpened: 2017-02-03Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [insert.iterators].
View all issues withNAD status.
Discussion:
Addresses US 151The three insert iterators should each have an instantiation guide to initialize from a container.
Proposed change:
Add to the<iterator> header synopsis:
template <class Container>back_insert_iterator(Container&) -> back_insert_iterator<Container>;template <class Container>front_insert_iterator(Container&) -> back_insert_iterator<Container>;template <class Container>insert_iterator(Container&, typename Container::iterator) -> insert_iterator<Container>;
[2017-07 Toronto Thurs Issue Prioritization]
After the core changes in Kona, these guides are no longer necessary; the implicit ones are sufficient.
Proposed resolution:
This wording is relative toN4618.
Add to the synopsis of<iterator>:
template <class Container> back_insert_iterator(Container&) -> back_insert_iterator<Container>;template <class Container> front_insert_iterator(Container&) -> back_insert_iterator<Container>;template <class Container> insert_iterator(Container&, typename Container::iterator) -> insert_iterator<Container>;
Section: 16.4.6.4[global.functions]Status:NADSubmitter: MorwennOpened: 2017-02-04Last modified: 2017-03-14
Priority:Not Prioritized
View all otherissues in [global.functions].
View all issues withNAD status.
Discussion:
Section 16.4.6.5[member.functions] makes it clear that standard library implementers are allowed to "replace a member function with default arguments with two or more member functions with equivalent behavior". However, it is unclear when reading 16.4.6.4[global.functions] whether implementers are allowed to perform the same transformation for non-member functions. 16.4.6.4[global.functions] p3 mentions that "an implementation shall not declare a non-member function signature with additional default arguments", but does not explicitly forbid to replace a function with default arguments with more functions with equivalent behavior.
The standard should make it clear whether such a transformation is conforming or not, probably through a note [global.functions].Link to theStandard Discussion forum.[2017-03-04, Kona]
We believe that [member.functions]p2 is clear.
Proposed resolution:
std::equal on empty rangesSection: 26.6.13[alg.equal]Status:NADSubmitter: Gennaro ProtaOpened: 2017-05-26Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [alg.equal].
View all issues withNAD status.
Discussion:
The description of thestd::equal() algorithm in the standard doesn'tmake clear what the result of it is on empty ranges:
std::equal(first, first, second) ; // what does this return?
It should IMHO return true (two empty ranges are always equal).
[2017-07 Toronto Monday issue prioritization]
Closing as NAD; the existing wording covers empty sequences
Proposed resolution:
This wording is relative toN4659.
Edit 26.6.13[alg.equal] as indicated:
[Drafting note: The current wording presented below uses two times the unusual phrase "[…] return […]" instead of "[…] returns […]". The project editor is kindly asked to consider to replace these unusual wording forms by the usual one. —end drafting note]
template<class InputIterator1, class InputIterator2> bool equal(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2);[…]-1-Remarks: If
-2-Returns:Iflast2was not given in the argument list, it denotesfirst2 + (last1 - first1)below.[first1, last1)and[first2, last2)are both empty, returnstrue. Iflast1 - first1 != last2 - first2, returnfalse. Otherwise returntrueif for every iteratoriin the range[first1, last1)the following corresponding conditions hold:*i == *(first2 + (i - first1)), pred(*i, *(first2 + (i - first1))) != false. Otherwise, returnsfalse.[…]
variant should requireDestructible typesSection: 22.6.3[variant.variant]Status:NADSubmitter: Agustín K-ballo BergéOpened: 2017-05-31Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [variant.variant].
View all issues withNAD status.
Discussion:
The state of avariant is not specified if an exception is thrown duringthe destruction of the active alternative. Exceptions should not beallowed to escape during destruction of an object used as avariantalternative. Otherwise, it should be specified that thevariant objectmight not hold a value.
[2017-07 Toronto Monday issue prioritization]
NAD; [res.on.functions]/2 already gives us this guarantee.
Proposed resolution:
This wording is relative toN4659.
Edit 22.6.3[variant.variant] as indicated:
-2- All types in
Types...shall be (possibly cv-qualified) object types that are not arrays, and shall satisfy the requirements ofDestructible(Table 27).
system_category() anderror_code::error_code() should beconstexprSection: 19.5.3.5[syserr.errcat.objects], 19.5.4.2[syserr.errcode.constructors]Status:NADSubmitter: Peter DimovOpened: 2017-06-27Last modified: 2017-07-12
Priority:Not Prioritized
View all otherissues in [syserr.errcat.objects].
View all issues withNAD status.
Discussion:
The default constructor oferror_code should beconstexpr to enable constant initialization; as a practical matter, there are reports that it regularly shows up in profiles because clearing error codes is so frequent.
addconstexpr to the declaration ofsystem_category() in [syserr.errcat.overview] and [syserr.errcat.objects];
optionally, addconstexpr to the declaration ofgeneric_category() in the same two sections;
addconstexpr to the default constructor oferror_code in [syserr.errcode.overview] and [syserr.errcode.constructors];
optionally, addconstexpr to theerror_code(int val, const error_category& cat) constructor in the same two sections;
optionally, addconstexpr toerror_code::assign;
optionally, addconstexpr toerror_code::clear;
optionally, addconstexpr toerror_code::value;
optionally, addconstexpr toerror_code::category.
There was an objection thatsystem_category() can't be madeconstexpr because it needs to "immortalize" the object so that it's not destroyed at process shutdown or module unload, in order for theerror_code facility to remain usable. However, thefollowing proof of concept shows how to achieve this and still make the functionconstexpr:
#include <new>template<class _Ty> union _Immortalizer { // constructs _Ty, never destroys constexpr _Immortalizer(): __ty() { } ~_Immortalizer() noexcept {} _Immortalizer(const _Immortalizer&) = delete; _Immortalizer& operator=(const _Immortalizer&) = delete; _Ty __ty;};struct error_category{ virtual ~error_category() = default;};struct system_category_impl : public error_category{};[[clang::require_constant_initialization]] static const _Immortalizer<system_category_impl> _System_category;constexpr error_category const& system_category() noexcept{ return _System_category.__ty;}struct error_code{ int val_; const error_category* cat_; constexpr error_code() noexcept : val_(0), cat_(&system_category()) {} constexpr int value() const noexcept { return val_; } constexpr error_category const& category() const noexcept { return *cat_; }};constexpr error_code s_code;static_assert(s_code.value() == 0);static_assert(&s_code.category() == &system_category());[2017-07 Toronto Tuesday PM issue prioritization]
NAD; This is a feature request; needs a paper.
Proposed resolution:
This wording is relative toN4659.
Edit 19.5.3.1[syserr.errcat.overview], classerror_category synopsis, as indicated:
class error_category {public: constexpr error_category() noexcept; virtual ~error_category(); error_category(const error_category&) = delete; error_category& operator=(const error_category&) = delete; virtual const char* name() const noexcept = 0; virtual error_condition default_error_condition(int ev) const noexcept; virtual bool equivalent(int code, const error_condition& condition) const noexcept; virtual bool equivalent(const error_code& code, int condition) const noexcept; virtual string message(int ev) const = 0; bool operator==(const error_category& rhs) const noexcept; bool operator!=(const error_category& rhs) const noexcept; bool operator<(const error_category& rhs) const noexcept;};constexpr const error_category& generic_category() noexcept;constexpr const error_category& system_category() noexcept;Edit 19.5.3.5[syserr.errcat.objects] as indicated:
constexpr const error_category& generic_category() noexcept;[…]
constexpr const error_category& system_category() noexcept;[…]
Edit 19.5.4.1[syserr.errcode.overview], classerror_code synopsis, as indicated:
class error_code {public: // 19.5.4.2[syserr.errcode.constructors], constructorsconstexpr error_code() noexcept;constexpr error_code(int val, const error_category& cat) noexcept; template <class ErrorCodeEnum> error_code(ErrorCodeEnum e) noexcept; // 19.5.4.3[syserr.errcode.modifiers], modifiersconstexpr void assign(int val, const error_category& cat) noexcept; template <class ErrorCodeEnum> error_code& operator=(ErrorCodeEnum e) noexcept;constexpr void clear() noexcept; // 19.5.4.4[syserr.errcode.observers], observersconstexpr int value() const noexcept;constexpr const error_category& category() const noexcept; error_condition default_error_condition() const noexcept; string message() const; explicit operator bool() const noexcept; private: int val_; // exposition only const error_category* cat_; // exposition only};Edit 19.5.4.2[syserr.errcode.constructors] as indicated:
constexpr error_code() noexcept;[…]
constexpr error_code(int val, const error_category& cat) noexcept;[…]
Edit 19.5.4.3[syserr.errcode.modifiers] as indicated:
constexpr void assign(int val, const error_category& cat) noexcept;[…]
constexpr void clear() noexcept;[…]
Edit 19.5.4.4[syserr.errcode.observers] as indicated:
constexpr int value() const noexcept;[…]
constexpr const error_category& category() const noexcept;[…]
optional and over-aligned typesSection: 22.5.3[optional.optional]Status:NADSubmitter: Tim SongOpened: 2017-09-04Last modified: 2020-09-06
Priority:3
View all otherissues in [optional.optional].
View all issues withNAD status.
Discussion:
LWG issue2555(i) added "It is implementation-defined whether over-aligned types are supported (C++14 §3.11)."to the specification ofstd::experimental::optional in LFTS, however that issue wasn't moved untiloptional had already been merged to the IS working paper, so it isn't present in the specification ofstd::optional. Should the same rule be added forstd::optional as well?
[2017-11 Albuquerque Wednesday night issues processing]
Priority set to 3; Casey to provide rationale for closing as NAD.
2018-11 Closed as NAD with the adoption ofP0899R1
Proposed resolution:
This wording is relative toN4687.
Edit 22.5.3[optional.optional] p1 as indicated:
[…] The contained value shall be allocated in a region of the
optional<T>storage suitably aligned for the typeT.It is implementation-defined whether over-aligned types are supported (6.8.3[basic.align]). When an object of typeoptional<T>is contextually converted tobool, the conversion returnstrueif the object contains a value; otherwise the conversion returnsfalse.
basic_string move ctor is underspecifiedSection: 27.4.3.3[string.cons]Status:NAD EditorialSubmitter: Peter SommerladOpened: 2017-11-09Last modified: 2017-11-29
Priority:Not Prioritized
View all otherissues in [string.cons].
View all issues withNAD Editorial status.
Discussion:
The standard has a hole in the specification ofbasic_string's move constructor that seems not only be editorial.In 27.4.3.3[string.cons] p2:
basic_string(const basic_string& str);basic_string(basic_string&& str) noexcept;Effects: Constructs an object of class
basic_stringas indicated in Table 56. In the second form,stris left in a valid state with an unspecified value.
refers to Table 56, but that table only speaks about copy-ctor. According to Pablo, move and copy differ in what they do.Move ctor ofbasic_string needs separate table (entry) to describe what happens.
[28-Nov-2017 After discussion on the ML, closing as NAD Editorial]
Proposed resolution:
basic_string tobasic_string_viewSection: 27.3.3[string.view.template]Status:NADSubmitter: Antony PolukhinOpened: 2018-02-19Last modified: 2022-08-24
Priority:2
View all otherissues in [string.view.template].
View all issues withNAD status.
Discussion:
It is known that we cannot disable move construction ofbasic_string_view from rvalues ofbasic_string, because it breaks avalid use case:
string foo();void bar(string_view );bar(foo());
Though it is still possible to disable an absolutely wrong case ofassigning an rvaluebasic_string tobasic_string_view:
string_view sw = "Hello";sw = foo();
Some tests that make sure that other use cases are not affected are availablehere
[2018-06-18 after reflector discussion]
Priority set to 2; status to LEWG
[2020-05-28; LEWG issue reviewing]
LEWG issue processing voted to reject 3068 as NAD. Status change to Open.
SF F N A SA15 5 1 0 0
[2022-08-24 Status changed: Open → NAD.]
LWG telecon: close based on LEWG direction."This makes string_view depend on basic_string.""Request a paper with implementation if someone really wants this."
Proposed resolution:
This wording is relative toN4727.
Change 27.3.3[string.view.template], class templatebasic_string_view synopsis, as indicated:
[…]// 27.3.3.2[string.view.cons], construction and assignmentconstexpr basic_string_view() noexcept;constexpr basic_string_view(const basic_string_view&) noexcept = default;constexpr basic_string_view& operator=(const basic_string_view&) noexcept = default;template <class A>basic_string_view& operator=(const basic_string<charT, traits, A>&&) = delete;constexpr basic_string_view(const charT* str);constexpr basic_string_view(const charT* str, size_type len);[…]
nothrow should beinline constexpr rather thatextern constSection: 17.6.2[new.syn]Status:NADSubmitter: Antony PolukhinOpened: 2018-04-25Last modified: 2020-09-06
Priority:2
View all issues withNAD status.
Discussion:
std::nothrow in [new.syn] is declared as 'extern const nothrow_t nothrow;'. Unfortunately this declaration requires linking with Standard Library (which does not work well on GCC with-nostdlib flag).Moreover the declaration differs from other Standard Library tags that are 'inline constexpr'.
[2018-06-18 after reflector discussion]
Priority set to 2
[2018-08-23 Batavia Issues processing]
Status to Tentatively NAD - if we had a status 'Wont Fix' that would be correct.
This is an ABI break for most implementations, and people can define their own variable of typestd::nothrow_t if they want a constexpr one.
Proposed resolution:
This wording is relative toN4741.
Edit 17.6.2[new.syn] as indicated:
struct nothrow_t { explicit nothrow_t() = default; };extern constinline constexpr nothrow_t nothrow;Section: 99 [support.contract.cviol]Status:NADSubmitter: Tim SongOpened: 2018-07-10Last modified: 2019-08-05
Priority:2
View all otherissues in [support.contract.cviol].
View all issues withNAD status.
Discussion:
contract_violation has anassertion_level member function that is specified to return text "describing theassertion-levelof the violated contract". There is, however, noassertion-level in [dcl.attr.contract], onlycontract-level.
[2018-11 Reflector prioritization]
Set Priority to 2
[Post Cologne Mailing]
Contracts were removed from the C++20 draft in Cologne; closing as NAD.
Proposed resolution:
contract_violation's special member functionsSection: 99 [support.contract.cviol]Status:NADSubmitter: Tim SongOpened: 2018-07-10Last modified: 2019-08-05
Priority:1
View all otherissues in [support.contract.cviol].
View all issues withNAD status.
Discussion:
contract_violation is currently defined as:
class contract_violation {public: uint_least32_t line_number() const noexcept; string_view file_name() const noexcept; string_view function_name() const noexcept; string_view comment() const noexcept; string_view assertion_level() const noexcept;};which implies a full set of defaulted special member functions with entirely unclear semantics, and can arguably be read to imply that it is an aggregate.
It seems unlikely that we meant for users to default construct or copycontract_violation objects, but if we did want to do that, we need to at least specify the behavior of a default constructedcontract_violationobject and how copying and moving work with respect to the lifetime of the strings referenced by thestring_views returned by its member functions.[2018-11 Reflector prioritization]
Set Priority to 1
[2019 Cologne Wednesday night]
= delete for copy/move assignment; Status to 'Open'; Daniel to provide wording
[Post Cologne Mailing]
Contracts were removed from the C++20 draft in Cologne; closing as NAD.
Proposed resolution:
Section: 16.2 [networking.ts::buffer.reqmts]Status:NADSubmitter: Vinnie FalcoOpened: 2018-10-07Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [networking.ts::buffer.reqmts].
View all issues withNAD status.
Discussion:
Addresses: networking.tsBuffer sequence iterators in [networking.ts] differ from the currentstandard iterator requirements in that the value returned upondereferencing is not required to be a reference type. This change isvital for allowing authors to create useful, lazily-evaluated viewswhich meet the requirements of buffer sequences. Unfortunately theupdated language is incompatible with the standard iterator requirementsfor equality testing, because the addresses of value types returned bybuffer sequence iterators may not be stable. The change proposed inthis defect report defines a new metric for buffer sequence iteratorequality.
11-2018 Status to NAD after discussion on the reflector.
Proposed resolution:
This wording is relative to theN4734.
Modify 16.2.1 [networking.ts::buffer.reqmts.mutablebuffersequence], Table 12 "MutableBufferSequence requirements", as indicated:
Table 12 — MutableBufferSequence requirements expression return type assertion/note
pre/post-conditionnet::buffer_sequence_begin(x)
net::buffer_sequence_end(x)An iterator type whose referencetype
is convertible tomutable_bufferand which
satisfies all the requirements for bidirectional
iterators (C++ 2014 [bidirectional.iterators]) except that:
- there is no requirement that
operator->is provided, and- there is no requirement that
reference
be a reference type., and- for iterators
aandb
there is no requirement thata == bif and
only if*aand*bare bound to the
same object, anda == bif and only ifdistance(buffer_sequence_begin(x), a) == distance(buffer_sequence_begin(x), b)[…]
Modify 16.2.2 [networking.ts::buffer.reqmts.constbuffersequence], Table 13"ConstBufferSequence requirements", as indicated:
Table 13 — ConstBufferSequence requirements expression return type assertion/note
pre/post-conditionnet::buffer_sequence_begin(x)
net::buffer_sequence_end(x)An iterator type whose referencetype is convertible toconst_bufferand which satisfies all the requirements for
bidirectional iterators (C++ 2014 [bidirectional.iterators]) except that:
- there is no requirement that
operator->is provided, and- there is no requirement that
referencebe a reference
type., and- for iterators
aandbthere is no
requirement thata == bif and only if*aand*bare bound to the same object, anda == bif and only ifdistance(buffer_sequence_begin(x), a) == distance(buffer_sequence_begin(x), b)[…]
unique_ptr with reference deleterSection: 20.3.1.3.2[unique.ptr.single.ctor]Status:NADSubmitter: Jonathan WakelyOpened: 2018-10-09Last modified: 2018-11-27
Priority:Not Prioritized
View all otherissues in [unique.ptr.single.ctor].
View all issues withNAD status.
Discussion:
[unique.ptr.single.ctor] defines these constructors:
unique_ptr(pointer p, const D& d) noexcept;unique_ptr(pointer p, remove_reference_t<D>&& d) noexcept;
and p13 says:
Remarks: If
Dis a reference type, the second constructor is definedas deleted. These constructors shall not participate in overload resolution unlessis_constructible_v<D, decltype(d)>is true.
The first sentence in theRemarks has no effect. IfD is a referencetypeA&, then for the second constructor the condition isis_constructible<A&, A&&> which isfalse. So the second constructor never participates in overload resolution for reference deleters, andso it's irrelevant whether it's deleted or not.
is_constructibleconstraint so that the deleted constructor participates in overloadresolution for deleters of reference type. That way trying toinitialize a deleter of reference type from an rvalue will resolve tothe deleted function as intended.I think we can just change the "shall not participate" condition to only apply to non-reference deleters. For reference deleters the condition is always true for the first constructor, becauseis_constructible<A&, A&> istrue, and alwaysfalse for the second constructor (but we want it to be true so the deleted constructor is used). So for both constructors, the "shall not participate" isn't useful whenD is a reference type.11-2018 Status to NAD after discussion on the reflector.
Proposed resolution:
This wording is relative toN4778.
Change 20.3.1.3.2[unique.ptr.single.ctor] as indicated:
unique_ptr(pointer p, const D& d) noexcept;unique_ptr(pointer p, remove_reference_t<D>&& d) noexcept;[…]
-11-Remarks: IfDis a reference type, the second constructor is defined as deleted.IfDis not a reference type, tThese constructors shall not participate in overload resolution unlessis_constructible_v<D, decltype(d)>istrue.[…]
starts_with() overloads should be called "begins_with"Section: 27.4.3[basic.string], 27.3.3[string.view.template]Status:NADSubmitter: Gennaro ProtaOpened: 2018-10-22Last modified: 2020-08-21
Priority:2
View otheractive issues in [basic.string].
View all otherissues in [basic.string].
View all issues withNAD status.
Discussion:
Throughout the standard library, the opposite of the verb "to end" is "to begin", not to "to start". In this respect, all the overloads ofstd::basic_string::starts_with andstd::basic_string_view::starts_with are named inconsistently. These calls were added inP0457R2, which refers to analogous functions in Java, Python, Qt, LLVM, WebKit, all of which use the term "start". But, in our opinion, the C++ standard library should first be consistent with itself.
[2018-11: Referred to LEWG after reflector discussion.]
[2020-05-28; LEWG issue reviewing]
LEWG issue processing voted to reject 3165 as NAD. Status change to Open.
Reject LWG3165 as NADSF F N A SA21 1 0 1 0
[2020-08-21; Issue processing telecon: moved to NAD based on LEWG recommendation]
Proposed resolution:
This wording is relative toN4778.
Change 27.4.3[basic.string], class templatebasic_string synopsis, as indicated:
boolbeginstarts_with(basic_string_view<charT, traits> x) const noexcept;boolbeginstarts_with(charT x) const noexcept;boolbeginstarts_with(const charT* x) const;
Change 27.4.3.8.5[string.starts.with] as indicated
boolbeginstarts_with(basic_string_view<charT, traits> x) const noexcept;boolbeginstarts_with(charT x) const noexcept;boolbeginstarts_with(const charT* x) const;-1-Effects: Equivalent to:
return basic_string_view<charT, traits>(data(), size()).beginstarts_with(x);
Change 27.3.3[string.view.template], class templatebasic_string_view synopsis, as indicated:
constexpr boolbeginstarts_with(basic_string_view x) const noexcept;constexpr boolbeginstarts_with(charT x) const noexcept;constexpr boolbeginstarts_with(const charT* x) const;
Change 27.3.3.8[string.view.ops] as indicated:
constexpr boolbeginstarts_with(basic_string_view x) const noexcept;-20-Effects: Equivalent to:
return compare(0, npos, x) == 0;constexpr boolbeginstarts_with(charT x) const noexcept;-21-Effects: Equivalent to:
returnbeginstarts_with(basic_string_view(&x, 1));constexpr boolbeginstarts_with(const charT* x) const;-22-Effects: Equivalent to:
returnbeginstarts_with(basic_string_view(x));
split_view::outer_iterator converting constructor is misconstrainedSection: 25.7.16.3[range.lazy.split.outer]Status:NADSubmitter: Casey CarterOpened: 2019-01-05Last modified: 2023-02-07
Priority:Not Prioritized
View otheractive issues in [range.lazy.split.outer].
View all otherissues in [range.lazy.split.outer].
View all issues withNAD status.
Discussion:
The constraints onsplit_view::outer_iterator's converting constructor:
are problematic. Sinceconstexpr outer_iterator(outer_iterator<!Const> i) requires Const && ConvertibleTo<iterator_t<V>, iterator_t<const V>>;
const V doesn't depend on a template parameterofouter_iterator, compilers want to expanditerator_t<const V> whenouter_iterator is instantiated- regardless of the value ofConst - which can result in a hard errorwheniterator_t<const V> is ill-formed. The constraint shouldinstead useiterator_t<Base>, as do the similar convertingconstructors for the other range adaptor iterator and sentinel types.[2019-01-20 Reflector prioritization]
Set status to NAD
Proposed resolution:
This wording is relative toN4791.
Change [range.split.outer] as follows:
namespace std::ranges { template<class V, class Pattern> template<bool Const> struct split_view<V, Pattern>::outer_iterator { […] constexpr outer_iterator(outer_iterator<!Const> i) requires Const && ConvertibleTo<iterator_t<V>, iterator_t<const VBase>>; […] };}[…]
constexpr outer_iterator(outer_iterator<!Const> i) requires Const && ConvertibleTo<iterator_t<V>, iterator_t<const VBase>>;-4-Effects: Initializes
parent_withi.parent_andcurrent_withstd::move(i.current_).[…]
N inssize(const T (&)[N]) should besize_tSection: 24.7[iterator.range]Status:NADSubmitter: Nevin LiberOpened: 2019-05-23Last modified: 2020-11-09
Priority:Not Prioritized
View otheractive issues in [iterator.range].
View all otherissues in [iterator.range].
View all issues withNAD status.
Discussion:
TheN inssize(const T (&)[N]) is specified to be of typeptrdiff_t. It should besize_t to be consistent with the rest of the standard library, such as thearray overloads for all other range access functions, theswap overload for arrays, andother function template overloads for arrays. (Note: the return type of this function should still beptrdiff_t.)
[2019-06-12 Tentatively NAD after reflector discussion]
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4810.
Modify 24.7[iterator.range] as indicated:
template<class T,ptrdiffsize_t N> constexpr ptrdiff_t ssize(const T (&array)[N]) noexcept;-19-Returns:
static_cast<ptrdiff_t>(N).
Section: 30.13[time.parse]Status:NADSubmitter: Howard HinnantOpened: 2019-09-02Last modified: 2020-09-06
Priority:3
View otheractive issues in [time.parse].
View all otherissues in [time.parse].
View all issues withNAD status.
Discussion:
from_stream overloads may need to set various formatting state and flags of thebasic_istream to implement the parsing functionality. Such settings must not persist beyond the parsing functions. Thus these functions need to save and restore any settings on thebasic_istream they may need to change.
[2019-10 Priority set to 3 after reflector discussion]
[2020-02, Prague; Close as NAD]
LWG reviewed the issue and decided no change is needed.Unless specified to change the flags, it's assumed that the stream flags areunchanged by any input function.Proposed resolution:
This wording is relative toN4830.
[Drafting note: The modification of 30.13[time.parse] p1 is intended to be non-conflictingly mergeable with the change suggested by LWG3269(i) at the same paragraph.]
Modify 30.13[time.parse] as indicated:
-1- Each parse overload specified in this subclause calls
[…]-10- Allfrom_streamunqualified, so as to enable argument dependent lookup (6.5.4[basic.lookup.argdep]).In the following paragraphs, letisdenote an object of typebasic_istream<charT, traits>, wherecharTandtraitsare template parameters in that context.from_streamoverloads behave as unformatted input functions, except that they have an unspecified effect on the value returned by subsequent calls tobasic_istream<>::gcount().Any changes made tois.fill(),is.width()oris.flags()are undone prior to an returning or exceptional execution ([thread.once.callonce]). Each overload takes a format string containing ordinary characters and flags which have special meaning. Each flag begins with a%. Some flags can be modified byEorO. During parsing each flag interprets characters as parts of date and time types according to Table [tab:time.parse.spec]. Some flags can be modified by a width parameter given as a positive decimal integer called out asNbelow which governs how many characters are parsed from the stream in interpreting the flag. All characters in the format string that are not represented in Table [tab:time.parse.spec], except for white space, are parsed unchanged from the stream. A white space character matches zero or more whitespace characters in the input stream.
viewable_rangeSection: 25.7.11.2[range.take.while.view], 25.7.12.2[range.drop.view], 25.7.13.2[range.drop.while.view]Status:NADSubmitter: Christopher Di BellaOpened: 2019-09-24Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [range.take.while.view].
View all issues withNAD status.
Discussion:
After adoption ofP1035 range adaptor closure is described to take aviewable_range as input, and return a view as output. The deduction-guides fortake_while_view,drop_view, anddrop_while_view do not currently impose theviewable_range requirement.
[2020-02 Status to NAD on Thursday morning in Prague.]
Proposed resolution:
This wording is relative toN4830.
Modify 25.7.11.2[range.take.while.view], class templatetake_while_view synopsis, as indicated:
namespace std::ranges { […] template<classinput_range R, class Pred>requires viewable_range<R> && indirect_unary_predicate<const Pred, iterator_t<R>> take_while_view(R&&, Pred) -> take_while_view<all_view<R>, Pred>;}Modify 25.7.12.2[range.drop.view], class templatedrop_view synopsis, as indicated:
namespace std::ranges { […] template<classinput_range R>requires viewable_range<R> drop_view(R&&, range_difference_t<R>) -> drop_view<all_view<R>>;}Modify 25.7.13.2[range.drop.while.view], class templatedrop_while_view synopsis, as indicated:
namespace std::ranges { […] template<classinput_range R, class Pred>requires viewable_range<R> && indirect_unary_predicate<const Pred, iterator_t<R>> drop_while_view(R&&, Pred) -> drop_while_view<all_view<R>, Pred>;}basic_string::operator=(charT c) should be constrainedSection: 27.4.3.3[string.cons]Status:DupSubmitter: RussiaOpened: 2019-11-04Last modified: 2019-11-16
Priority:Not Prioritized
View all otherissues in [string.cons].
View all issues withDup status.
Discussion:
Addresses RU 013
Because of the implicit conversion of arithmetic types it is error prone to use thebasic_string::operator=(charT c):
double d = 3.14;std::string s;s = d; // Compiles
Make sure that the program is ill-formed if an implicit conversion from arithmetic type happens whileassigning tostd::basic_string. Or at least make sure that the program is ill-formed if an implicit conversion from floating point type happens while assigning tostd::basic_string.
[2019-11 Status to Duplicate during Tuesday morning issue processing in Belfast.]
Proposed resolution:
This wording is relative toN4835.
Modify 27.4.3[basic.string] p3, class templatebasic_string synopsis, as indicated:
template<class T>constexpr basic_string& operator=(charT c);
Modify 27.4.3.3[string.cons] as indicated:
template<class T>constexpr basic_string& operator=(charT c);-?-Constraints:
-30-Effects: Equivalent to:is_same_v<T, charT>istrue.return *this = basic_string_view<charT, traits>(addressof(c), 1);
polymorphic_allocator::allocate_object andnew_object should be[[nodiscard]]Section: 20.5.3[mem.poly.allocator.class]Status:DupSubmitter: United StatesOpened: 2019-11-04Last modified: 2019-11-16
Priority:Not Prioritized
View all otherissues in [mem.poly.allocator.class].
View all issues withDup status.
Discussion:
Addresses US 217
Add[[nodiscard]] in front of the return type forallocate_object andnew_object in classdeclaration and in member-function description forpolymorphic_allocator template.
[Daniel comments]
This issue is related to LWG3304(i).
[2019-11 Status to Duplicate during Tuesday morning issue processing in Belfast.]
Proposed resolution:
This wording is relative toN4835.
Modify 20.5.3[mem.poly.allocator.class] p2, class templatepolymorphic_allocator synopsis, as indicated:
// 20.5.3.3[mem.poly.allocator.mem], member functions[[nodiscard]] Tp* allocate(size_t n);void deallocate(Tp* p, size_t n);void* allocate_bytes(size_t nbytes, size_t alignment = alignof(max_align_t));void deallocate_bytes(void* p, size_t nbytes, size_t alignment = alignof(max_align_t));template<class T>[[nodiscard]] T* allocate_object(size_t n = 1);template<class T> void deallocate_object(T* p, size_t n = 1);template<class T, class... CtorArgs>[[nodiscard]] T* new_object(CtorArgs&&... ctor_args);template<class T> void delete_object(T* p);
Modify 20.5.3.3[mem.poly.allocator.mem] as indicated:
template<class T>[[nodiscard]] T* allocate_object(size_t n = 1);-8-Effects: Allocates memory suitable for holding an array of
nobjects of typeT, as follows:[…]
(8.1) — if
SIZE_MAX / sizeof(T) < n, throwslength_error,(8.2) — otherwise equivalent to:
return static_cast<T*>(allocate_bytes(n*sizeof(T), alignof(T)));template<class T, class CtorArgs...>[[nodiscard]] T* new_object(CtorArgs&&... ctor_args);-11-Effects: Allocates and constructs an object of type
T, as follows.Equivalent to:[…]T* p = allocate_object<T>();try { construct(p, std::forward<CtorArgs>(ctor_args)...);} catch (...) { deallocate_object(p); throw;}return p;
ranges::cbegin/ranges::cend, (and mayberanges::crbegin/ranges::crend) are under-specified to allow rvalue-arraysSection: 25.3.4[range.access.cbegin], 25.3.5[range.access.cend]Status:NADSubmitter: Christopher Di BellaOpened: 2019-11-06Last modified: 2020-02-13
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
The following should be ill-formed, but is not, likely due to decay-to-pointer or reference collapsing.
double x[321];ranges::cbegin(std::move(x));// should be ill-formedranges::cend(std::move(x));// should be ill-formed
This might be a problem forranges::crbegin andranges::crend, but I haven't implemented any ofrbegin,rend,crbegin, andcrend to confirm as much.
[2020-02 Status to NAD on Thursday morning in Prague.]
Proposed resolution:
This wording is relative toN4835.
Change 25.3.4[range.access.cbegin] as indicated:
-1- The name
ranges::cbegindenotes a customization point object (16.3.3.3.5[customization.point.object]).If tThe expressionranges::for some subexpressioncbegin(E)Eof typeTis well-formed, then the expressionranges::cbegin(E)is expression-equivalent to:
(1.1) —
ranges::begin(static_cast<const T&>(E))ifEis an lvalue.(1.2) — Otherwise,
ranges::begin(static_cast<const T&&>(E)).
Change 25.3.5[range.access.cend] as indicated:
-1- The name
ranges::cenddenotes a customization point object (16.3.3.3.5[customization.point.object]).If tThe expressionranges::for some subexpressioncend(E)Eof typeTis well-formed, then the expressionranges::cend(E)is expression-equivalent to:
(1.1) —
ranges::end(static_cast<const T&>(E))ifEis an lvalue.(1.2) — Otherwise,
ranges::end(static_cast<const T&&>(E)).
Section: 25.7.14.3[range.join.iterator]Status:NADSubmitter: Johel Ernesto Guerrero PeñaOpened: 2020-01-07Last modified: 2020-11-09
Priority:0
View all otherissues in [range.join.iterator].
View all issues withNAD status.
Discussion:
The name ofjoin_view::iterator::ref-is-glvalue, defined asis_reference_v<range_reference_t<Base>>, doesn't take into account the fact that it may also be true becauserange_reference_t<Base>is an rvalue (e.g. formove_iterator<int>).
We suggest renaming it toderef-is-ref.
[2020-01-14 Status set to Tentatively NAD after five positive votes on the reflector. This issue was based on a misunderstanding by the submitter which had been cleared up in anrelated editorial issue.]
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
Rename all occurrences referring to the symboljoin_view::iterator::ref-is-glvalue toderef-is-ref.
ranges::basic_istream_view::iterator has an emptyiterator_traitsSection: 25.6.6.3[range.istream.iterator]Status:NADSubmitter: Patrick PalkaOpened: 2020-02-09Last modified: 2020-11-09
Priority:2
View all otherissues in [range.istream.iterator].
View all issues withNAD status.
Discussion:
Every instantiation ofranges::basic_istream_view::iterator has an emptyiterator_traits, i.e. the type
iterator_traits<ranges::basic_istream_view<Val, CharT, Traits>::iterator>
has no members.
This happens becausebasic_istream_view::iterator neither modelscpp17-iterator (since this concept requires copyability, which thisiterator is by design not) nor does it define all four of the membertypesdifference_type,value_type,reference, anditerator_category (it is missingreference). Therefore by 24.3.2.3[iterator.traits] p3, this iterator's specialization ofiterator_traits will be empty if generated from theiterator_traits primary template.Sincebasic_istream_view::iterator is indeed an iterator, itsiterator_traits should certainly not be empty. The simplest solutionhere is to define the member typereference in the definition ofbasic_istream_view::iterator, which will enable itsiterator_traitsspecialization to be appropriately populated from the primary template.[2020-02-10; Jonathan comments]
Jonathan and Casey have concerns about the proposed resolution. Casey: The wording makes it lookas if this iterator is supposed to be ancpp17-input-iterator.
[2020-02 Prioritized as P2 Monday morning in Prague]
Previous resolution [SUPERSEDED]:This wording is relative toN4849.
Modify 25.6.6.3[range.istream.iterator], class template
basic_istream_view::iteratorsynopsis, as indicated:namespace std::ranges { template<class Val, class CharT, class Traits> class basic_istream_view<Val, CharT, Traits>::iterator {// exposition only public: using iterator_category = input_iterator_tag; using difference_type = ptrdiff_t; using value_type = Val;using reference = Val&;iterator() = default; […] };}
[2020-02-13, Prague]
LWG decided for NAD: Theranges::basic_istream_view::iterator is a move-only type and thus cannot meet theCpp17 requirements (evenoutput_iterator_tag), as such it should not specializeiterator_traits, to avoid misleading results when it is passed to new algorithms.
iterator_category member type of this template.[2020-11-09 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
basic_syncbuf::emit() + Qt's#define emit = Big Bada-BoomSection: 31.11.2.1[syncstream.syncbuf.overview]Status:NADSubmitter: Marc MutzOpened: 2019-02-14Last modified: 2020-11-09
Priority:Not Prioritized
View all otherissues in [syncstream.syncbuf.overview].
View all issues withNAD status.
Discussion:
The current IS contains a function calledemit() (inbasic_syncbuf, added byP0053).
emit is a macro in pervasive use in everyQt program.#include'ing<osyncstream> after any Qt header would break, becauseemit was#define'd to nothing by the Qt headers.It is understood that the committee cannot check every 3rd-party library out there that chooses (badly, as I’d readily concur) to#define a macro of all-lowercase letters, but themin/max issue in the Windows headers caused so much pain for our users, that we probably should avoid a breakage here, for the benefit of our users that have to work Qt.It also doesn’t seem likeemit() is a particularly mandatory name for the syncbuf function. Since it returnsbool, it could just as easily be calledtry_emit() and the issue would be solved.Suggested approach:Inbasic_syncbuf, renamebool emit() tobool try_emit(). Inbasic_osyncstream, where the function doesn't returnbool, but sets the stream'sfailbit, renamevoid emit() tovoid emit_or_fail().[2020-02-14, Prague]
The issue was send to LEWG, who made the following poll:
We're open to renaming
osyncstream::emit()(and related).SF F N A SA1 1 5 8 20
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4849.
Modify 31.7.6.5[ostream.manip] as indicated:
template<class charT, class traits> basic_ostream<charT, traits>& flush_emit(basic_ostream<charT, traits>& os);-12-Effects: Calls
os.flush(). Then, ifos.rdbuf()is abasic_syncbuf<charT, traits, Allocator>*,calledbuffor the purpose of exposition, callsbuf->try_emit().
Modify 31.11.2.1[syncstream.syncbuf.overview] as indicated:
[…]// 31.11.2.4[syncstream.syncbuf.members], member functionsbooltry_emit();streambuf_type* get_wrapped() const noexcept;[…]-1- Class template
basic_syncbufstores character data written to it, known as the associated output, intointernal buffers allocated using the object's allocator. The associated output is transferred to the wrappedstream buffer object*wrappedwhentry_emit()is called or when thebasic_syncbufobject is destroyed. Such transfers are atomic with respect to transfers by otherbasic_syncbufobjects with the same wrapped stream buffer object.
Modify 31.11.2.2[syncstream.syncbuf.cons] as indicated:
~basic_syncbuf();-7-Effects: Calls
-8-Throws: Nothing. If an exception is thrown fromtry_emit().try_emit(), the destructor catches and ignores thatexception.
Modify 31.11.2.3[syncstream.syncbuf.assign] as indicated:
basic_syncbuf& operator=(basic_syncbuf&& rhs) noexcept;-1-Effects: Calls
try_emit()then move assigns fromrhs. After the move assignment*thishas the observable state it would have had if it had been move constructed fromrhs(31.11.2.2[syncstream.syncbuf.cons]).
Replace in 31.11.2.4[syncstream.syncbuf.members] all occurrences ofemit() bytry_emit() (five occurrences)
Replace in 31.11.2.5[syncstream.syncbuf.virtuals] all occurrences ofemit() bytry_emit() (three occurrences)
Modify 31.11.3.1[syncstream.osyncstream.overview] as indicated:
[…]// 31.11.3.3[syncstream.osyncstream.members], member functionsvoid emit_or_fail();streambuf_type* get_wrapped() const noexcept;[…]
Replace in 31.11.3.2[syncstream.osyncstream.cons] all occurrences ofemit() byemit_or_fail() (three occurrences)
Replace in [syncstream.osyncstream.assign] all occurrences ofemit() byemit_or_fail() (two occurrences)
Replace in 31.11.3.3[syncstream.osyncstream.members] all occurrences ofemit() byemit_or_fail() (six occurrences)
back_insert_iterator fails when a container is also its value typeSection: 24.5.2.2[back.insert.iterator]Status:NADSubmitter: Billy O'Neal IIIOpened: 2020-03-03Last modified: 2020-07-17
Priority:Not Prioritized
View all otherissues in [back.insert.iterator].
View all issues withNAD status.
Discussion:
Consider the following:
#include <algorithm>#include <iterator>#include <vector>struct example_container { using value_type = std::back_insert_iterator<example_container>; void push_back(const value_type&) {}};int main() { std::vector<std::back_insert_iterator<example_container>> v; example_container ex; std::copy(v.begin(), v.end(), std::back_inserter(ex));}This example is out-of-contract in the current standard because it createsback_insert_iterator<incomplete>, as per 16.4.5.8[res.on.functions]/2. However, it might be something we are considering for future iterators and proxy reference types. In practice, the "Ill-formed, no diagnostic required" the user is likely to get is an ambiguity between whatback_insert_iterator's copy assignment operator, and its "push back assigning operator". We could resolve this by changing the return type ofoperator* to a proxy in the same wayistream_iterator does, though that might be ABI breaking for some implementations.
operator* type if we intend to leave the door open to more incomplete type support in the standard library.[2020-07-17; Status changed to NAD in telecon]
We reviewed the reflector discussion and were not motivated to support this.There were concerns that adding incomplete type support elsewhere in containershas caused us regrettable problems, and we're not sure we could get this righteven if we wanted to support it.
Proposed resolution:
tuple oroptional from{aggregate-member-value}Section: 22.4.4.2[tuple.cnstr], 22.5.3.2[optional.ctor]Status:NADSubmitter: Ville VoutilainenOpened: 2020-05-01Last modified: 2020-11-09
Priority:2
View otheractive issues in [tuple.cnstr].
View all otherissues in [tuple.cnstr].
View all issues withNAD status.
Discussion:
For reference, seethis gcc bug report.
Constructing atuple oroptional from an element value of an aggregateis broken in C++20.tuple<c> t({val}); andoptional<c> t({val});invoked a non-forwarding constructor before, but now the perfect-forwarding convertingconstructors are a match, because the element is constructible from{val}. Butit's not convertible, so overload resolution chooses the explicit constructor, and theinitialization fails.Tim Song explains the overload resolution inthis reflector discussion.Now that we understand that C++17 called the non-forwarding conversion constructor,and C++20 tries to use the forwarding conversion constructor, we have the solution.SFINAE away the forwarding conversion constructor when it would convert an aggregate.This also means thattuple<c> t(0); won't work, which is unfortunatebecausetuple<c>/optional<c> no longer mirrors whatc can do.That's okay; in this LWG issue, we first restore feature parity with C++17, and later,as an extension, enable such initializations so thattuple/optionalmirrors whatc can do in C++20.The proposed wording below has been implemented and tested.[2020-05-09; Reflector prioritization]
Set priority to 2 after reflector discussions.
[2020-06-11; LWG Telecon: Status changed: New → LEWG.]
Ask LEWG if it's desirable to make({val}) work again.Tomasz would prefer it to be explicit e.g. viastd::in_place.
[2020-06-23; LEWG Telecon]
POLL: Make({val}) work again, at the risk of non-transparency of tuple constructors and further complicating the tuple and optional overload set.
SF F N A SA0 5 6 9 0
No consensus for change. Close as Not a defect.
[2020-11-09 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4861.
Modify 22.4.4.2[tuple.cnstr] as indicated:
template<class... UTypes> constexpr explicit(see below) tuple(UTypes&&... u);-11-Constraints:
sizeof...(Types)equalssizeof...(UTypes)andsizeof...(Types) ≥ 1andis_constructible_v<Ti, Ui>istruefor alliandconjunction_v<is_aggregate<remove_reference_t<Ti>>,negation<is_same<remove_reference_t<Ti>, remove_reference_t<Ui>>>>isfalsefor alli.
Modify 22.5.3.2[optional.ctor] as indicated:
template<class U = T> constexpr explicit(see below) optional(U&& v);-22-Constraints:
is_constructible_v<T, U>istrue,is_same_v<remove_cvref_t<U>, in_place_t>isfalse,andis_same_v<remove_cvref_t<U>, optional>isfalse, andconjunction_v<is_aggregate<T>, negation<is_same<T,remove_reference_t<U>>>>isfalse.
Section: 23.2.8[unord.req]Status:NADSubmitter: Marshall ClowOpened: 2020-07-23Last modified: 2020-08-21
Priority:Not Prioritized
View otheractive issues in [unord.req].
View all otherissues in [unord.req].
View all issues withNAD status.
Discussion:
In C++14, we added "transparent lookups" into the ordered associative containers. This was sold as an efficiency concern, as removing the need to create temporary objects just to compare against.
However, people found clever ways to use this. One of them, in fact, was in theoriginal paper, and was the subject of a question onStack Overflow.This all works because the elements in the ordered associative containers are, well, ordered.For C++20, we added this facility to the unordered containers.Consider the following code:#include <unordered_set>#include <string>#include <iostream>struct DumbHash // put everything in the same bucket{ using is_transparent = void; template<typename T> size_t operator()(const T&) const { return 0; }};struct CompareEQ { using is_transparent = void; bool operator()(const std::string& lhs, const std::string& rhs) const { return lhs == rhs; } bool operator()(const std::string& lhs, char rhs) const { return !lhs.empty() && (lhs[0] == rhs); } bool operator()(char lhs, const std::string& rhs) const { return !rhs.empty() && (lhs == rhs[0]); }};int main () { const char* one[] = {"a", "b", "c", "d", "e", "bb"}; const char* two[] = {"b", "e", "d", "bb", "c", "a"}; const char* thr[] = {"b", "bb", "a", "c", "d", "e"}; typedef std::unordered_set<std::string, DumbHash, CompareEQ> MS; MS m1{std::begin(one), std::end(one)}; MS m2{std::begin(two), std::end(two)}; MS m3{std::begin(thr), std::end(thr)}; for (const auto& s: m1) std::cout << s << ' '; std::cout << std::endl; for (const auto& s: m2) std::cout << s << ' '; std::cout << std::endl; for (const auto& s: m3) std::cout << s << ' '; std::cout << std::endl; std::cout << "m1:" << m1.count('b') << ' '; std::cout << "m2:" << m2.count('b') << ' '; std::cout << "m3:" << m3.count('b');}When I run this program on my Mac, I get the following output:
bb e d c b aa c bb d e be d c a bb bm1:1 m2:1 m3:2
(This is using unreleased code, but I have confirmed this with VS2019'sunordered_multiset.)
find,equal_range, andcontains.The problem is that the elements in the unordered containers are only partially ordered; i.e, all the elements that are equal (according to the non-transparent version of the comparison predicate) are adjacent in the container, but are unordered relative to the other elements in the container.My recommendation is to declare this all UB.Suggested resolution:Add a precondition to all of the transparent lookup functions for the unordered containers forbidding stuff like this. This should probably go in 23.2.8[unord.req], maybe at the end of Table [tab:container.hash.req].Precondition: The value being searched matches at most one unique key in the container.
[2020-08-21 Issue processing telecon: NAD based on reflector discussion. Status changed: New → NAD.]
Proposed resolution:
atomic_ref safety should be based on operations that "potentially conflict" rather than lifetimeSection: 32.5.7[atomics.ref.generic]Status:NADSubmitter: Billy O'Neal IIIOpened: 2020-09-12Last modified: 2024-06-28
Priority:3
View all otherissues in [atomics.ref.generic].
View all issues withNAD status.
Discussion:
Consider the following program:
#include <atomic>#include <iostream>#include <thread>using namespace std;int main() { int i{500}; atomic_ref atom{i}; i += 500; thread t1{[&atom] { for (int val{0}, x{0}; x < 70;) { if (atom.compare_exchange_weak(val, val + 10)) { ++x; }}}}; thread t2{[&atom] { for (int val{0}, y{0}; y < 29;) { if (atom.compare_exchange_weak(val, val + 1)) { ++y; }}}}; t1.join(); t2.join(); cout << i << endl; // 1729}Technically this program has undefined behavior. 32.5.7[atomics.ref.generic] p3 says that, during the lifetime of anyatomic_ref referring to an object, that the object may only be accessed through theatomic_ref instances. However, in this example theatomic_ref is constructed before thei+=500 and is not destroyed before the print, even though we have a happens-before relationship between the atomic and non-atomic 'phases' of access of the value.
#include <atomic>#include <iostream>#include <thread>using namespace std;int main() { int i{500}; i += 500; { atomic_ref atom{i}; thread t1{[&atom] { for (int val{0}, x{0}; x < 70;) { if (atom.compare_exchange_weak(val, val + 10)) { ++x; }}}}; thread t2{[&atom] { for (int val{0}, y{0}; y < 29;) { if (atom.compare_exchange_weak(val, val + 1)) { ++y; }}}}; t1.join(); t2.join(); } // destroy atom cout << i << endl; // 1729}We should probably get SG1 on record clarifying whether they intend the first program to be acceptable. I can think of a reason to foratomic_ref's ctor to do something (zeroing out padding), but in our implementation it does nothing. I can't think of any reason foratomic_ref's dtor to do anything.
[2020-09-29; Priority to P3 after reflector discussions; Status set to "SG1"]
[St. Louis 2024-06-28; SG1 confirm the intent and recommend NAD.]
[St. Louis 2024-06-28; LWG: Status changed: Open → NAD.]
Proposed resolution:
elements_view::sentinel's firstoperator- has wrong return typeSection: 25.7.23.4[range.elements.sentinel]Status:NAD EditorialSubmitter: Hewill KangOpened: 2021-05-28Last modified: 2021-06-07
Priority:Not Prioritized
View all issues withNAD Editorial status.
Discussion:
Because the iterator type of the firstoperator- isconstiterator<OtherConst>&, its return type should berange_difference_t<maybe-const<OtherConst, V>>.
[2021-06-07 Fixed by editorial issue#4603.Status changed: New → NAD Editorial.]
Proposed resolution:
This wording is relative toN4885.
Modify 25.7.23.4[range.elements.sentinel] as indicated:
[…][…] template<bool OtherConst> requires sized_sentinel_for<sentinel_t<Base>, iterator_t<maybe-const<OtherConst, V>>> friend constexpr range_difference_t<Basemaybe-const<OtherConst, V>> operator-(constiterator<OtherConst>& x, constsentinel& y); template<bool OtherConst> requires sized_sentinel_for<sentinel_t<Base>, iterator_t<maybe-const<OtherConst, V>>> friend constexpr range_difference_t<maybe-const<OtherConst, V>> operator-(constsentinel& x, constiterator<OtherConst>& y); };}template<bool OtherConst> requires sized_sentinel_for<sentinel_t<Base>, iterator_t<maybe-const<OtherConst, V>>>friend constexpr range_difference_t<Basemaybe-const<OtherConst, V>> operator-(constiterator<OtherConst>& x, constsentinel& y);-5-Effects: Equivalent to:
return x.current_ - y.end_;
nullopt_t's requirement to not beDefaultConstructibleSection: 22.5.5[optional.nullopt]Status:NADSubmitter: David FribergOpened: 2021-06-04Last modified: 2021-06-14
Priority:Not Prioritized
View all otherissues in [optional.nullopt].
View all issues withNAD status.
Discussion:
22.5.5[optional.nullopt] p2 requires thatnullopt_t shall not have a default constructor ([…] or an initializer-list constructor, and shall not be an aggregate). However, after the final resolution of LWG issue2510(i) andCWG 1518 it seems as if the following synopsis would suffice:
struct nullopt_t { explicit nullopt_t() = default; };Which would also be consistent with other tag types.
22.5.5[optional.nullopt] p2 in its current form was written prior to the final resolution of LWG issue2510(i) andCWG 1518, and is arguably based on using an earlier proposed approach for tag types which was later superseded.Details:P0032R3 was part of introducingoptional and contained a discussion around thenullopt_t type, tag types in general, and theDefaultConstructible requirement. Particularly, from section 'Not assignable from{}':To re-enforce this design, there is an pending issue 2510-Tag types should not be DefaultConstructible Core issue 2510.
At the time ofP0032R3, the resolution of LWG issue2510(i) was indeed for all tag typesto not beDefaultConstructible, but this resolution was later superseded as part of the resolution of CWG issueCWG 1518, which in turn reverted parts of the resolution of CWG issueCWG 1630 (which "went too far in allowing use of explicit constructors for default initialization").
The final resolution for CWG 1518 (P0398R0) lead to the requirement for aggregate classes to not have any explicit [user-declared] constructors, and LWG2510(i) was resolved accordingly by making all tag types have explicit user-declared (constexpr) default constructors.However, the spec ofnullopt_t never changed after these events or as part of updating other tag types, and it is still explicitly required to not beDefaultConstructible (nor have a initialization-list constructor) and to not be an aggregate, whereas the implementation of it is otherwise unspecified.We may note that we still see some compiler variance on the topic of CWG issues 1518 & 1630, see thisgodbolt link.[2021-06-14 Reflector poll:Current wording prevents an implicit conversion sequence from{}.Status changed: New → NAD.]
Proposed resolution:
This wording is relative toN4885.
Modify 22.5.2[optional.syn], header<optional> synopsis, as indicated:
[…]// 22.5.5[optional.nullopt], no-value state indicatorstruct nullopt_t{see belowexplicit nullopt_t() = default; };inline constexpr nullopt_t nullopt{}(unspecified);[…]
Modify 22.5.5[optional.nullopt] as indicated:
struct nullopt_t{see belowexplicit nullopt_t() = default; };inline constexpr nullopt_t nullopt{}(unspecified);-1- The struct
nullopt_tis an empty class type used as a unique type to indicate the state of not containing a value foroptionalobjects. In particular,optional<T>has a constructor withnullopt_tas a single argument; this indicates that an optional object not containing a value shall be constructed.-2- Typenullopt_tshall not have a default constructor or an initializer-list constructor, and shall not be an aggregate.
resize() andappend() functions across the librarySection: 27.4.3.5[string.capacity], 23.3.5.3[deque.capacity], 23.3.11.3[list.capacity], 23.3.13.3[vector.capacity], 23.3.7.5[forward.list.modifiers], 29.6.2.8[valarray.members], 27.4.3.7.2[string.append], 31.12.6.5.3[fs.path.append]Status:NADSubmitter: Louis DionneOpened: 2021-08-11Last modified: 2022-08-23
Priority:3
View all otherissues in [string.capacity].
View all issues withNAD status.
Discussion:
This issue requests to clarify the complexity requirements forresize andappend member functions across the library. Currently, none of them have complexity requirements associated to them, which means that implementations are free to use a geometric growth approach or not. A geometric growth approach (like what's required bypush_back) implies that callingresize/append with successively larger sizes will have amortized𝒪(N) complexity, whereas using aresize-exactly approach makes that pattern𝒪(N2).
push_back, or explicitly mention that implementations are allowed to use whatever growth strategy they want. If we do the former, users could start relying on this guarantee in a portable manner. If we do the latter, it would make it clear to users that they should not rely on the amortized𝒪(N) guarantee if they want their code to be portable.The following classes have aresize() member function and also apush_back() member function:27.4.3.5[string.capacity]
23.3.5.3[deque.capacity]
23.3.11.3[list.capacity]
23.3.13.3[vector.capacity]
The following classes have aresize() member function but do not supportpush_back():
23.3.7.5[forward.list.modifiers]
29.6.2.8[valarray.members]
The following classes have anappend() member function:
27.4.3.7.2[string.append]
31.12.6.5.3[fs.path.append]
None of them specify a complexity requirement. I think we should update all of them to describe what is expected or permitted in an implementation.
[2021-08-20; Reflector poll]
Set priority to 3 and status to "LEWG" after reflector poll.
[2022-02-22 LEWG telecon; Status changed: LEWG → Tentatively NAD.]
A paper would be needed.Such a paper would need to include discussion on whetherallocate_at_least (new for C++23) has an impact.
[2022-08-23 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
unique_ptrSection: 20.3.1.3.1[unique.ptr.single.general]Status:NADSubmitter: Johel Ernesto Guerrero PeñaOpened: 2021-09-07Last modified: 2021-09-20
Priority:Not Prioritized
View all otherissues in [unique.ptr.single.general].
View all issues withNAD status.
Discussion:
This originated from the editorial issues#4871 and#4872.
Several member functions ofunique_ptr arenoexcept, and yet, they have the precondition that an expression involving the deleter does not exit via an exception. There's nothing an implementation or user can take advantage of in presence of this UB. Since the behavior otherwise would be a call tostd::terminate, these preconditions should be striked out.Note that although~unique_ptr() is notnoexcept, 16.4.6.14[res.on.exception.handling] p3 specifies it to behave as if it were.[2021-09-20 Status changed: New → NAD.]
The current specification allows the compiler to omit noexcept-enforcement.
Proposed resolution:
This wording is relative toN4892.
Modify 20.3.1.3.2[unique.ptr.single.ctor] as indicated:
constexpr unique_ptr() noexcept;constexpr unique_ptr(nullptr_t) noexcept;-1- […]
-2-Preconditions:Dmeets theCpp17DefaultConstructible requirements (Table 27), and that construction does not throw an exception.[…]explicit unique_ptr(pointer p) noexcept;-5-Constraints: […]
-6-Mandates: […]-7-Preconditions:Dmeets theCpp17DefaultConstructible requirements (Table 27), and that construction does not throw an exception.[…]unique_ptr(pointer p, const D& d) noexcept;unique_ptr(pointer p, remove_reference_t<D>&& d) noexcept;-10-Constraints: […]
-11-Mandates: […]-12-Preconditions: For the first constructor, ifDis not a reference type,Dmeets theCpp17CopyConstructible requirementsand such construction does not exit via an exception. For the second constructor, ifDis not a reference type,Dmeets theCpp17MoveConstructible requirementsand such construction does not exit via an exception.[…]unique_ptr(unique_ptr&& u) noexcept;-17-Constraints: […]
-18-Preconditions: IfDis not a reference type,Dmeets theCpp17MoveConstructible requirements (Table 28).Construction of the deleter from an rvalue of type[…]Ddoes not throw an exception.template<class U, class E> unique_ptr(unique_ptr<U, E>&& u) noexcept;-21-Constraints: […]
-22-Preconditions: IfEis not a reference type, construction of the deleter from an rvalue of typeEis well-formedand does not throw an exception. Otherwise,Eis a reference type and construction of the deleter from an lvalue of typeEis well-formedand does not throw an exception.[…]
Modify 20.3.1.3.3[unique.ptr.single.dtor] as indicated:
~unique_ptr();-1-Preconditions: The expression
[…]get_deleter()(get())is well-formed,and has well-defined behavior, and does not throw exceptions.
Modify 20.3.1.3.4[unique.ptr.single.asgn] as indicated:
unique_ptr& operator=(unique_ptr&& u) noexcept;-1-Constraints: […]
-2-Preconditions: IfDis not a reference type,Dmeets theCpp17MoveAssignable requirements (Table 30)and assignment of the deleter from an rvalue of type. Otherwise,Ddoes not throw an exceptionDis areference type;remove_reference_t<D>meets theCpp17CopyAssignable requirementsand assignment of the deleter from an lvalue of type.[…]Ddoes not throw an exceptiontemplate<class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u) noexcept;-6-Constraints: […]
-7-Preconditions: IfEis not a reference type, assignment of the deleter from an rvalue of typeEis well-formedand does not throw an exception. Otherwise,Eis a reference type and assignment of the deleter from an lvalue of typeEis well-formedand does not throw an exception.[…]
Modify 20.3.1.3.6[unique.ptr.single.modifiers] as indicated:
void reset(pointer p = pointer()) noexcept;-3-Preconditions: The expression
[…]get_deleter()(get())is well-formed,and has well-defined behavior, and does not throw exceptions.void swap(unique_ptr& u) noexcept;-6-Preconditions:
[…]get_deleter()is swappable (16.4.4.3[swappable.requirements])and does not throw an exception under.swap
ranges::starts_with andranges::ends_with are underspecifiedSection: 26.6.16[alg.starts.with], 26.6.17[alg.ends.with]Status:NADSubmitter: Michael Schellenberger CostaOpened: 2021-09-17Last modified: 2021-09-24
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
When implementing C++23 newranges::starts_with andranges::ends_withfor MSVC we came around some issues regarding infinite ranges.
ends_with, if the second range is infinite. Similarly, there is no meaningful answer tostarts_with if both ranges are infinite.We should constraint both algorithms to forbid those corner cases (preferred resolution), or explicitly specify a given return value for those (The reasonable choice would be "return false;")[2021-09-24 infinite ranges are invalid by [iterator.requirements.general] p10, so undefined by p12. Might be nice to relax this in future, but needs a paper. Status changed: New → NAD.]
Proposed resolution:
compare_exchange be allowed to modify theexpected value on success?Section: 32.5.8.2[atomics.types.operations]Status:NADSubmitter: Jonathan WakelyOpened: 2021-09-29Last modified: 2022-08-23
Priority:2
View otheractive issues in [atomics.types.operations].
View all otherissues in [atomics.types.operations].
View all issues withNAD status.
Discussion:
Currently acompare_exchange will only update theexpected parameter if thecompare_exchange fails. This precludes unconditionally clearing the padding bits of theexpected object prior to doing thecompare_exchange, which complicates theimplementation by requiring additional work (e.g. making a copy of theexpected valueand clearing the copy's padding, then copying it back to expected only if thecompare_exchange fails).
expected in the success case,if such modifications only affect padding bits (i.e. do not alter the value). If we want to allow it,we need to say so explicitly. The current wording does not permit modifications in the success case,and any such modification could create a data race if another thread is reading the same memory location(if it knows a priori that acompare_exchange_strong would succeed and so not write to that location).[2021-10-14; Reflector poll]
Set priority to 2 after reflector poll. Send to SG1.
This is2426(i) again,but the new requirement to clear padding bits changes things.
[2022-07-06; Move to "Open" following SG1 feedback]
Allow compare_exchange to modify the expected value on success?
| SF | F | N | A | SA |
| 0 | 0 | 0 | 5 | 4 |
[2022-07-14; Move to "Tentatively NAD" following reflector poll]
[2022-08-23 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
__cpp_lib_deduction_guides to feature test macrosSection: 17.3.2[version.syn]Status:NADSubmitter: Konstantin VarlamovOpened: 2021-11-09Last modified: 2024-06-24
Priority:3
View otheractive issues in [version.syn].
View all otherissues in [version.syn].
View all issues withNAD status.
Discussion:
P0433R2, the proposal for adding deduction guides to the standard library, contained a recommendation to use__cpp_lib_deduction_guides as a feature test macro. However, it appears that this feature test macro has been accidentally omitted from the Standard when the paper was applied and probably needs to be added back.
Previous resolution [SUPERSEDED]:
This wording is relative toN4901.
Modify 17.3.2[version.syn] as indicated:
[…]#define __cpp_lib_coroutine 201902L// also in <coroutine>#define __cpp_lib_deduction_guides 201703L// also in <deque>, <forward_list>, <list>, <map>, <queue>, <set>, <stack>, // <unordered_map>, <unordered_set>, <vector>#define __cpp_lib_destroying_delete 201806L// also in <new>[…]
[2021-11-16; Konstantin Varlamov comments and improves wording]
One potential topic of discussion is whether the new feature test macro needs to be defined in every library header that contains an explicit deduction guide. While this would be consistent with the current approach, no other macro is associated with such a large set of headers (20 headers in total, whereas the current record-holder is__cpp_lib_nonmember_container_access with 12 headers). For this reason, it should be considered whether perhaps the new macro should only be defined in<version> (which would, however, make it an outlier). The proposed wording currently contains an exhaustive list (note that the deduction guides for<mutex> were removed by LWG2981(i)).
[2022-01-30; Reflector poll]
Set priority to 3 after reflector poll.Several votes for NAD as it's too late to be useful, and code which needsto be portable to pre-CTAD compilers can just not use CTAD.
[2023-04-21; Reflector poll for 'Tentatively NAD']
"We keep changing the deduction guides, and different libraries might beconformant in some headers and not others. The status cannot be representedby a single number."
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4901.
Modify 17.3.2[version.syn] as indicated:
[…]#define __cpp_lib_coroutine 201902L// also in <coroutine>#define __cpp_lib_deduction_guides 201703L// also in <array>, <deque>, <forward_list>, <functional>, <list>, <map>, // <memory>, <optional>, <queue>, <regex>, <scoped_allocator>, <set>, <stack>, // <string>, <tuple>, <unordered_map>, <unordered_set>, <utility>, <valarray>, // <vector>#define __cpp_lib_destroying_delete 201806L// also in <new>[…]
longjmp?Section: 17.14.3[csetjmp.syn]Status:NADSubmitter: Jiang AnOpened: 2021-12-15Last modified: 2022-01-30
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
IMO the UB in 17.14.3[csetjmp.syn]/2 is because of the design that "every destructor call for an object shall be in effect when the lifetime of that object ends". A similar requirement is in 6.8.4[basic.life]/5, but it's more relaxed than the requirement forsetjmp/longjmp.It seems better to harmonize the requirements in 6.8.4[basic.life]/5 and 17.14.3[csetjmp.syn]/2, which allowslongjmp to skip non-trivial but no-op destructor calls. Given that Microsoft UCRT'slongjmp can sometimes (but not always) call destructors, IMO we should say that it's unspecified whetherlongjmp calls destructor for any object whose lifetime ends.
[2022-01-30Duplicate ofCWG 2361.Status changed: New → NAD.]
Proposed resolution:
This wording is relative toN4901.
Modify 17.14.3[csetjmp.syn] as indicated:
-2- The function signature
longjmp(jmp_buf jbuf, int val)has more restricted behavior in this document.AIf replacing thesetjmp/longjmpcall pair has undefined behavior isetjmpandlongjmpin asetjmp/longjmpcall pair bycatchandthrowwould invoke anynon-trivialdestructors for any objects with automatic storage duration, it is unspecified whether the destructor is invoked for each such object. The behavior is undefined if the program depends on the side effects produced by any such unspecified destructor calls. A call tosetjmporlongjmphas undefined behavior if invoked in a suspension context of a coroutine (7.6.2.4[expr.await]).
std::cout << &X::f prints1Section: 31.7.6.3[ostream.formatted]Status:NADSubmitter: Peter DimovOpened: 2022-01-31Last modified: 2022-08-23
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
At present, the program
#include <iostream>struct X{ void f() {}};int main(){ std::cout << &X::f;}prints1. That's because member pointers implicitly converttobool, and there'soperator<< overload forbool in31.7.6.3.2[ostream.inserters.arithmetic].
L"str" is output tostd::cout,which used to print the pointer value using theoperator<<overload forconst void*.We should similarly consider adding a deleted overload for member pointers.[2022-03-04; Reflector poll; Status changed: New → Tentatively NAD]
Needs a paper to LEWG if anything should change here.
[2022-08-23 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4901.
Modify 31.7.6.2.1[ostream.general], class templatebasic_ostream synopsis, as indicated:
namespace std { […] template<class traits> basic_ostream<wchar_t, traits>& operator<<(basic_ostream<wchar_t, traits>&, const char16_t*) = delete; template<class traits> basic_ostream<wchar_t, traits>& operator<<(basic_ostream<wchar_t, traits>&, const char32_t*) = delete;template<class charT, class traits, class T, class C> basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>&, T C::*) = delete;}Section: 27.1[strings.general]Status:NADSubmitter: Jiang AnOpened: 2022-05-07Last modified: 2022-08-23
Priority:4
View all otherissues in [strings.general].
View all issues withNAD status.
Discussion:
Currently char-like types are defined as non-array trivial and standard-layout types (27.1[strings.general]). However, as far as I know, there is no actual operation specified in the standard or used in implementations requiring a char-like type to be standard-layout (unlike the triviality, which is related tocharT(), etc.). Implementations are merelystatic_assert-ing the standard-layout property of element types.
std::atomic<T*>), I think char-like types should just be non-array trivial types.[2022-05-17; Reflector poll]
Set priority to 4 after reflector poll. Six votes for NAD.Changing this would require a proposal through LEWG.
[2022-08-23 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
explicitSection: 25.7.26.2[range.zip.transform.view], 25.7.28.2[range.adjacent.transform.view], 25.7.29.2[range.chunk.view.input], 25.7.29.6[range.chunk.view.fwd], 25.7.30.2[range.slide.view], 25.7.31.2[range.chunk.by.view]Status:NADSubmitter: Hewill KangOpened: 2022-06-10Last modified: 2024-06-24
Priority:4
View all issues withNAD status.
Discussion:
All C++20 range adaptors' non-single-argument constructors are not declared asexplicit, which makes the following initialization well-formed:
std::vector v{42};std::ranges::take_view r1 = {v, 1};std::ranges::filter_view r2 = {v, [](int) { return true; }};However, the non-single-argument constructors of C++23 range adaptors, except forjoin_with_view, are allexplicit, which makes us no longer able to
std::ranges::chunk_view r1 = {v, 1}; //ill-formedstd::ranges::chunk_by_view r2 = {v, [](int, int) { return true; }}; //ill-formedThis seems unnecessary since I don't see the observable benefit of preventing this. In the standard, non-single-argument constructors are rarely specified asexplicit unless it is really undesirable, I think the above initialization is what the user expects since it's clearly intentional, and I don't see any good reason to reject it from C++23.
[2022-06-11; Daniel comments]
Another possible candidate could be 25.7.11.3[range.take.while.sentinel]'s
constexpr explicitsentinel(sentinel_t<Base> end, const Pred* pred);
[2022-06-21; Reflector poll]
Set priority to 4 after reflector poll. Send to LEWG.
[2023-01-24; LEWG in Kona]
Use alternative approach inP2711 instead.
[2024-06-24 Status changed: Tentatively NAD → NAD.]
P2711R1 was approved in February 2023, confirming thatthese constructors should be explicit.
Proposed resolution:
This wording is relative toN4910.
Modify 25.7.26.2[range.zip.transform.view] as indicated:
namespace std::ranges { template<copy_constructible F, input_range... Views> requires (view<Views> && ...) && (sizeof...(Views) > 0) && is_object_v<F> && regular_invocable<F&, range_reference_t<Views>...> &&can-reference<invoke_result_t<F&, range_reference_t<Views>...>> class zip_transform_view : public view_interface<zip_transform_view<F, Views...>> {copyable-box<F>fun_;// exposition only zip_view<Views...>zip_;// exposition only […] public: zip_transform_view() = default; constexprexplicitzip_transform_view(F fun, Views... views); […] }; […]}constexprexplicitzip_transform_view(F fun, Views... views);-1-Effects: Initializes
fun_withstd::move(fun)andzip_withstd::move(views)....
Modify 25.7.28.2[range.adjacent.transform.view] as indicated:
namespace std::ranges { template<forward_range V, copy_constructible F, size_t N> requires view<V> && (N > 0) && is_object_v<F> && regular_invocable<F&,REPEAT(range_reference_t<V>, N)...> &&can-reference<invoke_result_t<F&,REPEAT(range_reference_t<V>, N)...>> class adjacent_transform_view : public view_interface<adjacent_transform_view<V, F, N>> {copyable-box<F>fun_;// exposition only adjacent_view<V, N>inner_;// exposition only […] public: adjacent_transform_view() = default; constexprexplicitadjacent_transform_view(V base, F fun); […] }; […]}constexprexplicitadjacent_transform_view(V base, F fun);-1-Effects: Initializes
fun_withstd::move(fun)andinner_withstd::move(base).
Modify 25.7.29.2[range.chunk.view.input] as indicated:
namespace std::ranges { […] template<view V> requires input_range<V> class chunk_view : public view_interface<chunk_view<V>> { Vbase_ = V();// exposition only range_difference_t<V>n_ = 0;// exposition only […] public: chunk_view() requires default_initializable<V> = default; constexprexplicitchunk_view(V base, range_difference_t<V> n); […] }; […]}constexprexplicitchunk_view(V base, range_difference_t<V> n);-1-Preconditions:
-2-Effects: Initializesn > 0istrue.base_withstd::move(base)andn_withn.
Modify 25.7.29.6[range.chunk.view.fwd] as indicated:
namespace std::ranges { template<view V> requires forward_range<V> class chunk_view<V> : public view_interface<chunk_view<V>> { Vbase_ = V();// exposition only range_difference_t<V>n_ = 0;// exposition only […] public: chunk_view() requires default_initializable<V> = default; constexprexplicitchunk_view(V base, range_difference_t<V> n); […] };}constexprexplicitchunk_view(V base, range_difference_t<V> n);-1-Preconditions:
-2-Effects: Initializesn > 0istrue.base_withstd::move(base)andn_withn.
Modify 25.7.30.2[range.slide.view] as indicated:
namespace std::ranges { […] template<forward_range V> requires view<V> class slide_view : public view_interface<slide_view<V>> { Vbase_ = V();// exposition only range_difference_t<V>n_ = 0;// exposition only […] public: slide_view() requires default_initializable<V> = default; constexprexplicitslide_view(V base, range_difference_t<V> n); […] }; […]}constexprexplicitslide_view(V base, range_difference_t<V> n);-1-Effects: Initializes
base_withstd::move(base)andn_withn.
Modify 25.7.31.2[range.chunk.by.view] as indicated:
namespace std::ranges { template<forward_range V, indirect_binary_predicate<iterator_t<V>, iterator_t<V>> Pred> requires view<V> && is_object_v<Pred> class chunk_by_view : public view_interface<chunk_by_view<V, Pred>> { Vbase_ = V();// exposition onlycopyable-box<Pred>pred_ = Pred();// exposition only […] public: chunk_by_view() requires default_initializable<V> && default_initializable<Pred> = default; constexprexplicitchunk_by_view(V base, Pred pred); […] }; […]}constexprexplicitchunk_by_view(V base, Pred pred);-1-Effects: Initializes
base_withstd::move(base)andpred_withstd::move(pred).
reverse_iterator::operator-> is underconstrained for non-pointer iteratorsSection: 24.5.1.6[reverse.iter.elem]Status:NADSubmitter: Hewill KangOpened: 2022-06-27Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [reverse.iter.elem].
View all issues withNAD status.
Discussion:
For non-pointer types,reverse_iterator::operator-> only requires the expressioni.operator->() to be well-formed.
pointer, this will cause a hard error in the function body when the return type ofi.operator->() cannot be converted topointer.We should add a return type constraint for this.[2022-08-23; Reflector poll: NAD]
pointer isiterator_traits<Iterator>::pointer,which is required to namedecltype(i.operator->())(24.3.2.3[iterator.traits]/1)so the postulated problem simply does not arise in valid code.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 24.5.1.6[reverse.iter.elem] as indicated:
constexpr pointer operator->() const requires (is_pointer_v<Iterator> || requires(const Iterator i) {{ i.operator->()} -> convertible_to<pointer>; });-2-Effects:
(2.1) — If
Iteratoris a pointer type, equivalent to:return prev(current);(2.2) — Otherwise, equivalent to:
return prev(current).operator->();
reverse_iterator/common_iterator'soperator-> should not require the underlying iterator'soperator-> to be aconst member functionSection: 24.5.1.6[reverse.iter.elem], 24.5.5.4[common.iter.access]Status:NADSubmitter: Hewill KangOpened: 2022-06-27Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [reverse.iter.elem].
View all issues withNAD status.
Discussion:
For non-pointer types,reverse_iterator::operator-> requires that theIterator must have anoperator->() withconst-qualifier, whereas in theEffects clause, it always invokes the non-const object'soperator->().
common_iterator::operator-> also requires thatI::operator->() must beconst-qualified, which seems reasonable since the return type ofget<I>(v_) isconst I&. However, LWG3672(i) makescommon_iterator::operator->() always return a value, which makes it unnecessary to detect the constness ofI::operator->(), because it will be invoked with a non-const returned object anyway.I think we should remove this constraint as I don't see the benefit of doing that.Constraining iterator'soperator->() to beconst and finally invoking non-const overload doesn't feel right to me either. In<ranges>, the exposition-only constrainthas-arrow (25.5.2[range.utility.helpers]) foroperator->() does not require that the underlying iterator'soperator->() to beconst, we should make them consistent, and I believe this relaxation of constraints can bring some value.Daniel:This issue's second part of the resolution actually depends on3672(i) being applied. Butnote that the reference wording below is stillN4910.[2022-08-23; Reflector poll: NAD]
Implicit variations apply to thoserequires-expressions,so calling as non-const (and rvalue) is fine.The PR actually loses that property and makes those overloads truly underconstrained.Motivation for relaxing it is vague.As for consistency, we should fix has-arrow instead.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 24.5.1.6[reverse.iter.elem] as indicated:
constexpr pointer operator->() const requires (is_pointer_v<Iterator> || requires(constIterator i) { i.operator->(); });-2-Effects:
(2.1) — If
Iteratoris a pointer type, equivalent to:return prev(current);(2.2) — Otherwise, equivalent to:
return prev(current).operator->();
Modify 24.5.5.4[common.iter.access] as indicated:
constexpr decltype(auto) operator->() const requiressee below;-3- The expression in therequires-clause is equivalent to:
indirectly_readable<const I> && (requires(constI&i) { i.operator->(); } || is_reference_v<iter_reference_t<I>> || constructible_from<iter_value_t<I>, iter_reference_t<I>>)-4-Preconditions:
-5-Effects:holds_alternative<I>(v_)istrue.
(5.1) — If
Iis a pointer type or ifthe expressionget<I>(v_).operator->()is well-formedrequires(I i) { i.operator->(); }istrue, equivalent to:return get<I>(v_);(5.2) — Otherwise, if
iter_reference_t<I>is a reference type, equivalent to:auto&& tmp = *get<I>(v_); return addressof(tmp);(5.3) — Otherwise, equivalent to:
returnproxy(*get<I>(v_));whereproxyis the exposition-only class:classproxy { iter_value_t<I> keep_; constexprproxy(iter_reference_t<I>&& x) : keep_(std::move(x)) {} public: constexpr const iter_value_t<I>* operator->() const noexcept { return addressof(keep_); } };[…]
views::adjacent<0> should be prohibitedSection: 25.7.27.1[range.adjacent.overview], 25.7.28.1[range.adjacent.transform.overview]Status:NADSubmitter: Hewill KangOpened: 2022-07-13Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [range.adjacent.overview].
View all issues withNAD status.
Discussion:
views::adjacent is very similar toviews::slide, except that the window sizeN is given at compile time.
N is0 does not make sense forslide_view, LWG3711(i) and LWG3712(i) added preconditions to the constructor and removed the default constructor, respectively.But forviews::adjacent, we can still specifyN to be0. According to the description of 25.7.27.1[range.adjacent.overview], it will returnviews::empty<tuple<>> as in the case ofviews::zip applied to an empty pack. And forviews::adjacent_transform<0>(E, F), it will returnviews::zip_transform(F) and eventually returnempty_view for some type.This doesn't seem reasonable to me. The reason whyviews::zip can returnviews::empty<tuple<>> is that the parameter pack can indeed be empty, so this still makes some sense. However, there is no meaningful sense for the word "adjacent" whenN is0.I don't see any observable value in allowingviews::adjacent<0>, we should disable it for consistency withviews::slide.[2022-08-23; Reflector poll: NAD]
views::zip() is exactly as meaningful asviews::adjacent<0>(E) - it's just the edge case.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 25.7.27.1[range.adjacent.overview] as indicated:
-2- The name
views::adjacent<N>denotes a range adaptor object (25.7.2[range.adaptor.object]). Given a subexpressionEand a constant expressionN, the expressionviews::adjacent<N>(E)is expression-equivalent to:
(2.1) —
I((void)E, auto(views::empty<tuple<>>))ifNis equal to0,views::adjacent<N>(E)is ill-formed.(2.2) —O
otherwise,adjacent_view<views::all_t<decltype((E))>, N>(E).
Modify 25.7.28.1[range.adjacent.transform.overview] as indicated:
-2- The name
views::adjacent_transform<N>denotes a range adaptor object (25.7.2[range.adaptor.object]). Given subexpressionsEandFand a constantexpressionN:
(2.1) — If
Nis equal to0,views::adjacent_transform<N>(E, F)isill-formedexpression-equivalent to.((void)E, views::zip_transform(F)), except that the evaluations ofEandFare indeterminately sequenced(2.2) — Otherwise, the expression
views::adjacent_transform<N>(E, F)is expression-equivalent toadjacent_transform_view<views::all_t<decltype((E))>, decay_t<decltype((F))>, N>(E, F).
chunk_view::size should preserve the signedness of the size of the underlying rangeSection: 25.7.29.2[range.chunk.view.input], 25.7.29.6[range.chunk.view.fwd]Status:NADSubmitter: Hewill KangOpened: 2022-07-15Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [range.chunk.view.input].
View all issues withNAD status.
Discussion:
Currently, theEffects ofchunk_view::size simply returnsto-unsigned-like(div-ceil(ranges::distance(base_),n_)), wherediv-ceil is defined in 25.7.29.2[range.chunk.view.input] as:
template<class I>constexpr Idiv-ceil(I num, I denom) { //exposition only I r = num / denom; if (num % denom) ++r; return r;}There are two problems here. First, for the const version ofchunk_view::size, the types ofranges::distance(base_) andn_ arerange_difference_t<const V> andrange_difference_t<V> respectively, and the two parameters ofdiv-ceil have the same typeI.Given that the standard does not guarantee thatV andconst V must have the samedifference_type, this makes thediv-ceil's template deduction fail when the two are different.
ranges::size must return an unsigned type, but here we useto-unsigned-like to unconditionally convert the return type ofchunk_view::size to an unsigned type,which is inconsistent with the behavior of other range adaptors such astake_view anddrop_view.We should try to preserve the characteristics of therange_size_t of the underlying range as much as possible.[2022-08-23; Reflector poll: NAD (would need a paper for LEWG)]
The "range_difference_t<const V> and range_difference_t<V> can be both valid but have different types" part is something I expect Mr. Carter's eventual paper to outlaw. The "preserve signedness" part is LEWG.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 25.7.29.2[range.chunk.view.input] as indicated:
constexpr auto size() requires sized_range<V>;constexpr auto size() const requires sized_range<const V>;-5-Effects: Equivalent to:
returnto-unsigned-like(div-ceil(ranges::sizedistance(base_),static_cast<decltype(ranges::size(base_))>(n_));
Modify 25.7.29.6[range.chunk.view.fwd] as indicated:
constexpr auto size() requires sized_range<V>;constexpr auto size() const requires sized_range<const V>;-3-Effects: Equivalent to:
returnto-unsigned-like(div-ceil(ranges::sizedistance(base_),static_cast<decltype(ranges::size(base_))>(n_));
slide_view::size should preserve the signedness of underlying range's sizeSection: 25.7.30.2[range.slide.view]Status:NADSubmitter: Hewill KangOpened: 2022-07-15Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [range.slide.view].
View all issues withNAD status.
Discussion:
Currently,slide_view::size const has the followingEffects:
auto sz = ranges::distance(base_) -n_ + 1;if (sz > 0) sz = 0;returnto-unsigned-like(sz);
There are two problems worth noting here. First, as described in LWG3739(i),ranges::distance(base_) andn_ may have different types, which makes the actual type ofsz not deterministic.Also, the return type is unconditionally converted to an unsigned type, even though the underlying range may have a signed size type.
V has the samedifference_type asconst V, there may still be integer promotion issues mentioned by LWG3730(i)since we add an integer1 at the end here.I think convertingsz to the size type of the underlying range before returning is the appropriate thing to do.
[2022-08-23; Reflector poll: NAD]
Paper author: "I did consider promotion and decided not to care. The code compiles and conforms to all ranges requirements, and that seems entirely sufficient to me." "Even if we don't outlaw those being different types entirely, people playing those games will still get exactly one unsigned-integer-like type back. It's totally deterministic."
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 25.7.30.2[range.slide.view] as indicated:
constexpr auto size() requires sized_range<V>;constexpr auto size() const requires sized_range<const V>;-8-Effects: Equivalent to:
auto sz = ranges::distance(base_) -n_ + 1;if (sz < 0) sz = 0;returnstatic_cast<decltype(ranges::size(base_))>to-unsigned-like(sz);
std::chrono::abs(duration) is ill-formed with non-reduced periodsSection: 30.5.10[time.duration.alg]Status:NADSubmitter: Charlie BartoOpened: 2022-07-16Last modified: 2022-11-30
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Currently 30.5.10[time.duration.alg] specifiesabs(duration) as:
Returns: if
d >= d.zero(), returnd, otherwise return-d.
Because unary minus on durations is defined to returncommon_type_t<duration>(-rep_), andcommon_type_t for durations is specified to reduce the period, this is ill-formed with durations such asduration<int, ratio<1000, 1000>>, or any other type where the numerator and denominator of the period are not coprime.
[2022-08-23; Reflector poll: NAD]
Not ill-formed, implementation should do a conversion.Changing it to return the reduced duration as an improvement would be for LEWG.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4910.
Modify 30.2[time.syn], header<chrono> synopsis, as indicated:
[…]// 30.5.10[time.duration.alg], specialized algorithmstemplate<class Rep, class Period> constexprcommon_type_t<duration<Rep, Period>> abs(duration<Rep, Period> d);[…]
Modify 30.5.10[time.duration.alg] as indicated:
[Drafting note: This will cause
This is not a breaking change, because code that was usingabsto reduce the period before returning it, much like the other arithmetic operators.abswith a non-reduced period before did not compile.]
template<class Rep, class Period> constexprcommon_type_t<duration<Rep, Period>> abs(duration<Rep, Period> d);-1-Constraints:
-2-Returns: Ifnumeric_limits<Rep>::is_signedistrue.d >= d.zero(), return+d, otherwise return-d.
string::substr forward the allocator to the newly created string?Section: 27.4.3.8.3[string.substr]Status:NADSubmitter: Igor ZhukovOpened: 2022-08-10Last modified: 2022-11-30
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Adrian Vogelsgesang noticed that libcxx'sstring::substrforward the allocator to the newly created string.
[2022-08-24; Reflector poll]
Set status to Tentatively NAD after reflector poll.
"If you want to provide a different allocator, you can use the substring constructor."
"This matches the constructor, whose choice of allocator has been already considered in2402(i). Any changes here need a paper."
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
possibly-const-range is overconstrainedSection: 25.2[ranges.syn]Status:NADSubmitter: Hewill KangOpened: 2022-09-08Last modified: 2022-11-30
Priority:Not Prioritized
View otheractive issues in [ranges.syn].
View all otherissues in [ranges.syn].
View all issues withNAD status.
Discussion:
Due to thepossibly-const-range constraint that the template parameterR must modelinput_range, this makes theranges::cend that tries using it for meaningfulconst casting never be applied to anoutput_range, even thoughconst_sentinel does not require the template parameterS to modelinput_iterator.
[2022-09-23; Reflector poll]
Tentatively NAD. "const output ranges don’t seem to be useful."
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4917.
Modify 25.2[ranges.syn] as indicated:
#include <compare> //see 17.12.1[compare.syn]#include <initializer_list> //see 17.11.2[initializer.list.syn]#include <iterator> //see 24.2[iterator.synopsis]namespace std::ranges { […] //25.7.22[range.as.const], as const view template<input_range R> constexpr auto&possibly-const-range(R& r) { //exposition only if constexpr (constant_range<const R> && !constant_range<R>) { return const_cast<const R&>(r); } else { return r; } } […]}
Section: 28.5.6.1[formatter.requirements]Status:NADSubmitter: Mark de WeverOpened: 2022-08-28Last modified: 2023-06-16
Priority:3
View all otherissues in [formatter.requirements].
View all issues withNAD status.
Discussion:
A format string 28.5.2.1[format.string.general]/1 has an optionalformat-specifier replacement field. If this field is not present, thecurrent wording makes it clear the intention is to call parse when aformatting argument use a handle class 28.5.8.1[format.arg]/19
Effects: Initializes
ptr_withaddressof(val)andformat_with[](basic_format_parse_context<char_type>& parse_ctx, Context& format_ctx, const void* ptr) { typename Context::template formatter_type<TD> f; parse_ctx.advance_to(f.parse(parse_ctx)); format_ctx.advance_to(f.format(*const_cast<TQ*>(static_cast<const TD*>(ptr)), format_ctx)); }
For other types it is implied by [tab:formatter.basic]
Formats
uaccording to the specifiers stored in*this, writes theoutput tofc.out(), and returns an iterator past the end of the outputrange. The output shall only depend onu,fc.locale(),fc.arg(n)forany valuenof typesize_t, and the range[pc.begin(), pc.end())fromthe last call tof.parse(pc).
(Similar wording is used in [tab:formatter])
Before theparse function is called it is known whether or not aformat-spec is present. It seems wasteful to call a function that isknown not to parse anything. Therefore I propose to make the calloptional.This change is only observable for formatter specializations using thehandle class, for the formatter specializations in28.5.6.4[format.formatter.spec] the change has no observable effect.[2022-10-12; Reflector poll]
Set status to "LEWG" and priority to 3 after reflector poll.
Several votes for NAD as this would be a design change requiring a paper.Dissenting opinions: "Different handling of empty and default specs is entirelyincidental and not a design feature. Moreover, built-in formatters treat thesecases identically so it's a good idea to make this explicit.""Don't need a full paper to clarify the meaning of"don't call memberparse if there's no format spec".If LEWG agree the direction PR can be polished."
[Issaquah 2023-02-07; LWG]
Will be resolved differently byP2733.
[Varna 2023-06-16; Status changed: LEWG → NAD.]
Resolved differently by LWG3892(i).
Proposed resolution:
This wording is relative toN4917.
Modify 28.5.6.1[formatter.requirements] as indicated:
-3- Given character type
[…]charT, output iterator typeOut, and formatting argument typeT, in Table 74 and Table 75:pc.begin()points to the beginning of theformat-spec (28.5.2[format.string]) of the replacement field being formatted in the format string. Ifformat-spec isnot present or empty then eitherpc.begin() == pc.end()or*pc.begin() == '}'.
ModifyBasicFormatter requirements [tab:formatter.basic] as indicated:
Table 74:BasicFormatter requirements [tab:formatter.basic] Expression Return type Requirement …f.format(u, fc)FC::iteratorFormats uaccording to the specifiers stored in*this, writes the output tofc.out(), and returns
an iterator past the end of the output range.
The output shall only depend onu,fc.locale(),fc.arg(n)for any valuenof typesize_t, and
the range[pc.begin(), pc.end())from the last
call tof.parse(pc).When theformat-spec
(28.5.2[format.string]) is not present or empty
the call tof.parse(pc)is omitted.
ModifyFormatter requirements [tab:formatter] as indicated:
Table 75:Formatter requirements [tab:formatter] Expression Return type Requirement f.format(t, fc)FC::iteratorFormats taccording to the specifiers stored in*this, writes the output tofc.out(), and returns
an iterator past the end of the output range.
The output shall only depend ont,fc.locale(),fc.arg(n)for any valuenof typesize_t, and
the range[pc.begin(), pc.end())from the last
call tof.parse(pc).When theformat-spec
(28.5.2[format.string]) is not present or empty
the call tof.parse(pc)is omitted.…
Modify 28.5.8.1[format.arg] as indicated:
[…]
-16- The classhandleallows formatting an object of a user-defined type.namespace std { template<class Context> class basic_format_arg<Context>::handle { const void* ptr_; //exposition only void (*format_)(basic_format_parse_context<char_type>&*, Context&, const void*); //exposition only template<class T> explicit handle(T&& val) noexcept; //exposition only friend class basic_format_arg<Context>; //exposition only public: void format(basic_format_parse_context<char_type>&, Context& ctx) const; };}template<class T> explicit handle(T&& val) noexcept;-17- […]
-18- […]-19-Effects: Initializesptr_withaddressof(val)andformat_with[](basic_format_parse_context<char_type>&* parse_ctx, Context& format_ctx, const void* ptr) { typename Context::template formatter_type<TD> f;if (parse_ctx) parse_ctx.->advance_to(f.parse(*parse_ctx)); format_ctx.advance_to(f.format(*const_cast<TQ*>(static_cast<const TD*>(ptr)), format_ctx));}void format(basic_format_parse_context<char_type>& parse_ctx, Context& format_ctx) const;-20-Effects:If theformat-spec (28.5.2[format.string]) is not present or empty,equivalent to:
format_(nullptr, format_ctx, ptr_);otherwise, e
Equivalent to:format_(addressof(parse_ctx), format_ctx, ptr_);
ranges::fold_* can unintentionallyconst_cast andreinterpret_castSection: 26.6.18[alg.fold]Status:NADSubmitter: Nicole MazzucaOpened: 2022-09-15Last modified: 2022-11-30
Priority:Not Prioritized
View otheractive issues in [alg.fold].
View all otherissues in [alg.fold].
View all issues withNAD status.
Discussion:
In theEffects element ofranges::fold_right, we get the following code:
using U = decay_t<invoke_result_t<F&, iter_reference_t<I>, T>>;if (first == last) return U(std::move(init)); //functional-style C cast[…]Given the following function object:
struct Second { static char* operator()(const char*, char* rhs) { return rhs; }};callingfold_right as:
char* p = fold_right(views::empty<char*>, "Hello", Second{});initializesp withconst_cast<char*>("Hello").
fold_left_with_iter, and thus infold_left.One can get thereinterpret_cast behavior by replacingconst char* withunsigned long long.[2022-10-12; Reflector poll]
Set status to "Tentatively NAD" after reflector poll.
"The example doesn't compile. The accumulator should be be the second param,but with that fixed the constraints are not satisfied.Theconvertible_to constraint prevents the undesirable casting."
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4917.
Modify 26.6.18[alg.fold] as indicated:
template<bidirectional_iterator I, sentinel_for<I> S, class T,indirectly-binary-right-foldable<T, I> F> constexpr auto ranges::fold_right(I first, S last, T init, F f);template<bidirectional_range R, class T,indirectly-binary-right-foldable<T, iterator_t<R>> F> constexpr auto ranges::fold_right(R&& r, T init, F f);[…]-3-Effects: Equivalent to:
using U = decay_t<invoke_result_t<F&, iter_reference_t<I>, T>>;if (first == last) returnstatic_cast<U>(std::move(init));I tail = ranges::next(first, last);U accum = invoke(f, *--tail, std::move(init));while (first != tail) accum = invoke(f, *--tail, std::move(accum));return accum;template<input_iterator I, sentinel_for<I> S, class T,indirectly-binary-left-foldable<T, I> F> constexprsee below ranges::fold_left_with_iter(I first, S last, T init, F f);template<input_range R, class T,indirectly-binary-left-foldable<T, iterator_t<R>> F> constexprsee below ranges::fold_left_with_iter(R&& r, T init, F f);-6- Let
-7-Effects: Equivalent to:Ubedecay_t<invoke_result_t<F&, T, iter_reference_t<I>>>.if (first == last) return {std::move(first),static_cast<U>(std::move(init))};U accum = invoke(f, std::move(init), *first);for (++first; first != last; ++first) accum = invoke(f, std::move(accum), *first);return {std::move(first), std::move(accum)};
operator delete[]Section: 17.6.3.3[new.delete.array]Status:NADSubmitter: blacktea hamburgerOpened: 2022-09-25Last modified: 2022-11-30
Priority:Not Prioritized
View all otherissues in [new.delete.array].
View all issues withNAD status.
Discussion:
Consider (operator delete[](std::size_t) andoperator new(std::size_t) is not replaced):
operator delete[](operator new(1));
(even not replaced)void* operator new(std::size_t) does not returnvoid* operator new[](std::size_t). So the behavior is undefined according to 17.6.3.3[new.delete.array] paragraph 9:
Preconditions:
ptris a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced)operator new[](std::size_t)oroperator new[](std::size_t, std::align_val_t)which has not been invalidated by an intervening call tooperator delete[].
However, consider (operator delete(std::size_t) andoperator new[](std::size_t) is not replaced):
operator delete(operator new[](1));
(not replaced)operator new[](std::size_t) simply returnsoperator new(std::size_t) according to 17.6.3.3[new.delete.array] paragraph 4:
Default behavior: Returns
operator new(size), oroperator new(size, alignment), respectively.
So it is well-formed according to 17.6.3.2[new.delete.single] paragraph 10:
Preconditions:
ptris a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced)operator new(std::size_t)oroperator new(std::size_t, std::align_val_t)which has not been invalidated by an intervening call tooperator delete.
The behavior should be consistent.
[2022-10-10; Reflector poll]
Set status to "Tentatively NAD" after reflector poll.
"No reason to carve out an exception covering a case on something which can’tbe observed by the program (whether the allocation operators are replaced).This just makes things more complicated for no good reason.""This would require changes to sanitizers and other dynamic analyzers,for zero practical benefit (except allowing bad code to go un-diagnosed)."
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4917.
Modify 17.6.3.3[new.delete.array] as indicated:
void operator delete[](void* ptr) noexcept;void operator delete[](void* ptr, std::size_t size) noexcept;void operator delete[](void* ptr, std::align_val_t alignment) noexcept;void operator delete[](void* ptr, std::size_t size, std::align_val_t alignment) noexcept;-9-Preconditions:
[…]ptris a null pointer or its value represents the address of a block of memory allocated by an earlier call to a (possibly replaced)operator new[](std::size_t),oroperator new[](std::size_t, std::align_val_t), (not replaced)operator new(std::size_t), oroperator new(std::size_t, std::align_val_t)which has not been invalidated by an intervening call tooperator delete[].
std::match_resultsSection: 28.6.9.1[re.results.general]Status:NADSubmitter: Jonathan WakelyOpened: 2022-10-25Last modified: 2022-11-30
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
std::match_results meets some of the requirements for an allocator-aware container, which means that itsallocator_type must have the samevalue_type as the container. This means that class template argument deduction should work for:
std::match_results mr(alloc);
The allocator'svalue_type will be thesub_match<Iter> type stored in thematch_results object, and so the first template argument for thematch_results type will bevalue_type::iterator.
std::basic_regex, but I see no rationale for not adding one forstd::match_results. This seems like a defect, because all other allocator-aware containers support deduction from an allocator argument.[2022-11-01; reflector poll]
Status changed to Tentatively NAD. The issue is wrong: other containersdo not support deduction from an allocator type.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4917.
Modify 28.6.9.1[re.results.general], class templatematch_results synopsis, as indicated:
namespace std { template<class BidirectionalIterator, class Allocator = allocator<sub_match<BidirectionalIterator>>> class match_results { […] void swap(match_results& that); };template<class Allocator> match_results(Allocator) -> match_results<typename Allocator::value_type::iterator, Allocator>;}formattable<T, charT> default tochar?Section: 28.5.6.3[format.formattable]Status:NADSubmitter: Jonathan WakelyOpened: 2022-10-28Last modified: 2023-01-24
Priority:2
View otheractive issues in [format.formattable].
View all otherissues in [format.formattable].
View all issues withNAD status.
Discussion:
For many uses of<format> there's no need to explicitly mention the output type aschar. There are either typedefs forchar specializations (format_context,format_parse_context,format_args, etc.) or a default template argument (formatter,range_formatter). But for the newformattable concept you always need to specify the character type:
static_assert( std::formattable<int> ); //ill-formedstatic_assert( std::formattable<int, char> ); // OKShould the concept have a default template argument for the second parameter, to make it easier to check whether something isformattable aschar?
[2022-11-01; Reflector poll]
Set priority to 2 after reflector poll.Two votes for NAD, the convenience makes it easier to misuse.
[2022-11-30; Reflector poll]
Set status to "Tentatively NAD" after ten votes in reflector poll.
[2022-11-30 LWG telecon. Status changed: Tentatively NAD → NAD.]
[2023-01-24 LEWG electronic poll; weak consensus to reject the propsed change.]
Proposed resolution:
This wording is relative toN4917.
Modify 28.5.1[format.syn] as indicated:
[…]// 28.5.6[format.formatter], formattertemplate<class T, class charT = char> struct formatter;// 28.5.6.3[format.formattable], concept formattabletemplate<class T, class charT= char> concept formattable =see below;[…]
Modify 28.5.6.3[format.formattable] as indicated:
[Drafting note: This repeats the default template argument already shown in the synopsis, which would not be valid in C++ code. That is consistent with our presentation style though, as this is not C++ code, it's a specification. See e.g.
indirect_strict_weak_orderandsubrange.]
-1- Let
fmt-iter-for<charT>be an unspecified type that modelsoutput_iterator<const charT&>(24.3.4.10[iterator.concept.output]).template<class T, class charT= char> concept formattable = semiregular<formatter<remove_cvref_t<T>, charT>> && requires(formatter<remove_cvref_t<T>, charT> f, const formatter<remove_cvref_t<T>, charT> cf, T t, basic_format_context<fmt-iter-for<charT>, charT> fc, basic_format_parse_context<charT> pc) { { f.parse(pc) } -> same_as<basic_format_parse_context<charT>::iterator>; { cf.format(t, fc) } -> same_as<fmt-iter-for<charT>>; };
Section: 17.3.2[version.syn]Status:NADSubmitter: Daniel MarshallOpened: 2022-11-02Last modified: 2022-11-12
Priority:Not Prioritized
View otheractive issues in [version.syn].
View all otherissues in [version.syn].
View all issues withNAD status.
Discussion:
ranges::shift is seemingly the only ranges algorithm that incremented the value of an existing feature test macro.
__cpp_lib_starts_ends_with.Should there have been a__cpp_lib_ranges_shift or should have__cpp_lib_starts_ends_with incremented its value when the ranges algorithms were added?[Kona 2022-11-12 Status changed: New → NAD.]
Proposed resolution:
basic_const_iterator is too strict to provideiterator_categorySection: 24.5.3.4[const.iterators.types]Status:NADSubmitter: Hewill KangOpened: 2023-01-22Last modified: 2023-02-06
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
Currently,basic_const_iterator providesiterator_category member only when the underlying iterator modelsforward_iterator, which means that it will not provideinput_iterator_tag when applied to any C++17 legacy iterator.
iterator_category only by detecting whether theiterator_traits specialization of the underlying iterator has a validiterator_category, as is common practice for other iterator adaptors in<iterator>.[2023-02-06 Status changed: New → NAD.]
Set status to NAD after reflector poll.
Proposed resolution:
This wording is relative toN4928.
Modify 24.5.3.4[const.iterators.types] as indicated:
-2- The membertypedef-name
iterator_categoryis defined if and only ifthequalified-iditerator_traits<Iterator>::iterator_categoryis valid and denotes a type. In that case,Iteratormodelsforward_iteratorbasic_const_iterator<Iterator>::iterator_categorydenotes the typeiterator_traits<Iterator>::iterator_category.
__cpp_lib_ranges_to_container to__cpp_lib_ranges_toSection: 17.3.2[version.syn]Status:NADSubmitter: Hewill KangOpened: 2023-02-05Last modified: 2023-02-08
Priority:Not Prioritized
View otheractive issues in [version.syn].
View all otherissues in [version.syn].
View all issues withNAD status.
Discussion:
LWG3785(i) enablesranges::to to construct a non-range object from a range, confirming that this is the intended part of the original design.
ranges::to is still named__cpp_lib_ranges_to_container, where the "container" part seems confusing to users.[Issaquah 2023-02-08 Status changed: New → NAD.]
No consensus to change anything. The macro name is just a unique identifier,it doesn't have to be a precise description of the feature.
Proposed resolution:
This wording is relative toN4928.
Modify 17.3.2[version.syn], header<version> synopsis, as indicated:
[…]#define __cpp_lib_ranges_stride 202207L// also in <ranges>#define __cpp_lib_ranges_to_container202202L// also in <ranges>#define __cpp_lib_ranges_zip 202110L// also in <ranges>, <tuple>, <utility>[…]
Section: 20.2.8[allocator.uses]Status:NADSubmitter: Jiang AnOpened: 2023-03-05Last modified: 2024-06-24
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
LWG3870(i) madestd::construct_at unable to create an object of acv-qualified type, which affectsstd::uninitialized_construct_using_allocator. However, uses-allocator construction is currently not required to be equivalent to some call tostd::uninitialized_construct_using_allocator, which possibly implies that uses-allocator construction of acv-qualified type may still be required to be well-formed.
[2023-03-22; Reflector poll]
Set status to Tentatively NAD.
Not all uses-allocator construction is done usingconstruct_at.std::tuple<const T>(allocator_arg, alloc) doesuses-allocator construction of a const type, so we can't make it ill-formed.
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
ranges::const_iterator_t<range R> fails to accept arrays of unknown boundSection: 25.2[ranges.syn]Status:NADSubmitter: Arthur O'DwyerOpened: 2023-03-28Last modified: 2023-11-07
Priority:3
View otheractive issues in [ranges.syn].
View all otherissues in [ranges.syn].
View all issues withNAD status.
Discussion:
ranges::iterator_t<T> is unconstrained; but in contrast,ranges::const_iterator_t<T> constrainsT to be arange,i.e., it must have anend.
static_assert(std::is_same_v<std::ranges::iterator_t<int(&)[2]>, int*>); static_assert(std::is_same_v<std::ranges::iterator_t<int(&)[]>, int*>); // OK static_assert(std::is_same_v<std::ranges::const_iterator_t<int(&)[2]>, const int*>); static_assert(std::is_same_v<std::ranges::const_iterator_t<int(&)[]>, const int*>); // hard error[2023-06-01; Reflector poll]
Set priority to 3 after reflector poll. Several votes for NAD.Send to SG9 to be looked at withP2836.
[Kona 2023-11-07; SG9]
SG9 considered this and noted it's obsolete due to LWG3946(i).To support this case now would require changingranges::cbeginto add a special case for arrays of unknown bound, which would require a paper.
[Kona 2023-11-07; Status changed: Open → NAD.]
Proposed resolution:
This wording is relative toN4944.
Modify 25.2[ranges.syn] as indicated:
template<class T> using iterator_t = decltype(ranges::begin(declval<T&>()));// freestanding template<range R> using sentinel_t = decltype(ranges::end(declval<R&>()));// freestanding template<rangeclass R> using const_iterator_t = const_iterator<iterator_t<R>>;// freestanding template<range R> using const_sentinel_t = const_sentinel<sentinel_t<R>>;// freestanding
Section: 21[meta]Status:NADSubmitter: Alisdair MeredithOpened: 2023-05-01Last modified: 2024-06-24
Priority:Not Prioritized
View otheractive issues in [meta].
View all otherissues in [meta].
View all issues withNAD status.
Discussion:
There are many traits that have a requirement that they are instantiated only if"T shall be a complete type,cvvoid, or an array of unknown bound."
void and arrays of unknownbound (almost) the only remaining type-category is incomplete class types.The remaining edge case is incomplete enumerations, but they are required tohave a known fixed-base, so act as complete types, they can be copied,assigned, etc., without knowing the names of their enumerators.Hence, I suggest clearer wording would be:"T shall not be an incomplete class type."This is easier to understand, as we do not need to mentally enumerate everytype against a list to check it qualifies; it is a simpler test for the library tocheck if we were to mandate these restrictions.There are a very small number of traits with subtly different wording, whereincomplete unions are supported, or arrays of unknown bound are not aconcern due to invokingremove_all_extents first. The bulk of the changescan be made to traits with only the precise wording above though, and thenwe can review whether any of the remaining restrictions deserve a wordingupdate of their own.[2023-06-01; Reflector poll]
Set status to Tentatively NAD after four votes in favour during reflector poll,including a request to withdraw the issue from the submitter.
Incomplete enumeration types are found within theenum-specifierof an enum without a fixed underlying type:
enum E { A = sizeof(E) // error, E is incomplete at this point};[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4944.
Throughout 21[meta] replace all occurrences of
Tshall be a complete type,cvvoid, or an array of unknown bound.
by
Tshall not be an incomplete class type.
Section: D[depr]Status:NADSubmitter: Jiang AnOpened: 2023-05-22Last modified: 2024-06-24
Priority:Not Prioritized
View all issues withNAD status.
Discussion:
D.1[depr.general]/2 allows implementations to apply thedeprecated attribute to deprecated components.However, there doesn't seem to be any wording disallowing applying thedeprecated attribute to non-deprecated components.
Is it intended to allow implementations to deprecate every library componentas they want? If so, should we turn the allowance into "Recommended practice" and move it to somewhere in 16.4[requirements]?
There doesn't seem to be wording which formally recommends applyingdeprecated attribute to deprecated components either.
[2023-06-01; Reflector poll]
Set status to Tentatively NAD after nine votes in favour during reflector poll.Let implementations decide when to apply these attributes.
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4950.
[Drafting Note:There are two mutually exclusive proposed resolutions,depending on whether it is allowed to deprecate components not inD[depr].
Option A:
Insert a paragraph at the end of 16.4.2.2[contents]:
-?-Recommended practice:Implementations should not apply the
deprecatedattribute(9.13.4[dcl.attr.deprecated]) to library entities that are notspecified in D[depr].Implementations should apply thedeprecatedattribute tolibrary entities specified in D[depr] whenever possible.
Option B:
Insert two paragraphs at the end of 16.4.2.2[contents]:
-?- Implementations shall not apply the
deprecatedattribute(9.13.4[dcl.attr.deprecated]) to library entities that are notspecified in D[depr].-?-Recommended practice:Implementations should apply the
deprecatedattribute tolibrary entities specified in D[depr] whenever possible.
Section: 25.7.15.2[range.join.with.view]Status:NADSubmitter: Hewill KangOpened: 2023-08-21Last modified: 2024-06-24
Priority:3
View all otherissues in [range.join.with.view].
View all issues withNAD status.
Discussion:
The issue thatconcat_view implicitly breaks equality-preserving by concatenating range of references with range of prvalues seems to be reflected injoin_view as well.
string&& and the reference of the pattern range is prvaluestring, dereferencing its iterator will move the elements of the inner range to the returnedstring, which makes the second dereference get an emptystring (demo):vector v1{"hello"s};vector v2{"world"s};vector v{v1 | views::as_rvalue, v2 | views::as_rvalue};auto pattern = views::iota(0, 1) | views::transform([](int) { return ", "s; });ranges::forward_range auto joined = v | views::join_with(pattern);fmt::print("{}\n", joined); // ["hello", ", ", "world"]fmt::print("{}\n", joined); //["", ", ", ""]Not sure if we should ban such less common case.
[2023-10-30; Reflector poll]
Set priority to 3 after reflector poll. Send to SG9.
[2024-03-19; Tokyo: feedback from SG9]
SG9 believe that LWG3971 is a use-after-move and is working as intended.We further believe that matching the behavior ofconcat_view(which is the current behavior) is important. This is not a defect.
[St. Louis 2024-06-24 Status changed: Open → NAD.]
Proposed resolution:
projected<I, identity> should just beISection: 24.3.6.4[projected]Status:NADSubmitter: Hewill KangOpened: 2023-10-12Last modified: 2024-06-24
Priority:Not Prioritized
View all otherissues in [projected].
View all issues withNAD status.
Discussion:
Currently,projected is a wrapper of the implementation type regardless of whetherProj isidentity.
identity always returns a reference, this preventsprojected<I, identity> from fully emulating the properties of the original iterator when its reference is a prvalue.Such non-equivalence may lead to unexpected behavior in some cases (demo):#include <algorithm>#include <ranges>#include <iostream>int main() { auto outer = std::views::iota(0, 5) | std::views::transform([](int i) { return std::views::single(i) | std::views::filter([](int) { return true; }); }); for (auto&& inner : outer) for (auto&& elem : inner) std::cout << elem << " "; // 0 1 2 3 4 std::ranges::for_each( outer, [](auto&& inner) { //error: passing 'const filter_view' as 'this' argument discards qualifiers for (auto&& elem : inner) std::cout << elem << " "; });}In the above example,ranges::for_each requiresindirect_unary_predicate<Pred, projected<I, identity>>which ultimately requiresinvocable<Pred&, iter_common_reference_t<projected<I, identity>>>.
projected<I, identity> arefilter_view&& andfilter_view& respectively, which causes its common reference to be eventually calculated asconst filter_view&. Since the former is notconst-iterable, this results in a hard error during instantiation becauseconst begin is called unexpectedly in an unconstrained lambda.It seems like havingprojected<I, identity> just beI is a more appropriate choice, which makes the concept checking really specific toI rather than a potentially incomplete iterator wrapper.
[2023-11-03; Reflector poll]
NAD.P2997 solves this, and more."Applying the projection does in fact materialize prvalues,so this is just lying unless we special-case identity everywhere."
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4958.
Modify 24.3.6.4[projected] as indicated:
-1- Class template
projectedis used to constrain algorithms that accept callable objects and projections (3.44[defns.projection]). It combines anindirectly_readabletypeIand a callable object typeProjinto a newindirectly_readabletype whosereferencetype is the result of applyingProjto theiter_reference_tofI.namespace std { template<class I, class Proj> structprojected-impl { //exposition only structtype { //exposition only using value_type = remove_cvref_t<indirect_result_t<Proj&, I>>; using difference_type = iter_difference_t<I>; //present only if I //models weakly_incrementable indirect_result_t<Proj&, I> operator*() const; //not defined }; }; template<indirectly_readable I, indirectly_regular_unary_invocable<I> Proj> using projected =conditional_t<is_same_v<Proj, identity>, I, typenameprojected-impl<I, Proj>::type>;}
std::swap are under-specifiedSection: 22.2.2[utility.swap]Status:NADSubmitter: Jan SchultkeOpened: 2024-02-28Last modified: 2024-06-24
Priority:Not Prioritized
View all otherissues in [utility.swap].
View all issues withNAD status.
Discussion:
Subclause 22.2.2[utility.swap] describes the effect ofstd::swap as follows:
Effects: Exchanges values stored in two locations.
This description is extremely vague. A possible implementation which complies with this wording is:
template<class T>constexpr void swap(T&, T&) noexcept(/* ... */){ int __x = 0, __y = 0; int __z = __x; __x = __y; __y = __z;}This exchanges values stored in two locations; namely in the locations of two objects with automatic storage duration withinswap. Since this has no observable effect and complies, it is also valid to implementswap as follows:
template<class T>constexpr void swap(T&, T&) noexcept(/* ... */) { }Furthermore, there is implementation divergence.libc++ uses direct-initialization to construct a temporaryT, butlibstdc++ uses copy-initialization. For most types, this hopefully calls the same constructor, however, this is not universally true. The standard should specify in more detail what is meant to happen.
[2024-03-15; Reflector poll]
Set status to Tentatively NAD Editorial after reflector poll.
Cpp17MoveConstructible require direct-init and copy-init to besemantically equivalent, so the different implementation techniques canonly be observed by types which fail to meet the function's preconditions.
Replace the unusual "stored in two locations" wordingeditorially.
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4971.
Modify 22.2.2[utility.swap] as indicated:
template<class T> constexpr void swap(T& a, T& b) noexcept(see below);-1-Constraints:
-2-Preconditions: Typeis_move_constructible_v<T>istrueandis_move_assignable_v<T>istrue.Tmeets theCpp17MoveConstructible (Table 31) andCpp17MoveAssignable (Table 33) requirements.-3-Effects:Exchanges values stored in two locations.Equivalent to:auto t(std::move(a));a = std::move(b);b = std::move(t);-4-Remarks: The exception specification is equivalent to: […]
Section: 16.4.4[utility.requirements]Status:NADSubmitter: Detlef VollmannOpened: 2024-04-21Last modified: 2025-11-06
Priority:3
View all otherissues in [utility.requirements].
View all issues withNAD status.
Discussion:
P0260R8 had a requirement for constructors and destructors ofconcurrent queue value types to return on the same thread where it was called.
During the discussion in Tokyo, SG1 decided this to be a generalissue and not specific to concurrent queues.[2024-06-24; Reflector poll]
Set priority to 3 after reflector poll. Send to SG1.
[Kona 2025-11-06; Status changed: SG1 → NAD.]
SG1 response: It has been determined that this cannot happen.The only facility which can change the thread is co-routines,and they cannot apply to constructors and destructors (yet).There is nothing to be done about this after all.
Proposed resolution:
ranges::generate_random_n is missingSection: 26.12.2[alg.rand.generate]Status:NADSubmitter: Hewill KangOpened: 2024-04-29Last modified: 2024-06-24
Priority:Not Prioritized
View all otherissues in [alg.rand.generate].
View all issues withNAD status.
Discussion:
P1068 introducedranges::generate_random which has both range and iterator-sentinel pair overloads. However, the_n version never seems to be discussed.
generate andfill have their corresponding_n siblings, namelygenerate_n andfill_n, addinggenerate_random_n does improve consistency and provide a more intuitive and simple way to generate a specified number of random numbers.[2024-06-24; Reflector poll]
NAD, this is a feature request not a defect. Needs a paper.
[St. Louis 2024-06-24 Status changed: Tentatively NAD → NAD.]
Proposed resolution:
This wording is relative toN4981.
Modify 29.5.2[rand.synopsis], header<random> synopsis, as indicated:
#include <initializer_list> //see 17.11.2[initializer.list.syn]namespace std { […] namespace ranges { //26.12.2[alg.rand.generate], generate_random template<class R, class G> requires output_range<R, invoke_result_t<G&>> && uniform_random_bit_generator<remove_cvref_t<G>> constexpr borrowed_iterator_t<R> generate_random(R&& r, G&& g); template<class G, output_iterator<invoke_result_t<G&>> O, sentinel_for<O> S> requires uniform_random_bit_generator<remove_cvref_t<G>> constexpr O generate_random(O first, S last, G&& g);template<class G, output_iterator<invoke_result_t<G&>> O> requires uniform_random_bit_generator<remove_cvref_t<G>> constexpr O generate_random_n(O first, iter_difference_t<O> n, G&& g); template<class R, class G, class D> requires output_range<R, invoke_result_t<D&, G&>> && invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>> constexpr borrowed_iterator_t<R> generate_random(R&& r, G&& g, D&& d); template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O, sentinel_for<O> S> requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>> constexpr O generate_random(O first, S last, G&& g, D&& d);template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O> requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>> constexpr O generate_random_n(O first, iter_difference_t<O> n, G&& g, D&& d); } […]}
Modify 26.12.2[alg.rand.generate] as indicated:
template<class G, output_iterator<invoke_result_t<G&>> O, sentinel_for<O> S> requires uniform_random_bit_generator<remove_cvref_t<G>>constexpr O ranges::generate_random(O first, S last, G&& g);-4-Effects: Equivalent to:
return generate_random(subrange<O, S>(std::move(first), last), g);template<class G, output_iterator<invoke_result_t<G&>> O> requires uniform_random_bit_generator<remove_cvref_t<G>>constexpr O ranges::generate_random_n(O first, iter_difference_t<O> n, G&& g);[…]-?-Effects: Equivalent to:
return generate_random(counted_iterator(std::move(first), n), default_sentinel, g).base();template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O, sentinel_for<O> S> requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>>constexpr O ranges::generate_random(O first, S last, G&& g, D&& d);-8-Effects: Equivalent to:
return generate_random(subrange<O, S>(std::move(first), last), g, d);template<class G, class D, output_iterator<invoke_result_t<D&, G&>> O> requires invocable<D&, G&> && uniform_random_bit_generator<remove_cvref_t<G>>constexpr O ranges::generate_random_n(O first, iter_difference_t<O> n, G&& g, D&& d);-?-Effects: Equivalent to:
return generate_random(counted_iterator(std::move(first), n), default_sentinel, g, d).base();
Section: 24.3.1[iterator.requirements.general], 24.3.5.1[iterator.cpp17.general], 26.7.5[alg.replace], 26.7.6[alg.fill], 26.7.8[alg.remove], 26.7.9[alg.unique], 26.7.12[alg.random.sample], 26.8.2.4[partial.sort.copy], 26.8.5[alg.partitions], 26.10.7[partial.sum], 26.10.12[adjacent.difference], 29.5.8.1[rand.util.seedseq]Status:NAD EditorialSubmitter: Alisdair MeredithOpened: 2024-11-27Last modified: 2024-12-04
Priority:Not Prioritized
View all otherissues in [iterator.requirements.general].
View all issues withNAD Editorial status.
Discussion:
There are a numerous algorithms that mandate an iterator is "writable (24.3.1[iterator.requirements.general])":e.g., for thestd::fill algorithm, 26.7.6[alg.fill] 26.7.6p2
Mandates: The expression value is writable (24.3.1[iterator.requirements.general]) to the output iterator.
However, checking 24.3.1[iterator.requirements.general] I can find no definition for the term "writable".Checking past standards, I found that in C++17 we have the following definition:
An output iterator
ihas a non-empty set of types that arewritable to the iterator;
However, when we introduced the concept-based iterator taxonomy, this definition was replaced by:
An output iterator
ihas a non-empty set of types that areindirectly_writableto the iterator;
where the term of power is no longer defined, but a concept is used to define the relationship between iterator and value instead. We need to either find and fix each reference to "writable" (or more properly "writable to" — the old term is a relationship between two types, not a property of just one) using theindirectly_writable concept, or restore a definition of the term of power — likely phrased in terms of theindirectly_writable concept.
Change stable name [iterator.concept.writable] to [iterator.concept.indirectly.writable] and globallyreplace all occurrences of "
writable" (the concept) with "indirectly_writable"
has either been incorrectly applied 24.3.1[iterator.requirements.general] (because that position did notactually refer to thewritable concept) or if the interpretation that the originalwritabledefinition from 24.3.1[iterator.requirements.general] was intended to be aliased with thewritableconcept this substitution has been incompletely applied to the working draft.
[2024-12-04 Status changed: New → NAD Editorial.]
Proposed resolution: