| Doc. no. | +N2729=08-0239 | +
| Date: | +2008-08-24 | +
| Project: | +Programming Language C++ | +
| Reply to: | +Howard Hinnant <howard.hinnant@gmail.com> | +
Reference ISO/IEC IS 14882:1998(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 of Dup or + NAD. See the Library Active Issues List active issues and more + information. See the Library Defect Reports List for issues considered + defects. The introductory material in that document also applies to + this document.
+ +Section: D.9.1.3 [auto.ptr.conv] Status: NAD + Submitter: Nathan Myers Date: 1997-12-04
+View all issues with NAD status.
+Discussion:
+Paragraph 1 in "Effects", says "Calls +p->release()" where it clearly must be "Calls +p.release()". (As it is, it seems to require using +auto_ptr<>::operator-> to refer to X::release, assuming that +exists.)
+ + +Proposed resolution:
+Change 20.5.4.3 [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.]
+ + + + + +Section: 21.3 [basic.string] Status: NAD + Submitter: Beman Dawes Date: 1997-11-16
+View other active issues in [basic.string].
+View all other issues in [basic.string].
+View all issues with NAD status.
+Discussion:
+In Morristown we changed the size_type and difference_type typedefs +for all the other containers to implementation defined with a +reference to 23.1 [container.requirements]. This should probably also have been +done for strings.
+ + +Rationale:
+Not a defect. [Originally classified as a defect, later +reclassified.] basic_string, unlike the other standard library +template containers, is severely constrained by its use of +char_traits. Those types are dictated by the traits class, and are far +from implementation defined.
+ + + + + +Section: 27.4.3 [fpos] Status: NAD + Submitter: Matt Austern Date: 1997-12-15
+View all other issues in [fpos].
+View all issues with NAD status.
+Discussion:
+Table 88, in I/O, is too strict; it's unimplementable on systems +where a file position isn't just an offset. It also never says just +what fpos<> is really supposed to be. [Here's my summary, which +Jerry agrees is more or less accurate. "I think I now know what +the class really is, at this point: it's a magic cookie that +encapsulates an mbstate_t and a file position (possibly represented as +an fpos_t), it has syntactic support for pointer-like arithmetic, and +implementors are required to have real, not just syntactic, support +for 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: 22.2.1.5 [locale.codecvt.byname] Status: Dup + Submitter: Matt Austern Date: 1998-01-14
+View all other issues in [locale.codecvt.byname].
+View all issues with Dup status.
+Duplicate of: 19
+Discussion:
+Section 22.2.1.5.2 says that codecvt<>::do_in and do_out +should return the value noconv if "no conversion was +needed". However, I don't see anything anywhere that defines what +it means for a conversion to be needed or not needed. I can think of +several circumstances where one might plausibly think that a +conversion is not "needed", but I don't know which one is +intended here.
+ + +Rationale:
+ + + + + + +Section: 20.1.2 [allocator.requirements] Status: NAD + Submitter: Angelika Langer Date: 1998-02-23
+View other active issues in [allocator.requirements].
+View all other issues in [allocator.requirements].
+View all issues with NAD status.
+Discussion:
+I couldn't find a statement in the standard saying whether the allocator object held by +a container is held as a copy of the constructor argument or whether a pointer of +reference is maintained internal. There is an according statement for compare objects and +how they are maintained by the associative containers, but I couldn't find anything +regarding allocators.
+ +Did I overlook it? Is it an open issue or known defect? Or is it deliberately left +unspecified?
+ + +Rationale:
+Not a defect. The LWG believes that the Standard is already +clear. See 23.1 [container.requirements], paragraph 8.
+ + + + + +Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup + Submitter: Brendan Kehoe Date: 1998-06-01
+View all other issues in [locale.codecvt.byname].
+View all issues with Dup status.
+Duplicate of: 33
+Discussion:
+ + +Rationale:
+ + + + + + +Section: 27.7.3 [ostringstream] Status: NAD + Submitter: Matthias Mueller Date: 1998-05-27
+View all issues with NAD status.
+Discussion:
+In a comp.lang.c++.moderated Matthias Mueller wrote:
+ +"We are not sure how to interpret the CD2 (see 27.2 +[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1 +[stringbuf.cons]) +with respect to the question as to what the correct initial positions +of the write and read pointers of a stringstream should +be."
+ +"Is it the same to output two strings or to initialize the stringstream with the +first and to output the second?"
+ +[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and +Jerry Schwarz have all offered opinions; see reflector messages +lib-6518, 6519, 6520, 6521, 6523, 6524.]
+ + + + +Rationale:
+The LWG believes the Standard is correct as written. The behavior +of stringstreams is consistent with fstreams, and there is a +constructor which can be used to obtain the desired effect. This +behavior is known to be different from strstreams.
+ + + + + +Section: 27.6.1.2.3 [istream::extractors] Status: NAD + Submitter: Matt Austern Date: 1998-07-01
+View all other issues in [istream::extractors].
+View all issues with NAD status.
+Discussion:
+27.6.1.2.3 has member functions for extraction of signed char and +unsigned char, both singly and as strings. However, it doesn't say +what it means to extract a char from a +basic_streambuf<charT, Traits>.
+ +basic_streambuf, after all, has no members to extract a char, so +basic_istream must somehow convert from charT to signed char or +unsigned char. The standard doesn't say how it is to perform that +conversion.
+ + +Rationale:
+The Standard is correct as written. There is no such extractor and +this is the intent of the LWG.
+ + + + +Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD + Submitter: Matt Austern Date: 1998-08-18
+View all other issues in [depr.strstreambuf.virtuals].
+View all issues with NAD status.
+Discussion:
+The standard says how this member function affects the current +stream position. (gptr or pptr) However, it does not +say how this member function affects the beginning and end of the +get/put area.
+ +This is an issue when seekoff is used to position the get pointer +beyond the end of the current read area. (Which is legal. This is +implicit in the definition of seekhigh in D.7.1, paragraph 4.) +
+ + +Rationale:
+The LWG agrees that seekoff() is underspecified, but does not wish +to invest effort in this deprecated feature.
+ + + + + +Section: 21.3.8.9 [string.io] Status: Dup + Submitter: Steve Clamage Date: 1998-07-09
+View all other issues in [string.io].
+View all issues with Dup status.
+Duplicate of: 25
+Discussion:
+In a comp.std.c++ posting Michel Michaud wrote: What +should 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 width +of the field should be the minimum of width and the length of the +string, so the output shouldn't have any padding. I think that this is +a typo, however, and that what is wanted is the maximum of the +two. (As written, setw is useless for strings. If that had been the +intent, 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 formatting +parameters whatsoever.
+ + +Rationale:
+ + + + + + +Section: 22.2.1.4 [locale.codecvt] Status: Dup + Submitter: Nathan Myers Date: 1998-08-24
+View all other issues in [locale.codecvt].
+View all issues with Dup status.
+Duplicate of: 24
+Discussion:
+In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function +"do_convert" is mentioned. This member was replaced with +"do_in" and "do_out", the proper referents in the +contexts above.
+ + +Rationale:
+ + + + + +Section: 27.8.1 [fstreams] Status: NAD + Submitter: Matt Austern Date: 1998-08-27
+View all other issues in [fstreams].
+View all issues with NAD status.
+Discussion:
+Classes basic_ifstream, basic_ofstream, and +basic_fstream all have a member function is_open. It +should be a const member function, since it does nothing but +call one of basic_filebuf's const member functions.
+ + +Rationale:
+Not a defect. This is a deliberate feature; const streams would be +meaningless.
+ + + + +Section: 26.5.2.3 [valarray.access] Status: Dup + Submitter: Levente Farkas Date: 1998-09-09
+View all other issues in [valarray.access].
+View all issues with Dup 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 that +way. That is what valarray was designed to do; that's where the +"value array" name comes from. LWG members further comment +that "we don't want valarray to be a full STL container." +26.5.2.3 [valarray.access] specifies properties that indicate "an +absence of aliasing" for non-constant arrays; this allows +optimizations, including special hardware optimizations, that are not +otherwise possible.
+ + + + + +Section: 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [template.slice.array].
+View all issues with NAD 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.1.4 [associative.reqmts] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [associative.reqmts].
+View all issues with NAD status.
+Discussion:
+Paragraph 5 specifies:
+ ++ ++For set and multiset the value type is the same as the key type. For +map and multimap it is equal to pair<const Key, T>. +
Strictly speaking, this is not correct because for set and multiset +the value type is the same as the constant key type.
+ + +Rationale:
+Not a defect. The Standard is correct as written; it uses a +different mechanism (const &) for set and +multiset. See issue 103 for a related +issue.
+ + + + +Section: 21.3.5 [string.access] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all issues with NAD 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 "genetic +misfortune" inherent in the design of string and thus not a +defect in the Standard as such .
+ + + + +Section: 21 [strings] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [strings].
+View all issues with NAD status.
+Discussion:
+The standard seems not to require that charT is equivalent to +traits::char_type. So, what happens if charT is not equivalent to +traits::char_type?
+ + +Rationale:
+There is already wording in 21.1 [char.traits] paragraph 3 that +requires them to be the same.
+ + + + +Section: 21.3.6.8 [string::swap] Status: Dup + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [string::swap].
+View all issues with Dup status.
+Duplicate of: 5
+Discussion:
+The following compare() description is obviously a bug:
+ +int compare(size_type pos, size_type n1, + charT *s, size_type n2 = npos) const; ++ +
because without passing n2 it should compare up to the end of the +string instead of comparing npos characters (which throws an +exception)
+ + +Rationale:
+ + + + + +Section: 21.3.6.4 [string::insert], 21.3.6.2 [string::append] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [string::insert].
+View all issues with NAD 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: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: Dup + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [string::insert].
+View all issues with Dup status.
+Duplicate of: 83
+Discussion:
+All insert() and replace() members for strings with an iterator as +first argument lack a throw specification. The throw +specification should probably be: length_error if size exceeds +maximum.
+ + +Rationale:
+Considered a duplicate because it will be solved by the resolution +of issue 83.
+ + + + + +Section: 26.5 [numarray] Status: NAD + Submitter: Nico Josuttis Date: 1998-09-29
+View all other issues in [numarray].
+View all issues with NAD status.
+Discussion:
+You can easily create subsets, but you can't easily combine them +with other subsets. Unfortunately, you almost always needs an +explicit type conversion to valarray. This is because the standard +does not specify that valarray subsets provide the same operations as +valarrays.
+ +For example, to multiply two subsets and assign the result to a third subset, you can't +write 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 cast +creates 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: 17.4.4 [conforming] Status: NAD + Submitter: Matt Austern Date: 1998-01-22
+View all issues with NAD status.
+Discussion:
+Is it a permitted extension for library implementors to add template parameters to +standard library classes, provided that those extra parameters have defaults? For example, +instead of defining template <class T, class Alloc = allocator<T> > class +vector; defining it as template <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 extension +could break a conforming program, considering that users are not permitted to +forward-declare standard library components), but it ought to be explicitly permitted or +forbidden.
+ +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. For +example, a user library object may be templated on the type of +underlying sequence storage to use (deque/list/vector), since these +classes all take the same number and type of template parameters; this +would allow the user to determine the performance tradeoffs of the +user library object. A similar example is a user library object +templated on the type of underlying set storage (set/multiset) or map +storage (map/multimap), which would allow users to change (within +reason) the semantic meanings of operations on that object.
+I think that additional template parameters should be forbidden in +the Standard classes. Library writers don't lose any expressive power, +and can still offer extensions because additional template parameters +may 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 17.4.4.9 [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 at +the end of 17.4.4 [conforming] paragraph 1.
+ +[Kona: The LWG agreed the standard needs clarification. After +discussion with John Spicer, it seems added template parameters can be +detected by a program using template-template parameters. A straw vote +- "should implementors be allowed to add template +parameters?" found no consensus ; 5 - yes, 7 - no.]
+ + + + +Rationale:
++There is no ambiguity; the standard is clear as written. Library +implementors are not permitted to add template parameters to standard +library classes. This does not fall under the "as if" rule, +so it would be permitted only if the standard gave explicit license +for implementors to do this. This would require a change in the +standard. +
+ ++The LWG decided against making this change, because it would break +user code involving template template parameters or specializations +of standard library class templates. +
+ + + + + +Section: 17.4.4.4 [member.functions] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all issues with NAD status.
+Discussion:
+In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual +members 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 already +illegal. See 17.4.4.4 [member.functions] paragraph 2.
+ + + + +Section: 23 [containers] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with NAD status.
+Discussion:
+insert(iterator, const value_type&) is defined both on +sequences and on set, with unrelated semantics: insert here (in +sequences), and insert with hint (in associative containers). They +should have different names (B.S. says: do not abuse overloading).
+ + +Rationale:
+This is not a defect in the Standard. It is a genetic misfortune of +the design, for better or for worse.
+ + + + +Section: 24.4.1.3.13 [reverse.iter.op==] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all issues with NAD status.
+Discussion:
+The <, >, <=, >= comparison operator are wrong: they +return the opposite of what they should.
+ +Note: same problem in CD2, these were not even defined in CD1. SGI +STL code is correct; this problem is known since the Morristown +meeting but there it was too late
+ + +Rationale:
+This is not a defect in the Standard. A careful reading shows the Standard is correct +as written. A review of several implementations show that they implement +exactly what the Standard says.
+ + + + +Section: 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all issues with NAD status.
+Discussion:
+Overspecified For an insert iterator it, the expression *it is +required to return a reference to it. This is a simple possible +implementation, but as the SGI STL documentation says, not the only +one, 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 the +standard. The only example anyone could come up with caused some +incorrect code to work, rather than the other way around.
+ + + + + +Section: 23.2.6 [vector], 23.2.1 [array] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all other issues in [vector].
+View all issues with NAD status.
+Discussion:
+Reserve can not free storage, unlike string::reserve
+ + +Rationale:
+This is not a defect in the Standard. The LWG has considered this +issue in the past and sees no need to change the Standard. Deque has +no reserve() member function. For vector, shrink-to-fit can be +expressed in a single line of code (where v is +vector<T>): +
+ +++ + + + + +vector<T>(v).swap(v); // shrink-to-fit v
+
Section: 23.1.4 [associative.reqmts] Status: Dup + Submitter: AFNOR Date: 1998-10-07
+View all other issues in [associative.reqmts].
+View all issues with Dup status.
+Duplicate of: 264
+Discussion:
+Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems +impossible to implement, as it means that if [i, j) = [x], insert in an associative +container is O(1)!
+ + +Proposed resolution:
+N+log (size()) if [i,j) is sorted according to value_comp()
+ + +Rationale:
+Subsumed by issue 264.
+ + + + + +Section: 21.3.4 [string.capacity] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all other issues in [string.capacity].
+View all issues with NAD 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 () and +the non-const version is used, then the behavior is undefined.
+ + +Rationale:
+The Standard is correct. The proposed resolution already appears in +the Standard.
+ + + + +Section: 27.8 [file.streams] Status: Dup + Submitter: AFNOR Date: 1998-10-07
+View all issues with Dup 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 the +implementation non conforming.
+ + +Rationale:
+This is not a defect in the Standard. It might be an +interesting extension for the next Standard.
+ + + + +Section: 26.5.2 [template.valarray] Status: NAD + Submitter: AFNOR Date: 1998-10-07
+View all other issues in [template.valarray].
+View all issues with NAD 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 an +integral or floating point type, both types are convertible to each +other and reversing them leads to a well formed program.
+ + +Proposed resolution:
+Inverting the arguments could silently break programs. Introduce +the two signatures (const T&, size_t) and (size_t, const T&), +but make the one we do not want private so errors result in a +diagnosed access violation. This technique can also be applied to STL +containers.
+ + +Rationale:
+The LWG believes that while the order of arguments is unfortunate, +it does not constitute a defect in the standard. The LWG believes that +the proposed solution will not work for valarray<size_t> and +perhaps other cases.
+ + + + +Section: 24.5.3.5 [istreambuf.iterator::equal] Status: NAD Future + Submitter: Nathan Myers Date: 1998-10-15
+View all issues with NAD Future status.
+Discussion:
+The member istreambuf_iterator<>::equal is specified to be +unnecessarily inefficient. While this does not affect the efficiency +of conforming implementations of iostreams, because they can +"reach into" the iterators and bypass this function, it does +affect users who use istreambuf_iterators.
+ +The inefficiency results from a too-scrupulous definition, which +requires a "true" result if neither iterator is at eof. In +practice these iterators can only usefully be compared with the +"eof" value, so the extra test implied provides no benefit, +but slows down users' code.
+ +The solution is to weaken the requirement on the function to return +true only if both iterators are at eof.
+ + +Proposed resolution:
+Replace 24.5.3.5 [istreambuf.iterator::equal], +paragraph 1,
+ +++ +-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at + end-of-stream, regardless of what streambuf object they use.
+
with
+ +++ + + +-1- Returns: true if and only if both iterators are at + end-of-stream, regardless of what streambuf object they use.
+
Rationale:
+It is not clear that this is a genuine defect. Additionally, the +LWG was reluctant to make a change that would result in +operator== not being a equivalence relation. One consequence of +this change is that an algorithm that's passed the range [i, i) +would no longer treat it as an empty range.
+ + + + + +Section: 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] Status: NAD + Submitter: Steve Clamage Date: 1998-10-13
+View all other issues in [istream].
+View all issues with NAD 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 defined +semantics 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 internal +consistency.
+ +A larger question is whether sync should have assigned semantics for input streams.
+ +Classic iostreams said streambuf::sync flushes pending output and attempts to return +unread input characters to the source. It is a protected member function. The filebuf +version (which is public) has that behavior (it backs up the read pointer). Class +strstreambuf does not override streambuf::sync, and so sync can't be called on a +strstream.
+ +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 the +desired functionality.
+ +As for the other points, the LWG finds the standard correct as written.
+ + + + + +Section: 23.3.5 [template.bitset] Status: Dup + Submitter: Judy Ward Date: 1998-11-06
+View all other issues in [template.bitset].
+View all issues with Dup 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 templatized +constructor:
+ +++ +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 user +cannot pass this template constructor a const char* and +expect a conversion to basic_string. The reason is +"When you have a template constructor, it can get used in +contexts where type deduction can be done. Type deduction basically +comes up with exact matches, not ones involving conversions." +
+ +I don't think the intention when this constructor became +templatized was for construction from a const char* to no +longer work.
+ + +Proposed resolution:
+Add to 23.3.5 [template.bitset] a bitset constructor declaration
+ +++ +explicit bitset(const char*);+
and in Section 23.3.5.1 [bitset.cons] add:
+ +++ + +explicit bitset(const char* str);+Effects:
+
+ Calls bitset((string) str, 0, string::npos);
Rationale:
+Although the problem is real, the standard is designed that way so +it is not a defect. Education is the immediate workaround. A future +standard may wish to consider the Proposed Resolution as an +extension.
+ + + + + +Section: 22.1.1.1.1 [locale.category] Status: NAD + Submitter: Judy Ward Date: 1998-12-15
+View all other issues in [locale.category].
+View all issues with NAD status.
+Discussion:
+Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , +ctype<wchar_t>.
+ +Also Section 22.2.1.1 [locale.ctype] says:
+ +++ +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 22.2.1.3 [facet.ctype.special] +only has a detailed description of the ctype<char> specialization, not the +ctype<wchar_t> specialization.
+ + +Proposed resolution:
+Add the ctype<wchar_t> detailed class description to Section +22.2.1.3 [facet.ctype.special].
+ + +Rationale:
+Specialization for wchar_t is not needed since the default is acceptable.
+ + + + + +Section: 23.2.4.4 [list.ops] Status: NAD + Submitter: Howard Hinnant Date: 1999-03-06
+View all other issues in [list.ops].
+View all issues with NAD 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: 27.6.1.5.1 [iostream.cons] Status: NAD + Submitter: Howard Hinnant Date: 1999-03-06
+View all issues with NAD status.
+Discussion:
+-1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream) and +basic_ostream<charT,traits>(sb) (lib.ostream)
+ +The called for basic_istream and basic_ostream constructors call +init(sb). This means that the basic_iostream's virtual base class is +initialized twice.
+ + +Proposed resolution:
+Change 27.6.1.5.1, paragraph 1 to:
+ +-1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream).
+ + +Rationale:
+The LWG agreed that the init() function is called +twice, but said that this is harmless and so not a defect in the +standard.
+ + + + +Section: 22.2.1.4 [locale.codecvt] Status: NAD Future + Submitter: Angelika Langer Date: 1999-03-18
+View all other issues in [locale.codecvt].
+View all issues with NAD Future status.
+Discussion:
+Section 22.2.1.4 [locale.codecvt] specifies that +ctype_byname<char> must be a specialization of the ctype_byname +template.
+ +It is common practice in the standard that specializations of class templates are only +mentioned where the interface of the specialization deviates from the interface of the +template that it is a specialization of. Otherwise, the fact whether or not a required +instantiation is an actual instantiation or a specialization is left open as an +implementation detail.
+ +Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The +fact, that ctype_byname<char> is specified as a specialization suggests that there +must be something "special" about it, but it has the exact same interface as the +ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best +redundant, at worst misleading - unless I am missing anything.
+ +Naturally, an implementation will most likely implement ctype_byname<char> as a +specialization, because the base class ctype<char> is a specialization with an +interface different from the ctype template, but that's an implementation detail and need +not be mentioned in the standard.
+ + +Rationale:
+The standard as written is mildly misleading, but the correct fix +is to deal with the underlying problem in the ctype_byname base class, +not in the specialization. See issue 228.
+ + + + +Section: 23.3.1 [map] Status: NAD Editorial + Submitter: Mark Mitchell Date: 1999-04-14
+View all other issues in [map].
+View all issues with NAD Editorial status.
+Discussion:
+++ +23.1 [container.requirements]
+
+
+ expression return type + pre/post-condition
+ ------------- ----------- + -------------------
+ X::value_type T + + T is assignable
+
+ 23.3.1 [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 assigned +to. So, map<Key, T>::value_type does not satisfy the +assignable requirement imposed by a container.
+ +[See issue 103 for the slightly related issue of +modification of set keys.]
+ + + +Rationale:
+The LWG believes that the standard is inconsistent, but that this +is a design problem rather than a strict defect. May wish to +reconsider for the next standard.
+ + + + +Section: D.5 [depr.c.headers] Status: NAD + Submitter: Christophe de Dinechin Date: 1999-05-04
+View all issues with NAD status.
+Discussion:
+[depr.c.headers] paragraph 2 reads:
+ ++ ++ +Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace 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 in +std...
+ +I don't know what is the correct wording. For instance, if struct +tm is defined in time.h, ctime declares std::tm. However, the current +wording seems ambiguous regarding which of the following would occur +for 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 also +agreed that version 1 is intended, version 2 is not equivalent to +version 1, and version 3 is clearly not intended. The example below +was constructed by Nathan Myers to illustrate why version 2 is not +equivalent to version 1.
+ +Although not equivalent, the LWG is unsure if (2) is enough of +a 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 D.5 [depr.c.headers] paragraph 2 with:
+ ++ ++ + + +Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace std by name.h and is followed by an explicit +using-declaration (_namespace.udecl_) in global scope.
+ +
Rationale:
+The current wording in the standard is the result of a difficult +compromise that averted delay of the standard. Based on discussions +in Tokyo it is clear that there is no still no consensus on stricter +wording, so the issue has been closed. It is suggested that users not +write code that depends on Koenig lookup of C library functions.
+ + + + +Section: 27.4.4.1 [basic.ios.cons] Status: NAD + Submitter: Angelika Langer Date: 1999-05-12
+View all other issues in [basic.ios.cons].
+View all issues with NAD status.
+Discussion:
+There is no initial value for the adjustfield defined, although +many people believe that the default adjustment were right. This is a +common misunderstanding. The standard only defines that, if no +adjustment is specified, all the predefined inserters must add fill +characters before the actual value, which is "as if" the +right flag were set. The flag itself need not be set.
+ +When you implement a user-defined inserter you cannot rely on right +being the default setting for the adjustfield. Instead, you must be +prepared to find none of the flags set and must keep in mind that in +this case you should make your inserter behave "as if" the +right flag were set. This is surprising to many people and complicates +matters more than necessary.
+ +Unless there is a good reason why the adjustfield should not be +initialized I would suggest to give it the default value that +everybody expects anyway.
+ + + +Rationale:
+This is not a defect. It is deliberate that the default is no bits +set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.
+ + + + +Section: 23.1.3 [sequence.reqmts] Status: NAD Future + Submitter: Andrew Koenig Date: 1999-06-28
+View all other issues in [sequence.reqmts].
+View all issues with NAD Future status.
+Discussion:
+Suppose that c and c1 are sequential containers and i is an +iterator that refers to an element of c. Then I can insert a copy of +c1's elements into c ahead of element i by executing
+ ++ ++ +c.insert(i, c1.begin(), c1.end());+ +
If c is a vector, it is fairly easy for me to find out where the +newly inserted elements are, even though i is now invalid:
+ ++ ++ +size_t i_loc = i - c.begin(); +c.insert(i, c1.begin(), c1.end());+ +
and now the first inserted element is at c.begin()+i_loc and one
+past the last is at c.begin()+i_loc+c1.size().
+
+But what if c is a list? I can still find the location of one past the
+last inserted element, because i is still valid. To find the location
+of the first inserted element, though, I must execute something like
+ ++ +for (size_t n = c1.size(); n; --n) + --i;+ +
because i is now no longer a random-access iterator.
+
+Alternatively, I might write something like
+ ++ +bool first = i == c.begin(); +list<T>::iterator j = i; +if (!first) --j; +c.insert(i, c1.begin(), c1.end()); +if (first) + j = c.begin(); +else + ++j;+ +
which, although wretched, requires less overhead.
+
+But I think the right solution is to change the definition of insert
+so that instead of returning void, it returns an iterator that refers
+to the first element inserted, if any, and otherwise is a copy of its
+first argument.
Rationale:
+The LWG believes this was an intentional design decision and so is +not a defect. It may be worth revisiting for the next standard.
+ + + + +Section: 27.4.2.5 [ios.base.storage] Status: Dup + Submitter: Dietmar Kühl Date: 1999-07-20
+View all other issues in [ios.base.storage].
+View all issues with Dup status.
+Duplicate of: 41
+Discussion:
+According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the +functions iword() and pword() "set the +badbit (which might throw an exception)" on +failure. ... but what does it mean for ios_base to set the +badbit? The state facilities of the IOStream library are +defined in basic_ios, a derived class! It would be possible +to attempt a down cast but then it would be necessary to know the +character type used...
+ + +Rationale:
+ + + + + +Section: 27.6.1.2.3 [istream::extractors] Status: Dup + Submitter: Dietmar Kühl Date: 1999-07-20
+View all other issues in [istream::extractors].
+View all issues with Dup status.
+Duplicate of: 60
+Discussion:
+It appears to be somewhat nonsensical to consider the functions +defined in the paragraphs 1 to 5 to be "Formatted input +function" but since these functions are defined in a section +labeled "Formatted input functions" it is unclear to me +whether these operators are considered formatted input functions which +have to conform to the "common requirements" from 27.6.1.2.1 +[istream.formatted.reqmts]: If this is the case, all manipulators, not +just +ws, would skip whitespace unless noskipws is set +(... but setting noskipws using the manipulator syntax would +also skip whitespace :-)
+ +See also issue 166 for the same problem in formatted +output
+ + +Rationale:
+ + + + + +Section: 27.6.1.3 [istream.unformatted] Status: Dup + Submitter: Dietmar Kühl Date: 1999-07-20
+View all other issues in [istream.unformatted].
+View all issues with Dup status.
+Duplicate of: 60
+Discussion:
+It is not clear which functions are to be considered unformatted +input functions. As written, it seems that all functions in 27.6.1.3 +[istream.unformatted] are unformatted input functions. However, it does +not +really make much sense to construct a sentry object for +gcount(), sync(), ... Also it is unclear what +happens to the gcount() if eg. gcount(), +putback(), unget(), or sync() is called: +These functions don't extract characters, some of them even +"unextract" a character. Should this still be reflected in +gcount()? Of course, it could be read as if after a call to +gcount() gcount() return 0 (the last +unformatted input function, gcount(), didn't extract any +character) and after a call to putback() gcount() +returns -1 (the last unformatted input function +putback() did "extract" back into the +stream). Correspondingly for unget(). Is this what is +intended? If so, this should be clarified. Otherwise, a corresponding +clarification should be used.
+ + +Rationale:
+ + + + + +Section: 27.6.2.6.3 [ostream.inserters] Status: Dup + Submitter: Dietmar Kühl Date: 1999-07-20
+View all issues with Dup status.
+Duplicate of: 60
+Discussion:
+From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions +defined in 27.6.2.6.3 [ostream.inserters] have to construct a +sentry object. Is this really intended?
+ +This is basically the same problem as issue 162 but +for output instead of input.
+ + +Rationale:
+ + + + + +Section: 26.3.6 [complex.ops] Status: NAD + Submitter: Judy Ward Date: 1999-07-02
+View all other issues in [complex.ops].
+View all issues with NAD status.
+Discussion:
+A user who tries to explicitly instantiate a complex non-member operator will +get compilation errors. Below is a simplified example of the reason why. The +problem is that iterator_traits cannot be instantiated on a non-pointer type +like float, yet when the compiler is trying to decide which operator+ needs to +be instantiated it must instantiate the declaration to figure out the first +argument 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 instantiation
+template 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 will +work. Users are not affected in any case.
According to John +Spicer, It is possible to explicitly instantiate these operators using +different syntax: change "std::operator+<float>" to +"std::operator+".
+ +The proposed resolution of issue 120 is that users will not be able +to explicitly instantiate standard library templates. If that +resolution is accepted then library implementors will be the only ones +that will be affected by this problem, and they must use the indicated +syntax.
+ + + + +Section: 27.3.1 [narrow.stream.objects] Status: NAD + Submitter: Judy Ward Date: 1999-07-02
+View all other issues in [narrow.stream.objects].
+View all issues with NAD status.
+Discussion:
++Section 27.3.1 says "After the object cerr is initialized, +cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as +required for ios_base::init (lib.basic.ios.cons). It doesn't say +anything about the the state of clog. So this means that calling +cerr.tie() and clog.tie() should return 0 (see Table 89 for +ios_base::init effects). +
++Neither of the popular standard library implementations +that I tried does this, they both tie cerr and clog +to &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 for +ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the +postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct +ios_base::init to basic_ios::init().)
+ + + + +Section: 26.5.2.6 [valarray.cassign] Status: NAD + Submitter: Gabriel Dos Reis Date: 1999-08-15
+View all issues with NAD status.
+Discussion:
+26.5.2.6 defines augmented assignment operators +valarray<T>::op=(const T&), but fails to provide +corresponding versions for the helper classes. Thus making the +following illegal:
+
+#include <valarray>
+
+int main()
+{
+std::valarray<double> v(3.14, 1999);
+
+v[99] *= 2.0; // Ok
+
+std::slice s(0, 50, 2);
+
+v[s] *= 2.0; // ERROR
+}
+
+I can't understand the intent of that omission. It makes the +valarray library less intuitive and less useful.
+ + +Rationale:
+Although perhaps an unfortunate +design decision, the omission is not a defect in the current +standard. A future standard may wish to add the missing +operators.
+ + + + +Section: 25.3.3 [alg.binary.search] Status: NAD + Submitter: Nico Josuttis Date: 1999-10-10
+View all other issues in [alg.binary.search].
+View all issues with NAD status.
+Discussion:
+The complexity of binary_search() is stated as "At most
+log(last-first) + 2 comparisons", which seems to say that the
+algorithm has logarithmic complexity. However, this algorithms is
+defined for forward iterators. And for forward iterators, the need to
+step element-by-element results into linear complexity. But such a
+statement is missing in the standard. The same applies to
+lower_bound(), upper_bound(), and equal_range().
+
+However, strictly speaking the standard contains no bug here. So this
+might considered to be a clarification or improvement.
+
Rationale:
+The complexity is expressed in terms of comparisons, and that +complexity can be met even if the number of iterators accessed is +linear. Paragraph 1 already says exactly what happens to +iterators.
+ + + + +Section: 23.1.4 [associative.reqmts] Status: NAD + Submitter: Ed Brey Date: 1999-06-06
+View all other issues in [associative.reqmts].
+View all issues with NAD status.
+Duplicate of: 233
+Discussion:
+As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from +several 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 is +guaranteed if no element is inserted, even though constant complexity is always +possible if p points to an element equivalent to t.
+2. For a container with equivalent keys, the amortized constant complexity +guarantee 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 one +of which would not be right after p.
+3. By guaranteeing amortized constant complexity only when t is inserted +after p, it is impossible to guarantee constant complexity if t is inserted at +the beginning of the container. Such a problem would not exist if amortized +constant complexity was guaranteed if t is inserted before p, since there is +always some p immediately before which an insert can take place.
+4. For a container with equivalent keys, p does not allow specification of +where to insert the element, but rather only acts as a hint for improving +performance. This negates the added functionality that p would provide if it +specified where within a sequence of equivalent keys the insertion should occur. +Specifying the insert location provides more control to the user, while +providing no disadvantage to the container implementation.
+ + +Proposed resolution:
+In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 +for 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 checking +both before p and after p, and don't want to change this behavior.
+ + + + + +Section: 27.4.4 [ios] Status: NAD + Submitter: Steve Clamage Date: 1999-09-07
+View all issues with NAD status.
+Discussion:
+In classic iostreams, base class ios had an rdbuf function that returned a +pointer to the associated streambuf. Each derived class had its own rdbuf +function that returned a pointer of a type reflecting the actual type derived +from streambuf. Because in ARM C++, virtual function overrides had to have the +same return type, rdbuf could not be virtual.
+In standard iostreams, we retain the non-virtual rdbuf function design, and +in 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 in +derived classes.
+Minor question: Was there a specific reason not to make the original rdbuf +function virtual?
+Major problem: Friendly compilers warn about functions in derived classes +that hide base-class overloads. Any standard implementation of iostreams will +result in such a warning on each of the iostream classes, because of the +ill-considered decision to overload rdbuf only in a base class.
+In addition, users of the second rdbuf function must use explicit +qualification or a cast to call it from derived classes. An explicit +qualification or cast to basic_ios would prevent access to any later overriding +version if there was one.
+What I'd like to do in an implementation is add a using- declaration for the +second rdbuf function in each derived class. It would eliminate warnings about +hiding functions, and would enable access without using explicit qualification. +Such a change I don't think would change the behavior of any valid program, but +would 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 to +require the equivalent of a using-declaration for the rdbuf function that is not +replaced in a later derived class. We could discuss whether replacing the +function should be allowed.
+ + +Rationale:
+For historical reasons, the standard is correct as written. There is a subtle difference between the base +class rdbuf() and derived class rdbuf(). The derived +class 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 +17.4.4.4 [member.functions].
+ + + + +Section: 18.5.1.3 [new.delete.placement] Status: Dup + Submitter: Herb Sutter Date: 1998-12-15
+View all other issues in [new.delete.placement].
+View all issues with Dup status.
+Duplicate of: 114
+Discussion:
+The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads:
+ ++ ++ +[Example: This can be useful for constructing an object at a known address:
+ +
+
+ char place[sizeof(Something)];
+ Something* p = new (place) Something();
+
+end example]
This example has potential alignment problems.
+ + +Rationale:
+ + + + + +Section: 20.1.2 [allocator.requirements], 23.1 [container.requirements] Status: NAD + Submitter: Andy Sawyer Date: 1999-10-21
+View other active issues in [allocator.requirements].
+View all other issues in [allocator.requirements].
+View all issues with NAD 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 "best
+case" conditions - i.e. assume the run-time platform is "configured to
+the max", and no overhead from the program itself. This may possibly
+be determined at the point the library is written, but certainly no
+later than compile time.
+
+2) The largest container the program could create, given "best case"
+conditions - i.e. same platform assumptions as (1), but take into
+account any overhead for executing the program itself. (or, roughly
+"storage=storage-sizeof(program)"). This does NOT include any resource
+allocated by the program. This may (or may not) be determinable at
+compile time.
+
+3) The largest container the current execution of the program could
+create, given knowledge of the actual run-time platform, but again,
+not taking into account any currently allocated resource. This is
+probably best determined at program start-up.
+
+4) The largest container the current execution program could create at
+the point max_size() is called (or more correctly at the point
+max_size() returns :-), given it's current environment (i.e. taking
+into account the actual currently available resources). This,
+obviously, has to be determined dynamically each time max_size() is
+called.
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: 27.6.1.1.3 [istream::sentry] Status: NAD + Submitter: Matt McClure and Dietmar Kühl Date: 2000-01-01
+View all other issues in [istream::sentry].
+View all issues with NAD 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 to +provide specializations for ctype<char> and +ctype<wchar_t>. If sentry's constructor is implemented using +ctype, it will be uninstantiable for a user-defined character type +charT, unless the implementation has provided non-working (since it +would be impossible to define a correct ctype<charT> specialization +for an arbitrary charT) definitions of ctype's virtual member +functions.
+ ++It seems the intent the standard is that sentry should behave, in +every respect, not just during execution, as if it were implemented +using ctype, with the burden of providing a ctype specialization +falling on the user. But as it is written, nothing requires the +translation of sentry's constructor to behave as if it used the above +code, and it would seem therefore, that sentry's constructor should be +instantiable for all character types. +
+ ++Note: If I have misinterpreted the intent of the standard with +respect to sentry's constructor's instantiability, then a note should +be added to the following effect: +
+ ++ ++An implementation is forbidden from using the above code if it renders +the constructor uninstantiable for an otherwise valid character +type. +
In any event, some clarification is needed.
+ + + +Rationale:
+It is possible but not easy to instantiate on types other than char +or wchar_t; many things have to be done first. That is by intention +and is not a defect.
+ + + + +Section: 24.3.4 [iterator.operations] Status: NAD + Submitter: Rintala Matti Date: 2000-01-28
+View all issues with NAD status.
+Discussion:
+Section 24.3.4 describes the function distance(first, last) (where first and +last are iterators) which calculates "the number of increments or +decrements needed to get from 'first' to 'last'".
+The function should work for forward, bidirectional and random access +iterators, 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 implemented +if the implementation does not know which of the iterators points to an earlier +position (you cannot use ++ or -- on either iterator if you don't know which +direction is the "safe way to travel").
+The paragraph 24.3.4.1 states that "for ... bidirectional iterators they +use ++ to provide linear time implementations". However, the ++ operator is +not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly +mentions that distance() returns the number of increments _or decrements_, +suggesting that it could return a negative number also for bidirectional +iterators when 'last' points to a position before 'first'.
+Is a further requirement is needed to state that for forward and +bidirectional iterators "'last' must be reachable from 'first' using the ++ +operator". Maybe this requirement might also apply to random access +iterators so that distance() would work the same way for every iterator +category?
+ + +Rationale:
+"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6. +The definition is only in terms of operator++(). The LWG sees no defect in +the standard.
+ + + + +Section: 18.2.1.2 [numeric.limits.members] Status: NAD + Submitter: Steve Cleary Date: 2000-01-28
+View all other issues in [numeric.limits.members].
+View all issues with NAD status.
+Discussion:
+In several places in 18.2.1.2 [numeric.limits.members], a member is +described as "Meaningful for all floating point types." +However, no clear method of determining a floating point type is +provided.
+ +In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for +example, epsilon() is only meaningful if is_integer is +false). . ." which suggests that a type is a floating point type +if is_specialized is true and is_integer is false; however, this is +unclear.
+ +When clarifying this, please keep in mind this need of users: what +exactly is the definition of floating point? Would a fixed point or +rational representation be considered one? I guess my statement here +is 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 a +floating point type.
+ + + + +Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup + Submitter: Robert Klarer Date: 1999-11-02
+View all other issues in [facet.ctype.char.members].
+View all issues with Dup status.
+Duplicate of: 153
+Discussion:
++The widen and narrow member functions are described +in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded +signatures followed by a Returns clause. The Returns +clause only describes one of the overloads. +
+ + +Proposed resolution:
+Change the returns clause in 22.2.1.3.2 [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 22.2.1.3.2 [facet.ctype.char.members] paragraph 11 +from:
+Returns: do_narrow(low, high, to).
+ +to:
+Returns: do_narrow(c) or do_narrow(low, high, to), +respectively.
+ + +Rationale:
+Subsumed by issue 153, which addresses the same +paragraphs.
+ + + + + + +Section: 26.7 [c.math] Status: NAD + Submitter: Nico Josuttis Date: 2000-02-26
+View all other issues in [c.math].
+View all issues with NAD status.
+Discussion:
+Due to the additional overloaded versions of numeric functions for +float and long double according to Section 26.5, calls such as int x; +std::pow (x, 4) are ambiguous now in a standard conforming +implementation. Current implementations solve this problem very +different (overload for all types, don't overload for float and long +double, use preprocessor, follow the standard and get +ambiguities).
This behavior should be standardized or at least +identified as implementation defined.
+ + +Rationale:
+These math issues are an +understood and accepted consequence of the design. They have +been discussed several times in the past. Users must write casts +or write floating point expressions as arguments.
+ + + + +Section: 23.1.4 [associative.reqmts] Status: NAD + Submitter: Judy Ward Date: 2000-02-29
+View all other issues in [associative.reqmts].
+View all issues with NAD status.
+Discussion:
+A user noticed that this doesn't compile with the Rogue Wave library because +the rb_tree class declares a key_allocator, and allocator<const int> is +not legal, I think:
+++map < const int, ... > // legal?+
which made me wonder whether it is legal for a map's key_type to be const. In +email from Matt Austern he said:
+++ + +I'm not sure whether it's legal to declare a map with a const key type. I +hadn't thought about that question until a couple weeks ago. My intuitive +feeling is that it ought not to be allowed, and that the standard ought to say +so. It does turn out to work in SGI's library, though, and someone in the +compiler group even used it. Perhaps this deserves to be written up as an issue +too.
+
Rationale:
+The "key is assignable" requirement from table 69 in +23.1.4 [associative.reqmts] already implies the key cannot be const.
+ + + + +Section: 27.6.3 [std.manip] Status: Dup + Submitter: Hyman Rosen Date: 2000-02-29
+View all other issues in [std.manip].
+View all issues with Dup status.
+Duplicate of: 193
+Discussion:
+27.6.3 [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 behaves +as if f(s) were called, in is an (instance of) basic_istream then the +expression in>>s behaves as if f(s) were called. Where f can be +defined 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 the +description 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 if +the 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 "Where +f" sentence fragment needs to be merged into its preceding sentence. You +may also want to format the function a little better. The formatting above is +more-or-less what the Standard contains.
+ + +Rationale:
+The resolution of this defect is subsumed by the proposed resolution for +issue 193.
+ +[Tokyo: The LWG agrees that this is a defect and notes that it +occurs additional places in the section, all requiring fixes.]
+ + + + + + + + +Section: 25.3 [alg.sorting] Status: NAD + Submitter: Pablo Halpern Date: 2000-03-06
+View all other issues in [alg.sorting].
+View all issues with NAD status.
+Discussion:
+Many of the algorithms take an argument, pred, of template parameter type +BinaryPredicate or an argument comp of template parameter type Compare. These +algorithms usually have an overloaded version that does not take the predicate +argument. In these cases pred is usually replaced by the use of operator== and +comp is replaced by the use of operator<.
+This use of hard-coded operators is inconsistent with other parts of the +library, particularly the containers library, where equality is established +using equal_to<> and ordering is established using less<>. Worse, +the use of operator<, would cause the following innocent-looking code to have +undefined behavior:
+++vector<string*> vec; +sort(vec.begin(), vec.end());+
The use of operator< is not defined for pointers to unrelated objects. If +std::sort used less<> to compare elements, then the above code would be +well-defined, since less<> is explicitly specialized to produce a total +ordering of pointers.
+ + +Rationale:
+This use of operator== and operator< was a very deliberate, conscious, and +explicitly made design decision; these operators are often more efficient. The +predicate forms are available for users who don't want to rely on operator== and +operator<.
+ + + + +Section: 25.1.5 [alg.find] Status: NAD Future + Submitter: Pablo Halpern Date: 2000-03-06
+View all other issues in [alg.find].
+View all issues with NAD Future status.
+Discussion:
+The find function always searches for a value using operator== to compare the +value argument to each element in the input iterator range. This is inconsistent +with other find-related functions such as find_end and find_first_of, which +allow the caller to specify a binary predicate object to be used for determining +equality. The fact that this can be accomplished using a combination of find_if +and bind_1st or bind_2nd does not negate the desirability of a consistent, +simple, alternative interface to find.
+ + +Proposed resolution:
+++ + +In section 25.1.5 [alg.find], add a second prototype for find +(between the existing prototype and the prototype for find_if), as +follows:
+template<class InputIterator, class T, class BinaryPredicate> + InputIterator find(InputIterator first, InputIterator last, + const T& value, BinaryPredicate bin_pred);+Change the description of the return from:
+++Returns: The first iterator i in the range [first, last) for which the following corresponding + conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.
+to:
+++Returns: The first iterator i in the range [first, last) for which the following + corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) + != false. Return last if no such iterator is found.
+
Rationale:
+This is request for a pure extension, so it is not a defect in the +current standard. As the submitter pointed out, "this can +be accomplished using a combination of find_if and bind_1st or +bind_2nd".
+ + + + +Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup + Submitter: Dietmar Kühl Date: 2000-04-24
+View all other issues in [facet.ctype.char.members].
+View all issues with Dup status.
+Duplicate of: 28
+Discussion:
+The description of the is() member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the +second form of the is() method modifies the masks in the +ctype object. The correct semantics if, of course, to obtain +an array of masks. The corresponding method in the general case, +ie. the do_is() method as described in 22.2.1.1.2 [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:
+ + + + + +Section: 25.1.5 [alg.find] Status: NAD + Submitter: Andrew Koenig Date: 2000-05-02
+View all other issues in [alg.find].
+View all issues with NAD status.
+Discussion:
+Is the following implementation of find 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 to +whether 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 argument +of find be CopyConstructible. There may be no problem here, but +analysis is necessary.
+ + +Rationale:
+There is no indication in the standard that find's third argument +is required to be Copy Constructible. The LWG believes that no such +requirement was intended. As noted above, there are times when a user +might reasonably pass an argument that is not Copy Constructible.
+ + + + +Section: 24.5.1 [istream.iterator] Status: NAD + Submitter: Andrew Koenig Date: 2000-05-02
+View other active issues in [istream.iterator].
+View all other issues in [istream.iterator].
+View all issues with NAD status.
+Discussion:
+I do not think the standard specifies what operation(s) on istream +iterators 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 read +from 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 time +operator++ is called, and it is also read either when the iterator is +constructed or when operator* is called for the first time. In the +example above, exactly two integers are read from cin.
+ +There may be a problem with the interaction between istream_iterator +and some STL algorithms, such as find. There are no guarantees about +how many times find may invoke operator++.
+ + + + +Section: 23.1.4 [associative.reqmts] Status: Dup + Submitter: Mark Rodgers Date: 2000-05-19
+View all other issues in [associative.reqmts].
+View all issues with Dup status.
+Duplicate of: 233
+Discussion:
+Closed issue 192 raised several problems with the specification of +this function, but was rejected as Not A Defect because it was too big +a change with unacceptable impacts on existing implementations. +However, issues remain that could be addressed with a smaller change +and 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 + immediately before 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, make +the 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:
+ + + + + +Section: D.9.1 [auto.ptr] Status: NAD + Submitter: Joseph Gottman Date: 2000-06-30
+View all other issues in [auto.ptr].
+View all issues with NAD status.
+Discussion:
+According to section 20.4.5, the function +auto_ptr::operator=() returns a reference to an auto_ptr. +The reason that operator=() usually returns a reference is to +facilitate code like
+ +int x,y,z; + x = y = z = 1; ++ +
However, given analogous code for auto_ptrs,
+auto_ptr<int> x, y, z; + z.reset(new int(1)); + x = y = z; ++ +
the result would be that z and y would both be set to +NULL, instead of all the auto_ptrs being set to the same value. +This makes such cascading assignments useless and counterintuitive for +auto_ptrs.
+ + +Proposed resolution:
+Change auto_ptr::operator=() to return void instead +of an auto_ptr reference.
+ + +Rationale:
+The return value has uses other than cascaded assignments: a user can +call an auto_ptr member function, pass the auto_ptr to a +function, etc. Removing the return value could break working user +code.
+ + + + +Section: 20.6.3 [base], 24.3.2 [iterator.basic] Status: NAD + Submitter: Robert Dick Date: 2000-08-17
+View all other issues in [base].
+View all issues with NAD status.
+Discussion:
++According to the November 1997 Draft Standard, the results of deleting an +object of a derived class through a pointer to an object of its base class are +undefined if the base class has a non-virtual destructor. Therefore, it is +potentially dangerous to publicly inherit from such base classes. +
+ +Defect:
+
+The STL design encourages users to publicly inherit from a number of classes
+which do nothing but specify interfaces, and which contain non-virtual
+destructors.
+
Attribution:
+
+Wil Evers and William E. Kempf suggested this modification for functional
+objects.
+
Proposed resolution:
++When a base class in the standard library is useful only as an interface +specifier, i.e., when an object of the class will never be directly +instantiated, specify that the class contains a protected destructor. This +will 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 a +defect in the strict sense. The LWG had several different objections +to the proposed change. One is that it would prevent users from +creating objects of type unary_function and +binary_function. Doing so can sometimes be legitimate, if users +want to pass temporaries as traits or tag types in generic code. +
+ + + + + +Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD + Submitter: Martin Sebor Date: 2000-10-05
+View all other issues in [depr.strstreambuf.virtuals].
+View all issues with NAD status.
+Discussion:
++It appears that the interaction of the strstreambuf members overflow() +and seekoff() can lead to undefined behavior in cases where defined +behavior could reasonably be expected. The following program +demonstrates 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) calls +overflow(traits::to_int_type(c)) if a write position isn't available (it +isn't due to the above). +
+ ++D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at +least one write position available (i.e., it allows the function to make +any positive number of write positions available). +
+ ++D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see +seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this +case. newoff is then epptr() - eback(). +
+ ++D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or +gptr() == epptr() + off holds. +
+ ++If strstreambuf::overflow() made exactly one write position available +then gptr() will be set to just before epptr(), and the program will +return 0. Buf if the function made more than one write position +available, epptr() and gptr() will both point past pptr() and the +behavior of the program is undefined. +
+ + +Proposed resolution:
+ + +Change the last sentence of D.7.1 [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 issue 65: it's not clear what it +means to seek beyond the current area. Without resolving issue 65 we can't resolve this. As with issue 65, +the library working group does not wish to invest time nailing down +corner cases in a deprecated feature.
+ + + + + +Section: 18.7 [support.exception] Status: NAD + Submitter: J. Stephen Adamczyk Date: 2000-10-10
+View all other issues in [support.exception].
+View all issues with NAD 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 final +parameter before the "..." is unnamed. cstdarg is, as far +as I can tell, inherited verbatim from the C standard. and the +definition there (7.8.1.1 in the ISO C89 standard) refers to "the +identifier of the rightmost parameter". What happens when there +is no such identifier? +
+ ++My personal opinion is that this should be allowed, but some tweak +might be required in the C++ standard. +
+ + +Rationale:
++Not a defect, the C and C++ standards are clear. It is impossible to +use varargs if the parameter immediately before "..." has no +name, because that is the parameter that must be passed to va_start. +The example given above is broken, because va_start is being passed +the wrong parameter. +
+ ++There is no support for extending varargs to provide additional +functionality beyond what's currently there. For reasons of C/C++ +compatibility, it is especially important not to make gratuitous +changes in this part of the C++ standard. The C committee has already +been requested not to touch this part of the C standard unless +necessary. +
+ + + + +Section: 20.1.2 [allocator.requirements] Status: NAD + Submitter: Matt Austern Date: 2000-11-07
+View other active issues in [allocator.requirements].
+View all other issues in [allocator.requirements].
+View all issues with NAD status.
+Discussion:
++In 20.1.5, paragraph 5, the standard says that "Implementors are +encouraged to supply libraries that can accept allocators that +encapsulate more general memory models and that support non-equal +instances." This is intended as normative encouragement to +standard library implementors. However, it is possible to interpret +this 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 International +Standard". +
+ + +Rationale:
+The LWG believes the normative encouragement is already +sufficiently clear, and that there are no important consequences +even if it is misunderstood.
+ + + + + +Section: 23.1 [container.requirements] Status: NAD + Submitter: Steve Cleary Date: 2000-11-27
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with NAD status.
+Discussion:
+ ++This came from an email from Steve Cleary to Fergus in reference to +issue 179. The library working group briefly discussed +this in Toronto and believes it should be a separate issue. +
+ ++Steve said: "We may want to state that the const/non-const iterators must have +the same difference type, size_type, and category." +
+ ++(Comment from Judy) +I'm not sure if the above sentence should be true for all +const and non-const iterators in a particular container, or if it means +the container's iterator can't be compared with the container's +const_iterator unless the above it true. I suspect the former. +
+ + +Proposed resolution:
++In Section: 23.1 [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 a +size_type. We already know that the difference types are +identical, because the container requirements already say that the +difference types of both X::iterator and X::const_iterator are both +X::difference_type. The standard does not require that X::iterator +and X::const_iterator have the same iterator category, but the LWG +does not see this as a defect: it's possible to imagine cases in which +it would be useful for the categories to be different.
+ +It may be desirable to require X::iterator and X::const_iterator to +have the same value type, but that is a new issue. (Issue 322.)
+ + + + + + +Section: 27.4.2.2 [fmtflags.state] Status: NAD + Submitter: Judy Ward Date: 2000-12-30
+View all other issues in [fmtflags.state].
+View all issues with NAD status.
+Discussion:
++The Effects clause for ios_base::setf(fmtflags fmtfl) says +"Sets fmtfl in flags()". What happens if the user first calls +ios_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::left +and 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_base +constructor says that each ios_base member has an indeterminate value +after construction, all the existing implementations I tried explicitly set +ios_base::dec. +
+ + +Proposed resolution:
+ + +Rationale:
++adjustfield, basefield, and floatfield +are each multi-bit fields. It is possible to set multiple bits within +each of those fields. (For example, dec and +oct). These fields are used by locale facets. The LWG +reviewed the way in which each of those three fields is used, and +believes that in each case the behavior is well defined for any +possible combination of bits. See for example Table 58, in 22.2.2.2.2 +[facet.num.put.virtuals], noting the requirement in paragraph 6 of that +section. +
++Users are advised to use manipulators, or else use the two-argument +version of setf, to avoid unexpected behavior. +
+ + + + + +Section: 26.7 [c.math] Status: NAD + Submitter: Judy Ward Date: 2000-12-30
+View all other issues in [c.math].
+View all issues with NAD 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 the +C++ 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 functions +are optional and, if supplied, should match the description in +the 1999 version of the C standard. In the next round +of C++ standardization they can then become mandatory. +
+ + +Rationale:
+The C90 standard, as amended, already permits (but does not +require) these functions, and the C++ standard incorporates the +C90 standard by reference. C99 is not an issue, because it is +never referred to by the C++ standard.
+ + + + + +Section: 25.2.4 [alg.transform] Status: NAD + Submitter: Angelika Langer Date: 2001-01-04
+View all other issues in [alg.transform].
+View all issues with NAD status.
+Discussion:
+This issue is related to issue 242. In case that the resolution +proposed for issue 242 is accepted, we have have the following +situation: The 4 numeric algorithms (accumulate and consorts) as well +as transform would allow a certain category of side effects. The +numeric algorithms specify that they invoke the functor "for +every iterator i in the range [first, last) in order". transform, +in contrast, would not give any guarantee regarding order of +invocation of the functor, which means that the functor can be invoked +in any arbitrary order. +
+ +Why would that be a problem? Consider an example: say the +transformator that is a simple enumerator ( or more generally +speaking, "is order-sensitive" ). Since a standard +compliant implementation of transform is free to invoke the enumerator +in no definite order, the result could be a garbled enumeration. +Strictly speaking this is not a problem, but it is certainly at odds +with the prevalent understanding of transform as an algorithms that +assigns "a new _corresponding_ value" to the output +elements. +
+ +All implementations that I know of invoke the transformator in +definite order, namely starting from first and proceeding to last - +1. Unless there is an optimization conceivable that takes advantage of +the indefinite order I would suggest to specify the order, because it +eliminate the uncertainty that users would otherwise have regarding +the order of execution of their potentially order-sensitive function +objects. +
+ + +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 corresponding +value 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 through +every iterator i in the range [result, result + (last1 - first1)) a new +corresponding +value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + +(i - result), *(first2 + (i - result))). +
Rationale:
+For Input Iterators an order is already guaranteed, because +only one order is possible. If a user who passes a Forward +Iterator to one of these algorithms really needs a specific +order of execution, it's possible to achieve that effect by +wrapping it in an Input Iterator adaptor.
+ + + + + +Section: 20.2.3 [pairs] Status: NAD + Submitter: Martin Sebor Date: 2001-01-14
+View all other issues in [pairs].
+View all issues with NAD status.
+Discussion:
+The synopsis of the header <utility> in 20.2 [utility] +lists the complete set of equality and relational operators for pair +but the section describing the template and the operators only describes +operator==() and operator<(), and it fails to mention +any requirements on the template arguments. The remaining operators are +not mentioned at all. +
+ + +Rationale:
+20.2.1 [operators] paragraph 10 already specifies the semantics. +That paragraph says that, if declarations of operator!=, operator>, +operator<=, and operator>= appear without definitions, they are +defined as specified in 20.2.1 [operators]. There should be no user +confusion, since that paragraph happens to immediately precede the +specification of pair.
+ + + + + +Section: 22.2.1.5 [locale.codecvt.byname] Status: NAD + Submitter: Gregory Bumgardner Date: 2001-01-25
+View all other issues in [locale.codecvt.byname].
+View all issues with NAD status.
+Discussion:
++The effects of codecvt<>::do_length() are described in +22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified +in issue 75, codecvt<>::do_length() must +process the source data and update the stateT argument just +as if the data had been processed by codecvt<>::in(). +However, the standard does not specify how do_length() would +report a translation failure, should the source sequence contain +untranslatable or illegal character sequences. +
+ ++The other conversion methods return an "error" result value +to indicate that an untranslatable character has been encountered, but +do_length() already has a return value (the number of source +characters that have been processed by the method). +
+ + +Proposed resolution:
++This issue cannot be resolved without modifying the interface. An exception +cannot be used, as there would be no way to determine how many characters +have been processed and the state object would be left in an indeterminate +state. +
+ ++A source compatible solution involves adding a fifth argument to length() +and do_length() that could be used to return position of the offending +character sequence. This argument would have a default value that would +allow 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 and +the from_next argument, if used, could then be used to retrieve the +location 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 of +external characters, it stops.
+ + + + + +Section: 24.1 [iterator.requirements] Status: NAD + Submitter: Dave Abrahams Date: 2001-02-05
+View other active issues in [iterator.requirements].
+View all other issues in [iterator.requirements].
+View all issues with NAD status.
+Discussion:
++We all "know" that input iterators are allowed to produce +values 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 be +the 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 reference +type, but since operator->() must return a pointer for +a->m to be well-formed, it needs something to return a +pointer to. This seems to indicate that *a must be +buffered 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: 18.7.3.3 [terminate] Status: NAD + Submitter: Judy Ward Date: 2001-04-03
+View all other issues in [terminate].
+View all issues with NAD status.
+Discussion:
++According to section 18.7.3.3 of the standard, std::terminate() is +supposed to call the terminate_handler in effect immediately after +evaluating the throw expression. +
+ ++Question: what if the terminate_handler in effect is itself +std::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 terminate +handler to terminate are explicitly asking for terminate +to call itself.
+ + + + + +Section: 18.7.3.3 [terminate] Status: NAD + Submitter: Detlef Vollmann Date: 2001-04-11
+View all other issues in [terminate].
+View all issues with NAD status.
+Discussion:
+ ++The standard appears to contradict itself about whether the stack is +unwound 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 library +clauses; nothing in the core clauses says that stack unwinding happens +after terminate is called. 18.7.3.3p2 does not say anything +about when terminate() is called; it merely specifies which +terminate_handler is used.
+ + + + + +Section: 26.7 [c.math] Status: NAD + Submitter: Dave Abrahams Date: 2001-06-04
+View all other issues in [c.math].
+View all issues with NAD status.
+Discussion:
+Currently the standard mandates the following overloads of +abs():
+ +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 function +that works on "implicitly inter-convertible" types is dangerous in +practice. The headers that get included at any point in a translation +unit can change unpredictably during program +development/maintenance. The wrong overload might be unintentionally +selected. +
+ ++Currently, there is nothing that mandates the simultaneous visibility +of these overloads. Indeed, some vendors have begun fastidiously +reducing dependencies among their (public) headers as a QOI issue: it +helps people to write portable code by refusing to compile unless all +the correct headers are #included. +
+ +The same issue may exist for other functions in the library.
+ +Redmond: PJP reports that C99 adds two new kinds of abs: complex, +and int_max_abs.
+ +Related issue: 343.
+ +[ +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 to long and + to float. If x is a value of such a class, then + abs(x) would give the long version if the user + included <cstdlib>, the float 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: 22.2.6.4 [locale.moneypunct.byname] Status: NAD + Submitter: Martin Sebor Date: 2001-07-05
+View all issues with NAD status.
+Discussion:
+The definition of the moneypunct facet contains the typedefs char_type +and string_type. Only one of these names, string_type, is defined in +the derived facet, moneypunct_byname.
+ + +Proposed resolution:
+For consistency with the numpunct facet, add a typedef for +char_type to the definition of the moneypunct_byname facet in +22.2.6.4 [locale.moneypunct.byname].
+ + +Rationale:
+The absence of the typedef is irrelevant. Users can still access +the typedef, because it is inherited from the base class.
+ + + + + +Section: 22.1.1 [locale] Status: NAD + Submitter: Martin Sebor Date: 2001-07-15
+View all other issues in [locale].
+View all issues with NAD status.
+Discussion:
++The "exposition only" value of the std::locale::none constant shown in +the definition of class locale is misleading in that it on many +systems conflicts with the value assigned to one if the LC_XXX +constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE +on Linux and SunOS). This causes incorrect behavior when such a +constant is passed to one of the locale member functions that accept a +locale::category argument and interpret it as either the C LC_XXX +constant or a bitmap of locale::category values. At least three major +implementations adopt the suggested value without a change and +consequently suffer from this problem. +
+ ++For instance, the following code will (presumably) incorrectly copy facets +belonging 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 member +functions in such a way that they can take either category +arguments or the LC_ constants defined in <cctype>. In light of +this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light +of the requirement in the preceding paragraph that it is possible to +combine category bitmask elements with bitwise operations, +defining the category elements is delicate, +particularly if an implementor is constrained to work with a +preexisting C library. (Just using the existing LC_ constants would +not work in general.) There's no set of "exposition only" values that +could give library implementors proper guidance in such a delicate +matter. The non-normative example we're giving is no worse than +any other choice would be.
+ +See issue 347.
+ + + + + +Section: 27.4.3 [fpos] Status: NAD + Submitter: PremAnand M. Rao Date: 2001-08-27
+View all other issues in [fpos].
+View all issues with NAD status.
+Discussion:
++Increment and decrement operators are missing from +Table 88 -- Position type requirements in 27.4.3 [fpos]. +
+ + +Proposed resolution:
++Table 88 (section 27.4.3) -- Position type requirements +be 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 defect +report. Additionally, nobody saw a clear need for this extension; +fpos is used only in very limited ways.
+ + + + + +Section: 22.2.2 [category.numeric] Status: NAD + Submitter: Howard Hinnant Date: 2001-10-13
+View all issues with NAD 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 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last +sentence: +
++ ++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 it +matters. This is an obscure corner case, since grouping is usually +intended for the benefit of humans and oct/hex prefixes are usually +intended for the benefit of machines. There is not a strong enough +consensus in the LWG for action. +
+ + + + +Section: 20.2.3 [pairs] Status: Dup + Submitter: Andy Sawyer Date: 2001-10-23
+View all other issues in [pairs].
+View all issues with Dup status.
+Duplicate of: 532
+Discussion:
+ + ++The current wording of 20.2.2 [lib.pairs] p6 precludes the use of +operator< on any pair type which contains a pointer. +
+ + +Proposed resolution:
+In 20.2.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 need some ordering without caring much + which ordering it is. Another example of the later is typeinfo's + before.
+ + + + + + +Section: 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup + Submitter: Nathan Myers Date: 2001-10-25
+View all other issues in [allocator.members].
+View all issues with Dup status.
+Duplicate of: 634
+Discussion:
+See c++std-lib-9006 and c++std-lib-9007. This issue is taken +verbatim 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 result +is that many library facilities fail for legal user code, such as +the 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) specifies +no 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) and +a.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 type +is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that +includes the requirement that &t return the usual types and +values. Since allocators are intended to be used in conjunction with +containers, and since the CopyConstructible requirements appear to +have been written to deal with the concerns of this issue, the LWG +feels it is NAD unless someone can come up with a well-formed example +exhibiting 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: 20.6 [function.objects] Status: NAD Editorial + Submitter: Dale Riley Date: 2001-11-12
+View all other issues in [function.objects].
+View all issues with NAD Editorial status.
+Discussion:
++In 20.6 [function.objects] the header <functional> synopsis declares +the unary_negate and binary_negate function objects as struct. +However in 20.6.10 [negators] the unary_negate and binary_negate +function objects are defined as class. Given the context, they are +not "basic function objects" like negate, so this is either a typo or +an editorial oversight. +
+ +[Taken from comp.std.c++]
+ + + +Proposed resolution:
+Change the synopsis to reflect the useage in 20.6.10 [negators]
+ +[Curaçao: Since the language permits "struct", the LWG +views this as NAD. They suggest, however, that the Project Editor +might wish to make the change as editorial.]
+ + + + + + + +Section: 20.2.3 [pairs] Status: NAD Editorial + Submitter: Martin Sebor Date: 2001-12-02
+View all other issues in [pairs].
+View all issues with NAD Editorial status.
+Discussion:
++The class template std::pair defines a template ctor (20.2.2, p4) but +no template assignment operator. This may lead to inefficient code since +assigning an object of pair<C, D> to pair<A, B> +where the types C and D are distinct from but convertible to +A and B, respectively, results in a call to the template copy +ctor to construct an unnamed temporary of type pair<A, B> +followed by an ordinary (perhaps implicitly defined) assignment operator, +instead of just a straight assignment. +
+ + +Proposed resolution:
++Add the following declaration to the definition of std::pair: +
+template<class U, class V> + pair& operator=(const pair<U, V> &p); ++
+And also add a paragraph describing the effects of the function template to the +end of 20.2.2: +
+template<class U, class V> + pair& operator=(const pair<U, V> &p); ++
+ Effects: first = p.first; + second = p.second; + Returns: *this +
+ +[Curaçao: There is no indication this is was anything other than +a design decision, and thus NAD. May be appropriate for a future +standard.]
+ + +[ +Pre Bellevue: It was recognized that this was taken care of by +N1856, +and thus moved from NAD Future to NAD Editorial. +]
+ + + + + + +Section: 22.2.1 [category.ctype] Status: NAD + Submitter: Matt Austern Date: 2002-01-23
+View all other issues in [category.ctype].
+View all issues with NAD 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". On +Microsoft C++ it prints "isspace: 1 isalpha: 1".
+ ++I believe that both implementations are legal, and the standard does not +give enough guidance for users to be able to use std::ctype's +protected interface portably.
+ ++The above program assumes that ctype_base::mask enumerators like +space and print are disjoint, and that the way to +say that a character is both a space and a printing character is to or +those two enumerators together. This is suggested by the "exposition +only" values in 22.2.1 [category.ctype], but it is nowhere specified in +normative text. An alternative interpretation is that the more +specific categories subsume the less specific. The above program +gives the results it does on the Microsoft compiler because, on that +compiler, print has all the bits set for each specific +printing character class. +
+ +From the point of view of std::ctype's public interface, there's no +important difference between these two techniques. From the point of +view of the protected interface, there is. If I'm defining a facet +that inherits from std::ctype<char>, I'm the one who defines the +value that table()['a'] returns. I need to know what combination of +mask values I should use. This isn't so very esoteric: it's exactly +why std::ctype has a protected interface. If we care about users +being able to write their own ctype facets, we have to give them a +portable 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. +
+ +Issue 339 is related, but not identical. The +proposed resolution if issue 339 says that +ctype_base::mask must be a bitmask type. It does not say that the +ctype_base::mask elements are bitmask elements, so it doesn't +directly affect this issue.
+ +More comments from Benjamin Kosnik, who believes that +that C99 compatibility essentially requires what we're +calling 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 standpoint +of portability. Either one will require some implementations to +change.
+ + +Rationale:
+The LWG agrees that this is a real ambiguity, and that both +interpretations are conforming under the existing standard. However, +there's no evidence that it's causing problems for real users. Users +who want to define ctype facets portably can test the ctype_base masks +to see which interpretation is being used.
+ + + + + +Section: 26.7 [c.math] Status: NAD Editorial + Submitter: Ray Lischner Date: 2002-02-26
+View all other issues in [c.math].
+View all issues with NAD 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 to +signal a range error. [Curaçao: The LWG notes that this isn't +strictly correct, since errno is set.] The semantics require that they +return HUGE_VAL, but they cannot because HUGE_VAL might not be +representable 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 by +adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.
+ +C++ must also fix, but it should be done in the context of the +general C99 based changes to C++, not via DR. Thus the LWG in Curaçao +felt the resolution should be NAD, FUTURE, but the issue is being held +open for one more meeting to ensure LWG members not present during the +discussion concur.
+ + +Rationale:
+Will be fixed as part of more general work in the TR.
+ + + + + +Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: NAD + Submitter: Martin Sebor Date: 2002-03-12
+View all other issues in [facet.num.put.virtuals].
+View all issues with NAD status.
+Discussion:
++22.2.2.2.2, p12 specifies that thousands_sep is to be inserted only +for integral types (issue 282 suggests that this should be done for +all arithmetic types). +
+ ++22.2.2.1.2, p12 requires that grouping be checked for all extractors +including that for void*. +
+ ++I don't think that's right. void* values should not be checked for +grouping, should they? (Although if they should, then num_put needs +to 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: 27 [input.output] Status: NAD + Submitter: Walter Brown, Marc Paterno Date: 2002-05-10
+View all other issues in [input.output].
+View all issues with NAD status.
+Discussion:
++The following member functions are declared const, yet return non-const +pointers. We believe they are should be changed, because they allow code +that may surprise the user. See document N1360 for details and +rationale. +
+ +[Santa Cruz: the real issue is that we've got const member +functions that return pointers to non-const, and N1360 proposes +replacing them by overloaded pairs. There isn't a consensus about +whether this is a real issue, since we've never said what our +constness policy is for iostreams. N1360 relies on a distinction +between physical constness and logical constness; that distinction, or +those 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: 25.2.8 [alg.remove] Status: NAD + Submitter: Anthony Williams Date: 2002-05-13
+View all other issues in [alg.remove].
+View all issues with NAD status.
+Discussion:
++remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their +input range to be marked with Input Iterators. However, since two +operations are required against the elements to copy (comparison and +assigment), when the input range uses Input Iterators, a temporary +copy must be taken to avoid dereferencing the iterator twice. This +therefore requires the value type of the InputIterator to be +CopyConstructible. If the iterators are at least Forward Iterators, +then the iterator can be dereferenced twice, or a reference to the +result maintained, so the temporary is not required. +
+ + +Proposed resolution:
++Add "If InputIterator does not meet the requirements of forward +iterator, then the value type of InputIterator must be copy +constructible. Otherwise copy constructible is not required." to +25.2.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: 21.3.6.6 [string::replace] Status: NAD Editorial + Submitter: Beman Dawes Date: 2002-06-03
+View all issues with NAD Editorial status.
+Discussion:
++21.3.6.6 [string::replace] basic_string::replace, second +signature, given in paragraph 1, has two "Throws" paragraphs (3 and +5). +
+ ++In addition, the second "Throws" paragraph (5) includes specification +(beginning with "Otherwise, the function replaces ...") that should be +part 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: 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] Status: NAD + Submitter: Randy Maddox Date: 2002-07-22
+View all other issues in [res.on.exception.handling].
+View all issues with NAD status.
+Discussion:
+ +Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on +Exception Handling, states that "Any other functions defined in the +C++ Standard Library that do not have an exception-specification may +throw implementation-defined exceptions unless otherwise specified." +This statement is followed by a reference to footnote 178 at the +bottom of that page which states, apparently in reference to the C++ +Standard Library, that "Library implementations are encouraged (but +not required) to report errors by throwing exceptions from (or derived +from) the standard exceptions."
+ +These statements appear to be in direct contradiction to clause +18.6.1 [type.info], which states "The class exception defines the +base 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: 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] Status: NAD + Submitter: Ray Lischner Date: 2002-08-08
+View all issues with NAD status.
+Discussion:
++In section 22.2.6.3.1 [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 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits() +should return "unsigned". +
+ + + +Proposed resolution:
+ + +Rationale:
+Regardless of whether the return value is int or unsigned, it's +always conceivable that frac_digits might return a nonsensical +value. (Is 4294967295 really any better than -1?) The clients of +moneypunct, the get and put facets, can and do perform range +checks.
+ + + + + +Section: 21.3.6.4 [string::insert] Status: NAD + Submitter: Ray Lischner Date: 2002-08-16
+View all other issues in [string::insert].
+View all issues with NAD status.
+Discussion:
++Section 21.3.6.4 [string::insert], paragraph 4, contains the following, +"Then throws length_error if size() >= npos - rlen." +
+ ++Related to DR 83, this sentence should probably be removed. +
+ + +Proposed resolution:
+ + +Rationale:
This requirement is redundant but correct. No change is +needed.
+ + + + +Section: 22.1.1 [locale] Status: Dup + Submitter: Martin Sebor Date: 2002-09-06
+View all other issues in [locale].
+View all issues with Dup 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 remain +valid after an assignment that clearly must replace all the facets +in 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 goes +out of scope? +
+ + +Proposed resolution:
+[Summer '04 mid-meeting mailing: Martin and Dietmar believe this + is a duplicate of issue 31 and recommend that it be + closed. +]
+ + + + + + +Section: 17 [library] Status: NAD + Submitter: Matt Austern Date: 2002-10-23
+View all other issues in [library].
+View all issues with NAD status.
+Discussion:
++Many function templates have parameters that are passed by value; +a typical example is find_if's pred parameter in +25.1.5 [alg.find]. Are the corresponding template parameters +(Predicate in this case) implicitly required to be +CopyConstructible, or does that need to be spelled out explicitly? +
+ ++This isn't quite as silly a question as it might seem to be at first +sight. If you call find_if in such a way that template +argument deduction applies, then of course you'll get call by value +and you need to provide a copy constructor. If you explicitly provide +the template arguments, however, you can force call by reference by +writing something like find_if<my_iterator, +my_predicate&>. The question is whether implementation +are required to accept this, or whether this is ill-formed because +my_predicate& is not CopyConstructible. +
+ ++The scope of this problem, if it is a problem, is unknown. Function +object arguments to generic algorithms in clauses 25 [algorithms] +and 26 [numerics] are obvious examples. A review of the whole +library is necessary. +
+[ +This is really two issues. First, predicates are typically passed by +value but we don't say they must be Copy Constructible. They should +be. Second: is specialization allowed to transform value arguments +into references? References aren't copy constructible, so this should +not be allowed. +]
+ +[ +2007-01-12, Howard: First, despite the note above, references are +copy constructible. They just aren't assignable. Second, this is very +closely related to 92 and should be consistent with that. +That issue already says that implementations are allowed to copy +function objects. If one passes in a reference, it is copyable, but +susceptible to slicing if one passes in a reference to a base. Third, +with rvalue reference in the language one only needs to satisfy +MoveConstructible to pass an rvalue "by value". Though the function +might still copy the function object internally (requiring +CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to +code all of the std::algorithms such that they do not copy function +objects internally. One merely passes them by reference internally if +desired (this has been fully implemented and shipped for several years). + If this were mandated, it would reverse 92, allowing +function objects to reliably maintain state. E.g. the example in 92 would reliably remove only the third element. +]
+ + + +Proposed resolution:
++Recommend NAD. +
+ + +Rationale:
++Generic algorithms will be marked with concepts and these will imply a requirement +of MoveConstructible (not CopyConstructible). The signature of the function will +then precisely describe and enforce the precise requirements. +
+ + + + + +Section: 26.3 [complex.numbers] Status: NAD + Submitter: Gabriel Dos Reis Date: 2002-11-08
+View all other issues in [complex.numbers].
+View all issues with NAD status.
+Discussion:
++Practice with std::complex<> and the associative containers +occasionally reveals artificial and distracting issues with constructs +resembling: std::set<std::complex<double> > s; +
+ ++The main reason for the above to fail is the absence of an approriate +definition for std::less<std::complex<T> >. That in turn comes from +the definition of the primary template std::less<> in terms of +operator<. +
+ ++The usual argument goes as follows: Since there is no ordering over +the complex field compatible with field operations it makes little +sense to define a function operator< operating on the datatype +std::complex<T>. That is fine. However, that reasoning does not carry +over to std::less<T> which is used, among other things, by associative +containers as an ordering useful to meet complexity requirements. +
+ +Related issue: 348.
+ +[ +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 change +that we need to do. Is there a total ordering for floating point values, +including NaN? There is not a clear enough solution or big enough +problem for us to solve. Solving this problem would require solving the +problem for floating point, which is equally unclear. The LWG noted that +users 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 of std::less for std::complex.
+ + +Rationale:
+Discussed in Santa Cruz. An overwhelming majority of the LWG +believes this should not be treated a DR: it's a request for a design +change, not a defect in the existing standard. Most people (10-3) +believed that we probably don't want this change, period: as with +issue 348, it's hard to know where to draw the line. +The LWG noted that users who want to put objects into an associative +container for which operator< isn't defined can simply +provide their own comparison function object.
+ + + + + +Section: 20.1.1 [utility.arg.requirements] Status: NAD Editorial + Submitter: Doug Gregor Date: 2002-10-24
+View other active issues in [utility.arg.requirements].
+View all other issues in [utility.arg.requirements].
+View all issues with NAD Editorial status.
+Discussion:
++The CopyConstructible requirements in Table 30 state that for an +object t of type T (where T is CopyConstructible), the expression &t +returns the address of t (with type T*). This requirement is overly +strict, in that it disallows types that overload operator& to not +return a value of type T*. This occurs, for instance, in the Boost.Lambda library, where +operator& is overloaded for a Boost.Lambda function object to return +another 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 to +not return T* , therefore rendering the std::transform call ill-formed. +However, most standard library implementations will compile this code +properly, and the viability of such binder libraries is severely hindered +by the unnecessary restriction in the CopyConstructible requirements. +
+ ++For reference, the address of an object can be retrieved without using +the 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 issue 350, which +will need to be reexamined if the CopyConstructible requirements +change. +
+ + +Proposed resolution:
++Remove the last two rows of Table 30, eliminating the requirements +that &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.1.1 [input.iterators] Status: NAD + Submitter: Corwin Joy Date: 2002-12-11
+View all other issues in [input.iterators].
+View all issues with NAD status.
+Discussion:
+ ++In section 24.1.1 [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 24.5.3.5 [istreambuf.iterator::equal] it states that +"istreambuf_iterator::equal 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." (My emphasis). +
+ ++The defect is that either 'equivalent' needs to be more precisely +defined or the conditions for equality in 24.5.3.5 [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 then +f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].
+ +However, it is unlikely that *f1 will give the same value as *f2 except +by accident.
+ +So what does *f1 'equivalent' to *f2 mean? I think the standard should +be clearer on this point, or at least be explicit that this does not +mean that *f1 and *f2 are required to have the same value in the case +of input iterators.
+ + +Proposed resolution:
+ + +Rationale:
The two iterators aer not in the domain of ==
+ + + + + + +Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: NAD Editorial + Submitter: Alberto Barbati Date: 2002-12-24
+View all other issues in [locale.codecvt.virtuals].
+View all issues with NAD Editorial status.
+Discussion:
++this DR follows the discussion on the previous thread "codecvt::do_in +not consuming external characters". It's just a clarification issue +and 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 22.2.1.4.2 [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 affirmative +answer to the question. However, the current wording has induced a few +library implementors to make the incorrect assumption that +do_in()/do_out() always consume at least one internal character when +they succeed. +
+ ++The submitter also believes that the proposed resolution is not in +conflict with the related issue 76. Moreover, by explicitly allowing +operations on state to produce characters, a codecvt implementation +may effectively implement N-to-M translations without violating the +"one character at a time" principle described in such issue. On a side +note, the footnote in the proposed resolution of issue 76 that +informally rules out N-to-M translations for basic_filebuf should be +removed if this issue is accepted as valid. +
+ + +[ +Kona (2007): The proposed resolution is to add a note. Since this is +non-normative, the issue is editorial, but we believe that the note is +correct. Proposed Disposition: NAD, Editorial +]
+ + + + + + +Section: 27.6.1.3 [istream.unformatted] Status: NAD + Submitter: Martin Sebor Date: 2003-01-05
+View all other issues in [istream.unformatted].
+View all issues with NAD status.
+Discussion:
++The Effects clauses for the two functions below violate the +general requirements on unformatted input functions outlined +in 27.6.1.3: they do not begin by constructing a sentry object. +Instead, they begin by calling widen ('\n'), which may throw +an exception. The exception is then allowed to propagate from +the unformatted input function irrespective of the setting of +exceptions(). +
++Note that in light of 27.6.1.1, p3 and p4, the fact that the +functions allow exceptions thrown from widen() to propagate +may not strictly speaking be a defect (but the fact that the +functions do not start by constructing a sentry object still +is). However, since an exception thrown from ctype<charT> +::widen() during any other input operation (say, from within +a call to num_get<charT>::get()) will be caught and cause +badbit to be set, these two functions should not be treated +differently for the sake of consistency. +
+ + +Proposed resolution:
+ + +Rationale:
++Not a defect. The standard is consistent, and the behavior required +by the standard is unambiguous. Yes, it's theoretically possible for +widen to throw. (Not that this will happen for the default ctype +facet or for most real-world replacement ctype facets.) Users who +define ctype facets that can throw, and who care about this behavior, +can use alternative signatures that don't call widen. +
+ + + + + + +Section: 17.3.1.1 [structure.summary] Status: Pending NAD Editorial + Submitter: Martin Sebor Date: 2003-09-18
+View all issues with Pending NAD Editorial status.
+Discussion:
+ +
+The text in 17.3.1.1, p1 says:
+
+
+"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
+paragraphs are normative."
+
+
+The library section makes heavy use of paragraphs labeled "Notes(s),"
+some of which are clearly intended to be normative (see list 1), while
+some others are not (see list 2). There are also those where the intent
+is not so clear (see list 3).
+
+
+List 1 -- Examples of (presumably) normative Notes:
+
+
+20.7.5.1 [allocator.members], p3,
+20.7.5.1 [allocator.members], p10,
+21.3.2 [string.cons], p11,
+22.1.1.2 [locale.cons], p11,
+23.2.2.3 [deque.modifiers], p2,
+25.3.7 [alg.min.max], p3,
+26.3.6 [complex.ops], p15,
+27.5.2.4.3 [streambuf.virt.get], p7.
+
+
+List 2 -- Examples of (presumably) informative Notes:
+
+
+18.5.1.3 [new.delete.placement], p3,
+21.3.6.6 [string::replace], p14,
+22.2.1.4.2 [locale.codecvt.virtuals], p3,
+25.1.4 [alg.foreach], p4,
+26.3.5 [complex.member.ops], p1,
+27.4.2.5 [ios.base.storage], p6.
+
+
+List 3 -- Examples of Notes that are not clearly either normative
+or informative:
+
+
+22.1.1.2 [locale.cons], p8,
+22.1.1.5 [locale.statics], p6,
+27.5.2.4.5 [streambuf.virt.put], p4.
+
+
+None of these lists is meant to be exhaustive.
+
[Definitely a real problem. The big problem is there's material + that doesn't quite fit any of the named paragraph categories + (e.g. Effects). Either we need a new kind of named + paragraph, or we need to put more material in unnamed paragraphs + jsut after the signature. We need to talk to the Project Editor + about how to do this. +]
+ + +[ +Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, +22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete +will handle editorially. +]
+ + + +Proposed resolution:
+[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". +Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. +Recommend NAD.]
+ +[ +Batavia: We feel that the references in List 2 above should be changed from Remarks +to Notes. We also feel that those items in List 3 need to be double checked for +the same change. Alan and Pete to review. +]
+ + + + + +Section: 27.4.4.3 [iostate.flags] Status: Dup + Submitter: Martin Sebor Date: 2003-09-18
+View all other issues in [iostate.flags].
+View all issues with Dup status.
+Duplicate of: 412
+Discussion:
++ +The Effects clause in 27.4.4.3, p5 describing the effects of a call to +the ios_base member function clear(iostate state) says that the function +only throws if the respective bits are already set prior to the function +call. 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: 18.7.2.4 [unexpected] Status: NAD + Submitter: Vyatcheslav Sysoltsev Date: 2003-09-29
+View all issues with NAD status.
+Discussion:
++Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected(); +is called (18.7.2) immediately after completing the stack unwinding +for the former function", but 18.7.2.4 (Effects) says that "void +unexpected(); . . . Calls the unexpected_handler function in effect +immediately after evaluating the throwexpression (18.7.2.2),". Isn't +here a contradiction: 15.5.2 requires stack have been unwound when in +void unexpected() and therefore in unexpected_handler but 18.7.2.4 +claims that unexpected_handler is called "in effect immediately" after +evaluation of throw expression is finished, so there is no space left +for stack to be unwound therefore? I think the phrase "in effect +immediately" should be removed from the standard because it brings +ambiguity 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: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: NAD + Submitter: Ivan Godard Date: 2003-10-24
+View all other issues in [ostream.inserters.arithmetic].
+View all issues with NAD status.
+Discussion:
++Given: +
+void f(int) {}
+void(*g)(int) = f;
+cout << g;
+
+
++(with the expected #include and usings), the value printed is a rather +surprising "true". Rather useless too. +
+ +The standard defines:
+ +ostream& operator<<(ostream&, void*);+ +
which picks up all data pointers and prints their hex value, but does +not pick up function pointers because there is no default conversion +from function pointer to void*. Absent that, we fall back to legacy +conversions 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: 22.2 [locale.categories] Status: NAD + Submitter: Matt Austern Date: 2003-11-02
+View other active issues in [locale.categories].
+View all other issues in [locale.categories].
+View all issues with NAD 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.
+ +Related issue: 421.
+ +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: 26.3.8 [complex.transcendentals] Status: NAD + Submitter: Matt Austern Date: 2003-11-05
+View all issues with NAD status.
+Discussion:
++Operations like pow and exp on +complex<T> are typically implemented in terms of +operations like sin and cos on T. +Should implementations write this as std::sin, or as plain +unqualified sin? +
+ +The issue, of course, is whether we want to use +argument-dependent lookup in the case where T is a +user-defined type. This is similar to the issue of valarray +transcendentals, as discussed in issue 226.
+ +This issue differs from valarray transcendentals in two important +ways. First, "the effect of instantiating the template +complex for types other than float, double or long double is +unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not +dictate implementation, so there is no guarantee that a particular +real math function is used in the implementation of a particular +complex function.
+ + + +Proposed resolution:
+ + +Rationale:
+If you instantiate std::complex for user-defined types, all bets +are off.
+ + + + + +Section: 22.1.1.1.1 [locale.category] Status: Dup + Submitter: Pete Becker Date: 2003-12-26
+View all other issues in [locale.category].
+View all issues with Dup 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, not +OutputIterator. +
+ + +Proposed resolution:
++Change the second template argument to InputIterator. +
+ + +Rationale:
+ + + + + + +Section: 23.3.3 [set] Status: Dup + Submitter: Bill Plauger Date: 2004-01-30
+View all other issues in [set].
+View all issues with Dup 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 requirements +table, in this regard. +
+ + +Proposed resolution:
+ + +Rationale:
+ + + + + + +Section: 23.1.4 [associative.reqmts], 23.3 [associative] Status: Dup + Submitter: Bill Plauger Date: 2004-01-30
+View all other issues in [associative.reqmts].
+View all issues with Dup status.
+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 for +vector/deque/list:
+iterator erase(iterator); + iterator erase(iterator, iterator); ++ + + +
Proposed resolution:
++Informally: The table of associative container requirements, and the +relevant template classes, should return an iterator designating the +first element beyond the erased subrange. +
+ + +Rationale:
+ + + + + + +Section: 22.1.1.3 [locale.members] Status: NAD + Submitter: Bill Plauger Date: 2004-01-30
+View all other issues in [locale.members].
+View all issues with NAD status.
+Discussion:
+template<class Facet> + locale::combine(const locale&) const; ++
+is obliged to create a locale that has no name. This is overspecification +and overkill. The resulting locale should follow the usual rules -- it +has a name if the locale argument has a name and Facet is one of the +standard 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. The combine member function works at the + wrong level of granularity.
+ + + + + +Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: NAD + Submitter: Bill Plauger Date: 2004-03-23
+View all issues with NAD status.
+Discussion:
++3.6.3 Termination spells out in detail the interleaving of static +destructor calls and calls to functions registered with atexit. To +match this behavior requires intimate cooperation between the code +that calls destructors and the exit/atexit machinery. The former +is tied tightly to the compiler; the latter is a primitive mechanism +inherited from C that traditionally has nothing to do with static +construction and destruction. The benefits of intermixing destructor +calls with atexit handler calls is questionable at best, and very +difficult to get right, particularly when mixing third-party C++ +libraries with different third-party C++ compilers and C libraries +supplied by still other parties. +
+ ++I believe the right thing to do is defer all static destruction +until after all atexit handlers are called. This is a change in +behavior, but one that is likely visible only to perverse test +suites. At the very least, we should permit deferred destruction +even 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 deferred +destruction but not require it. +]
+ + +[ +Howard: The course of action recommended in Batavia would undo LWG +issue 3 and break current code implementing the "phoenix +singleton". Search the net for "phoenix singleton atexit" to get a feel +for the size of the adverse impact this change would have. Below is +sample code which implements the phoenix singleton and would break if +atexit 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 pattern
+A& 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 with quick_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:
++
+ + + + + +Section: 21.3.1 [string.require] Status: NAD + Submitter: Daniel Frey Date: 2004-06-10
+View all other issues in [string.require].
+View all issues with NAD status.
+Discussion:
++Today, my colleagues and me wasted a lot of time. After some time, I +found the problem. It could be reduced to the following short example: +
+ + #include <string>
+ int main() { std::string( 0 ); }
+
+
+The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and +Comeau online) compile the above without errors or warnings! The +programs (at least for the GCC) resulted in a SEGV.
+ +I know that the standard explicitly states that the ctor of string +requires a char* which is not zero. STLs could easily detect the above +case with a private ctor for basic_string which takes a single 'int' +argument. This would catch the above code at compile time and would not +ambiguate any other legal ctors.
+ +[Redmond: No great enthusiasm for doing this. If we do, + however, we want to do it for all places that take charT* + pointers, not just the single-argument constructor. The other + question is whether we want to catch this at compile time (in which + case we catch the error of a literal 0, but not an expression whose + value is a null pointer), at run time, or both.]
+ + + + +Proposed resolution:
+ + +Rationale:
++Recommend NAD. Relegate this functionality to debugging implementations. +
+ + + + + +Section: 23 [containers] Status: NAD + Submitter: Martin Sebor Date: 2004-06-28
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with NAD status.
+Discussion:
+ ++The standard doesn't prohibit the destructors (or any other special +functions) of containers' elements invoked from a member function +of the container from "recursively" calling the same (or any other) +member function on the same container object, potentially while the +container is in an intermediate state, or even changing the state +of the container object while it is being modified. This may result +in 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 standard +that will cover all cases without introducing unfortunate +corner cases. +
+ + + + + +Section: 25.3.3.3 [equal.range] Status: Dup + Submitter: Prateek R Karandikar Date: 2004-06-30
+View all other issues in [equal.range].
+View all issues with Dup status.
+Duplicate of: 270
+Discussion:
++There is no "Returns:" clause for std::equal_range, which returns non-void. +
+ + +Proposed resolution:
+ + +Rationale:
+Fixed as part of issue 270.
+ + + + + + +Section: 24.1.3 [forward.iterators] Status: NAD + Submitter: Dave Abrahams Date: 2004-07-09
+View all other issues in [forward.iterators].
+View all issues with NAD 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 iterator +means that you can always assign *something* into the result of +dereferencing it. That makes almost all non-mutable forward +iterators non-conforming. I think we need to sever the refinement +relationship between forward iterator and output iterator. +
+ +Related issue: 200. But this is not a dup.
+ + + +Proposed resolution:
+ + +Rationale:
+Yes, 24.1/3 does say that. But it's introductory material. The +precise specification is in 24.1.3, and the requrements table there is +right. We don't need to fine-tune introductory wording. (Especially +since this wording is likely to be changed as part of the iterator +overhaul.)
+ + + + + +Section: 24.1.3 [forward.iterators] Status: Dup + Submitter: Dave Abrahams Date: 2004-07-11
+View all other issues in [forward.iterators].
+View all issues with Dup 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. Basically +it implies that the const-ness of the iterator affects the const-ness +of 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 same +as the first line.
+ +Related issue: 478
+ + +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 in + 478. +
+ + + + + +Section: 23.1 [container.requirements] Status: Dup + Submitter: Herb Sutter Date: 2004-08-01
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Dup 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 of operator new.
+ +[ +Lillehammer: A container will definitely never use this overridden +operator new, but whether it will fail to compile is unclear from the +standard. Are containers supposed to use qualified or unqualified +placement new? 20.4.1.1 is somewhat relevant, but the standard +doesn't make it completely clear whether containers have to use +Allocator::construct(). If containers don't use it, the details of how +containers use placement new are unspecified. That is the real bug, +but it needs to be fixed as part of the allocator overhaul. Weak +support that the eventual solution should make this code well formed. +]
+ + + + +Proposed resolution:
+ + + + + + + +Section: 20.6.3 [base] Status: NAD + Submitter: Joe Gottman Date: 2004-08-19
+View all other issues in [base].
+View all issues with NAD status.
+Discussion:
+The classes std::unary_function and std::binary_function are both +designed to be inherited from but contain no virtual functions. This +makes it too easy for a novice programmer to write code like +binary_function<int, int, int> *p = new plus<int>; delete p;
+ +There are two common ways to prevent this source of undefined +behavior: give the base class a public virtual destructor, or give it +a protected nonvirtual destructor. Since unary_function and +binary_function have no other virtual functions, (note in particular +the absence of an operator()() ), it would cost too much to give them +public virtual destructors. Therefore, they should be given protected +nonvirtual 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: 25.2.9 [alg.unique] Status: NAD + Submitter: Andrew Koenig Date: 2004-08-30
+View all other issues in [alg.unique].
+View all issues with NAD status.
+Discussion:
++The standard says that unique(first, last) "eliminates all but the +first element from every consecutive group of equal elements" in +[first, last) and returns "the end of the resulting range". So a +postcondition 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 being +explicit, but it's hard to think that's a major problem.
+ + + + + +Section: 20.2.3 [pairs], 20.4 [tuple] Status: NAD Editorial + Submitter: Andrew Koenig Date: 2004-09-14
+View all other issues in [pairs].
+View all issues with NAD Editorial status.
+Discussion:
+(Based on recent comp.std.c++ discussion)
+ +Pair (and tuple) should specialize std::swap to work in terms of +std::swap on their components. For example, there's no obvious reason +why swapping two objects of type pair<vector<int>, +list<double> > should not take O(1).
+ +[Lillehammer: We agree it should be swappable. Howard will + provide wording.]
+ + +[ +Post Oxford: We got swap for pair but accidently +missed tuple. tuple::swap is being tracked by 522. +]
+ + + + +Proposed resolution:
++Wording provided in +N1856. +
+ +Rationale:
++Recommend NAD, fixed by +N1856. +
+ + + + + +Section: 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] Status: Dup + Submitter: Peter Dimov Date: 2004-09-20
+View all issues with Dup 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 Effects +clause, is actually *i == value, where i is an InputIterator. +
+ ++The two clauses are in agreement only if the type of *i is T, but this +isn't necessarily the case. *i may have a heterogeneous comparison +operator 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 just find. 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) issue 283.
+ + + + + + +Section: 25.3.7 [alg.min.max] Status: Dup + Submitter: Dave Abrahams Date: 2004-10-13
+View all other issues in [alg.min.max].
+View all issues with Dup status.
+Duplicate of: 281
+Discussion:
+A straightforward implementation of these algorithms does not need to +copy T.
+ + +Proposed resolution:
+drop the the words "and CopyConstructible" from paragraphs 1 and 4
+ + +Rationale:
+ + + + + + +Section: 20.1.2 [allocator.requirements] Status: NAD + Submitter: Dhruv Matani Date: 2004-10-17
+View other active issues in [allocator.requirements].
+View all other issues in [allocator.requirements].
+View all issues with NAD status.
+Discussion:
++The standard's version of allocator::construct(pointer, +const_reference) severely limits what you can construct using this +function. Say you can construct a socket from a file descriptor. Now, +using this syntax, I first have to manually construct a socket from +the fd, and then pass the constructed socket to the construct() +function so it will just to an uninitialized copy of the socket I +manually constructed. Now it may not always be possible to copy +construct a socket eh! So, I feel that the changes should go in the +allocator::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 can +be 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: 25.2.8 [alg.remove] Status: NAD + Submitter: Thomas Mang Date: 2004-12-12
+View all other issues in [alg.remove].
+View all issues with NAD status.
+Discussion:
+In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the +behavior of the mutating sequence operations std::remove and +std::remove_if. However, the wording does not reflect the intended +behavior [Note: See definition of intended behavior below] of these +algorithms, 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 the +range [first, last) for which the following corresponding conditions +hold: *i == value, pred(*i) != false."
+ ++This sentences expresses specifically that all elements denoted by the +(original) range [first, last) for which the corresponding condition +hold will be eliminated. Since there is no formal definition of the term +"eliminate" provided, the meaning of "eliminate" in everyday language +implies that as postcondition, no element in the range denoted by +[first, last) will hold the corresponding condition on reiteration over +the range [first, last). +
+ ++However, this is neither the intent [Note: See definition of intended +behavior below] nor a general possible approach. It can be easily proven +that if all elements of the original range[first, last) will hold the +condition, it is not possible to substitute them by an element for which +the 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 of +this so-called resulting range is the range [first,last) - thus +returning 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 removed +is the same as their relative order in the original range" +
+ ++This sentences makes use of the term "removed", which is neither +specified, 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 intended +behavior was that all elements of the range [first, last) which do not +hold the condition *i == value (std::remove) or pred(*i) != false +(std::remove_if)], call them s-elements [Note: s...stay], will be placed +into 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 the +original range [first, last). The relative order of the elements in the +resulting subrange[first, return value) shall be the same as the +relative order of the corresponding elements in the original range. It +is undefined whether any elements in the resulting subrange [return +value, last) will hold the corresponding condition, or not. +
+ ++All implementations known to the author of this Defect Report comply +with this intent. Since the intent of the behavior (contrary to the +current wording) is also described in various utility references serving +the C++ community [1], it is not expected that fixing the paragraphs +will influence current code - unless the code relies on the behavior as +it is described by current wording and the implementation indeed +reflects 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 the +original range, where k shall denote a value of type ForwardIterator. It +is 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 meaning +should fit. +b) The corresponding conditions were negated compared to the current +wording, becaue the new wording requires it. +c) The wording "of the original range" might be redundant, since any +subrange starting at 'first' and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +d) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall +denote a value of type ForwardIterator" might be redundant, because it +follows implicitly by 25.2.7/3. +e) "Places" does, in the author's opinion, explicitly forbid duplicating +any element holding the corresponding condition in the original range +[first, last) within the resulting range [first, k). If there is doubt +this term might be not unambiguous regarding this, it is suggested that +k is specified more closely by the following wording: "k shall denote a +value of type ForwardIterator [Note: see d)] so that k - first is equal +to the number of elements in the original range [first, last) for which +the corresponding condition did hold". This could also be expressed as a +separate paragraph "Postcondition:" +f) The senctence "It is undefined whether any elements in the resulting +subrange [k, last) will hold the corresponding condition, or not." was +added consciously so the term "Places" does not imply if the original +range [first, last) contains n elements holding the corresponding +condition, the identical range[first, last) will also contain exactly n +elements holding the corresponding condition after application of the +algorithm. +
+ ++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 into +the subrange [first, return value) shall be the same as their relative +order was in the original range [first, last) prior to application of +the algorithm." +
+ ++Comments to the new wording: +
+ ++a) the wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, 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 provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/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: 25.2.9 [alg.unique] Status: NAD + Submitter: Thomas Mang Date: 2004-12-12
+View all other issues in [alg.unique].
+View all issues with NAD status.
+Discussion:
+In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the +behavior of the mutating sequence operation std::unique. However, the +wording does not reflect the intended behavior [Note: See definition of +intended 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 consecutive +group 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 from +a consecutive group of equal elements (where equality is defined as *i +== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call +them r-elements [Note: r...remove], will be eliminated. Since there is +no formal definition of the term "eliminate" provided, it is undefined +how this "elimination" takes place. But the meaning of "eliminate" in +everyday language seems to disallow explicitly that after application of +the 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 to +compare two elements for equality: The current wording contains the +expression "(i - 1)", which is not covered by 25/9 [Note: See DR +submitted by Thomas Mang regarding invalid iterator arithmetic +expressions]. +
+ + ++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 the +author's opinion even the only possible interpretation) of this +so-called resulting range is the range [first, last) - thus returning +always the ForwardIterator 'last' parameter. +
+ +2) Description of intended behavior:
+ ++For the rest of this Defect Report, it is assumed that the intended +behavior was that all elements denoted by the original range [first, +last) which are the first element from a consecutive group of elements +for which the corresponding conditions: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i-1), *i) ! = false (for +the version of unique with a predicate argument) [Note: If such a group +of elements consists of only a single element, this is also considered +the first element] [Note: See resolutions of DR 202], call them +s-elements [Note: s...stay], will be placed into 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 the original range [first, last). +Invalid iterator arithmetic expressions are expected to be resolved as +proposed in DR submitted by Thomas Mang regarding invalid iterator +arithmetic expressions. It is also assumed by the author that the +relative order of the elements in the resulting subrange [first, return +value) shall be the same as the relative order of the corresponding +elements (the s-elements) in the original range [Note: If this was not +intended behavior, the additional proposed paragraph about stable order +will certainly become obsolete]. +Furthermore, the resolutions of DR 202 are partially considered. +
+ ++All implementations known to the author of this Defect Report comply +with this intent [Note: Except possible effects of DR 202]. Since this +intent of the behavior (contrary to the current wording) is also +described in various utility references serving the C++ community [1], +it is not expected that fixing the paragraphs will influence current +code [Note: Except possible effects of DR 202] - unless the code relies +on the behavior as it is described by current wording and the +implementation 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 of +elements, referred to by the iterator i in the range [first, last), for +which the following conditions hold: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i -1), *i) != false (for +the version of unique with a predicate argument), into the subrange +[first, k) of the original range, where k shall denote a value of type +ForwardIterator." +
+ +Comments to the new wording:
+ ++a) The new wording was influenced by the resolutions of DR 202. If DR +202 is resolved in another way, the proposed wording need also +additional review. +b) "Places" has no special meaning, and the everyday language meaning +should fit. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique without a predicate +argument)" and "(for the version of unique with a predicate argument)" +was added consciously for clarity and is in resemblence with current +23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. +e) The wording "of the original range" might be redundant, since any +subrange starting at first and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +f) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The +wording ", where k shall denote a value of type ForwardIterator" might +be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], +paragraph 2. +g) "Places" does, in the author's opinion, explicitly forbid duplicating +any s-element in the original range [first, last) within the resulting +range [first, k). If there is doubt this term might be not unambiguous +regarding this, it is suggested that k is specified more closely by the +following wording: "k shall denote a value of type ForwardIterator +[Note: See f)] so that k - first is equal to the number of elements in +the original range [first, last) being the first element from every +consecutive group of elements for which the corresponding condition did +hold". This could also be expressed as a separate paragraph +"Postcondition:". +h) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case last - first == +1] , the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered 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], paragraph +2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 +[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if +the preceding expressions are used, or the preceding expressions shall +be eliminated if wording inside {} is used): +
+ ++"Notes:{Postcondition:} Stable: the relative order of the elements that +are placed into the subrange [first, return value {k}) shall be the same +as their relative order was in the original range [first, last) prior to +application of the algorithm." +
+ +Comments to the new wording:
+ ++a) It is assumed by the author that the algorithm was intended to be +stable. +In case this was not the intent, this paragraph becomes certainly +obsolete. +b) The wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, 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 in +this Defect Report [Note: This DR is supposed to complement DR 202]. +See DR 239. +See DR submitted by Thomas Mang regarding invalid iterator arithmetic +expressions. +
+ ++[1]: +The wording of these references is not always unambiguous, and provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/IEC 14882:2003. +
+ ++[2]: +Illustration of conforming implementations according to current wording: +
+ ++One way the author of this DR considers how this "elimination" could be +achieved by a conforming implementation according to current wording is +by substituting each r-element by _any_ s-element [Note: s...stay; any +non-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 the +only possible solution according to current wording. +
+ + +Proposed resolution:
+ + +Rationale:
+The LWG believes the standard is sufficiently clear. No +implementers get it wrong, and changing it wouldn't cause any code to +change, so there is no real-world harm here.
+ + + + + +Section: 23.2.4.4 [list.ops] Status: NAD + Submitter: Thomas Mang Date: 2004-12-12
+View all other issues in [list.ops].
+View all issues with NAD status.
+Discussion:
+In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the +behavior of the std::list<T, Allocator>::unique operation. However, the +current wording is defective for various reasons.
+ + + ++1) Analysis of current wording: +
+ +23.2.4.4 [list.ops], paragraph 19:
+ ++Current wording says: +"Effects: Eliminates all but the first element from every consecutive +group of equal elements referred to by the iterator i in the range +[first + 1, last) for which *i == *(i - 1) (for the version of unique +with no argument) or pred(*i, *(i -1)) (for the version of unique with a +predicate argument) holds."
+ ++This sentences makes use of the undefined term "Eliminates". Although it +is, to a certain degree, reasonable to consider the term "eliminate" +synonymous with "erase", using "Erase" in the first place, as the +wording of 23.2.4.4 [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 not +defined for bidirectional iterator [see DR submitted by Thomas Mang +regarding invalid iterator arithmetic expressions].
+ ++The same problems as pointed out in DR 202 (equivalence relation / order +of arguments for pred()) apply to this paragraph.
+ ++23.2.4.4 [list.ops], paragraph 20: +
+ ++Current wording says: +"Throws: Nothing unless an exception in thrown by *i == *(i-1) or +pred(*i, *(i - 1))"
+ ++The sentence makes two times use of invalid iterator arithmetic +expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). +
++[Note: Minor typos: "in" / missing dot at end of sentence.] +
+ ++23.2.4.4 [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 no +application 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" is +supposed to be synonymous to "erase", that "first" is equivalent to an +iterator obtained by a call to begin(), "last" is equivalent to an +iterator obtained by a call to end(), and that all invalid iterator +arithmetic expressions are resolved as described in DR submitted by +Thomas Mang regarding invalid iterator arithmetic expressions.
+ ++Furthermore, the resolutions of DR 202 are considered regarding +equivalence relation and order of arguments for a call to pred.
+ ++All implementations known to the author of this Defect Report comply +with these assumptions, apart from the impact of the alternative +resolution of DR 202. Except for the changes implied by the resolutions +of DR 202, no impact on current code is expected.
+ ++3) Proposed fixes:
+ ++Change 23.2.4.4 [list.ops], paragraph 19 to:
+ ++"Effect: Erases all but the first element from every consecutive group +of elements, referred to by the iterator i in the range [begin(), +end()), for which the following conditions hold: *(i-1) == *i (for the +version of unique with no argument) or pred(*(i-1), *i) != false (for +the version of unique with a predicate argument)."
+ ++Comments to the new wording:
+ ++a) The new wording was influenced by DR 202 and the resolutions +presented there. If DR 202 is resolved in another way, the proposed +wording need also additional review. +b) "Erases" refers in the author's opinion unambiguously to the member +function "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.2.4.4 [list.ops], paragraph +15.]. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique with no argument)" and "(for +the version of unique with a predicate argument)" was kept consciously +for clarity. +e) "begin()" substitutes "first", and "end()" substitutes "last". The +range need adjustment from "[first + 1, last)" to "[begin(), end())" to +ensure a valid range in case of an empty list. +f) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case size() == 1] , +the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered the first element."
+ ++Change 23.2.4.4 [list.ops], paragraph 20 to:
+ ++"Throws: Nothing unless an exception is thrown by *(i-1) == *i or +pred(*(i-1), *i)."
+ ++Comments to the new wording:
+ ++a) The wording regarding the conditions is identical to proposed +23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops], +paragraph 19 is resolved in another way, the proposed wording need also +additional review. +b) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +c) Typos fixed.
+ ++Change 23.2.4.4 [list.ops], paragraph 21 to:
+ ++"Complexity: If empty() == false, exactly size() - 1 applications of the +corresponding predicate, otherwise no applications of the corresponding +predicate."
+ ++Comments to the new wording:
+ ++a) The new wording is supposed to also replace the proposed resolution +of 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 arithmetic +expressions.
+ + + +Proposed resolution:
+ + +Rationale:
+"All implementations known to the author of this Defect Report +comply with these assumption", and "no impact on current code is +expected", i.e. there is no evidence of real-world confusion or +harm.
+ + + + + +Section: 24.1.1 [input.iterators] Status: NAD + Submitter: Chris Jefferson Date: 2004-12-13
+View all other issues in [input.iterators].
+View all issues with NAD 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 does +not 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 required +either to be dereferenceable ..."
+ +While a==b does not imply that b is a copy of a, this statement should +perhaps 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 does +not guarantee the substitution property or referential transparency).
+ + + +Proposed resolution:
+ + +Rationale:
+This is descriptive text, not normative, and the meaning is clear.
+ + + + + +Section: 23.1.4 [associative.reqmts] Status: NAD + Submitter: Hans B os Date: 2004-12-19
+View all other issues in [associative.reqmts].
+View all issues with NAD status.
+Discussion:
+According to [lib.associative.reqmts] table 69, the runtime comlexity +of insert(p, t) and erase(q) can be done in amortized constant time.
+ +It was my understanding that an associative container could be +implemented as a balanced binary tree.
+ +For inser(p, t), you 'll have to iterate to p's next node to see if t +can be placed next to p. Furthermore, the insertion usually takes +place at leaf nodes. An insert next to the root node will be done at +the left of the root next node
+ +So when p is the root node you 'll have to iterate from the root to +its next node, which takes O(log(size)) time in a balanced tree.
+ +If you insert all values with insert(root, t) (where root is the +root 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 no +empty 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 delete +the leaf node. Furthermore according to DR 130, erase should return +the 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 is +empty, each operation will take O(log(size)), and the amortized +complexity is still O(log(size)).
+ +The operations can be done in amortized constant time if iterating +to the next node can be done in (non amortized) constant time. This +can be done by putting all nodes in a double linked list. This +requires two extra links per node. To me this is a bit overkill since +you 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: 25.3.1.2 [stable.sort] Status: NAD Editorial + Submitter: Prateek Karandikar Date: 2005-04-12
+View all issues with NAD 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: 22.2.1.5 [locale.codecvt.byname] Status: NAD + Submitter: Krzysztof Żelechowski Date: 2005-05-24
+View all other issues in [locale.codecvt.byname].
+View all issues with NAD status.
+Discussion:
++Contradiction. +
+ + +Proposed resolution:
++
+ + + + + +Section: 20.6.3 [base] Status: NAD + Submitter: Me <anti_spam_email2003@yahoo.com> Date: 2005-06-07
+View all other issues in [base].
+View all issues with NAD status.
+Discussion:
++ ++"For templates greater, less, greater_equal, and less_equal, +the specializations for any pointer type yield a total order, even if +the built-in operators <, >, <=, >= do not." +
+The standard should do much better than guarantee that these provide a +total order, it should guarantee that it can be used to test if memory +overlaps, i.e. write a portable memmove. You can imagine a platform +where the built-in operators use a uint32_t comparison (this tests for +overlap on this platform) but the less<T*> functor is allowed to be +defined to use a int32_t comparison. On this platform, if you use +std::less with the intent of making a portable memmove, comparison on +an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give +incorrect 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 p2 +points 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) to +all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R +such 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 when +comparing 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 is +considered to be an array of 1 object that doesn't overlap with any +non-null pointer to T. less_equal, greater, greater_equal, equal_to, +and not_equal_to give the expected results based on the total ordering +semantics of less. For T of void, treat it as having similar semantics +as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv +void*>(a, b) which gives the same results as less<cv char*>((cv +char*)(cv void*)a, (cv char*)(cv void*)b). +
+I'm also thinking there should be a footnote to 20.5.3/1 saying that if +A and B are similar types (4.4/4), comp<A>(a,b) returns the same value +as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might +be problematic if there is some really funky operator overloading going +on that does different things based on cv (that should be undefined +behavior if somebody does that though). This at least should be +guaranteed for all POD types (especially pointers) that use the +built-in comparison operators. +
+ + + +Rationale:
++less is already required to provide a strict weak ordering which is good enough +to detect overlapping memory situations. +
+ + + + + +Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD Editorial + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.req].
+View all issues with NAD 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 that +defines a zero-argument function object returning values of
unsigned integraltype +unsigned 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 state +determined 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. Moved +to Ready. +]
+ + + + +Rationale:
++Jens: Just requiring X(unsigned long) still makes it possible +for an evil library writer to also supply a X(int) that does something +unexpected. The wording above requires that X(s) always performs +as if X(unsigned long) would have been called. I believe that is +sufficient and implements our intentions from Mont Tremblant. I +see no additional use in actually requiring a X(unsigned long) +signature. u.seed(s) is covered by its reference to X(s), same +arguments. +
+ + +[ +Portland: Subsumed by N2111. +]
+ + + + + +Section: 26.4 [rand], TR1 5.1.3 [tr.rand.var] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand].
+View all issues with NAD status.
+Discussion:
++Paragraph 3 requires that template argument U (which corresponds to template +parameter Engine) satisfy all uniform random number generator requirements. +However, there is no analogous requirement regarding the template argument +that corresponds to template parameter Distribution. We believe there should +be, and that it should require that this template argument satisfy all random +distribution 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 that +do 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: 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.dist.uni].
+View all issues with NAD status.
+Discussion:
++In [tr.rand.dist.iunif] the uniform_int distribution currently has a single +template parameter, IntType, used as the input_type and as the result_type +of the distribution. We believe there is no reason to conflate these types +in this way. +
+ + +Proposed resolution:
++We recommend that there be a second template parameter to +reflect the distribution's input_type, and that the existing first template +parameter 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 been +eliminated. +]
+ + + + + + + +Section: 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all issues with NAD 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 been +eliminated. +]
+ + + + + + + +Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.dist].
+View all issues with NAD status.
+Discussion:
++Unlike all other distributions in TR1, this binomial_distribution has an +implementation-defined input_type. We believe this is an unfortunate choice, +because it hinders users from writing portable code. It also hinders the +writing of compliance tests. We recommend instead: +
++typedef RealType input_type; +
+While this choice is somewhat arbitrary (as it was for some of the other +distributions), we make this particular choice because (unlike all other +distributions) otherwise this template would not publish its RealType +argument and so users could not write generic code that accessed this +second template parameter. In this respect, the choice is consistent with +the 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 distribution +implementations, while the other is based on mathematical characteristics of +probability distribution functions in general. +
++Implementations of binomial distributions commonly use Stirling approximations +for values in certain ranges. It is far more natural to use real values to +represent these approximations than it would be to use integral values to do +so. In other ranges, implementations reply on the Bernoulli distribution to +obtain values. While TR1's bernoulli_distribution::input_type is specified as +int, we believe this would be better specified as double. +
++This brings us to our main point: The notion of a random distribution rests +on the notion of a cumulative distribution function, which in turn mathematically +depends on a continuous dependent variable. Indeed, such a distribution function +would be meaningless if it depended on discrete values such as integers - and this +remains 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 be +specified 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, and +gamma_distribution). We have already argued the case for the binomial the +remaining four distributions. +
++In the case of uniform_int, we believe that the calculations to produce an +integer result in a specified range from an integer in a different specified +range is best done using real arithmetic. This is because it involves a +product, one of whose terms is the ratio of the extents of the two ranges. +Without real arithmetic, the results become less uniform: some numbers become +more (or less) probable that they should be. This is, of course, undesireable +behavior in a uniform distribution. +
++Finally, we believe that in the case of the bernoulli_distribution (briefly +mentioned earlier), as well as the cases of the geometric_distribution and the +poisson_distribution, it would be far more natural to have a real input_type. +This is because the most natural computation involves the random number +delivered 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 specified +in 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 been +eliminated. +]
+ + + + + + +Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.eng].
+View all issues with NAD Editorial status.
+Discussion:
++Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine +is to be seeded given a single unsigned long. This algorithm is seriously +flawed 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 with +a maximum of 2147483563 (just a shade under 31 bits), then when w is, for +example, 48, each of the x(i) will be less than 2**-17. The consequence +is that roughly the first 400 numbers delivered will be conspicuously +close to either zero or one. +
++Unfortunately, this is not an innocuous flaw: One of the predefined engines +in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit +this poor behavior, while the original N1378 proposal states that these +pre-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 for +void seed(unsigned long value = 19780503) by +
+ ++ ++Effects: If value == 0, sets value to 19780503. In any +case,
+ +with a linear congruential generator lcg(i) having parameters +mlcg = 2147483563, alcg = 40014, +clcg = 0, and lcg(0) = value,+sets carry(-1) and x(-r) … x(-1) +as if executing+ ++linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value); +seed(lcg); ++
+to (lcg(1) · 2-w) mod 1 +… (lcg(r) · 2-w) mod 1, +respectively. If x(-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 is +intended. Moved to Ready. +]
+ + + + +Rationale:
++Jens: I'm using an explicit type here, because fixing the +prose would probably not qualify for the (with issue 504 even +stricter) requirements we have for seed(Gen&). +
+ +[ +Portland: Subsumed by N2111. +]
+ + + + + + +Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.eng].
+View all issues with NAD Editorial status.
+Discussion:
++Paragraph 3 begins: +
+++The size of the state is r. +
+However, this is not quite consistent with the remainder of the paragraph +which specifies a total of nr+1 items in the textual representation of +the 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 move +n's definition from later in the paragraph. Either of the following +seem 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 only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]
+ + +[ +Berlin: N1932 adopts the proposed NAD. +]
+ + + + + + + +Section: 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] Status: NAD Editorial + Submitter: Walter Brown Date: 2005-07-03
+View all issues with NAD 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 textual +representation 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 only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]
+ + +[ +Berlin: N1932 adopts the proposed NAD. +]
+ + + + + + + +Section: 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.synopsis].
+View all issues with NAD 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 involving +pseudo-random number engines. Given only the facilities described in tr1, it would +be very difficult to produce any algorithms involving the notion of a generic engine. +The intent of this proposal is to provide, via engine_traits<>, sufficient +descriptive information to allow an algorithm to employ a pseudo-random number engine +without regard to its exact type, i.e., as a template parameter. +
++For example, today it is not possible to write an efficient generic function that +requires any specific number of random bits. More specifically, consider a +cryptographic 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 provided +engine, 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_traits +template 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 a +complete specialization of this new engine_traits template. +
+ + + +Proposed resolution:
+[ +Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this +feature. Recommend close as NAD. +]
+ + + +Rationale:
++Recommend NAD, +N1932, +N2111 +covers this. Already in WP. +
+ + + + + +Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.eng].
+View all issues with NAD 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: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD + Submitter: Walter Brown Date: 2005-07-03
+View all other issues in [rand.req].
+View all issues with NAD 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 seems +inadequate in the context of generic code, where it becomes useful and +perhaps 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, the +text "textual representation" be expanded so as to read "engine name +followed by the textual representation." +
+ +[ +Berlin: N1932 considers this NAD. This is a QOI issue. +]
+ + + + + + + +Section: 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial + Submitter: Robert Klarer Date: 2005-07-11
+View all issues with NAD Editorial status.
+Discussion:
++It is not completely clear how the primary type traits deal with +cv-qualified types. And several of the secondary type traits +seem to be lacking a definition. +
+ +[ +Berlin: Howard to provide wording. +]
+ + + +Proposed resolution:
++Wording provided in N2028. +A +revision (N2157) +provides more detail for motivation. +
+ + +Rationale:
+Solved by revision (N2157) +in the WP. + + + + + +Section: 23.1.3 [sequence.reqmts] Status: NAD + Submitter: Chris Jefferson Date: 2005-09-14
+View all other issues in [sequence.reqmts].
+View all issues with NAD status.
+Discussion:
++Problem: There are a number of places in the C++ standard library where +it is possible to write what appear to be sensible ways of calling +functions, but which can cause problems in some (or all) +implementations, as they cause the values given to the function to be +changed in a way not specified in standard (and therefore not coded to +correctly work). These fall into two similar categories. +
+ ++1) Parameters taken by const reference can be changed during execution +of 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 all +cases. +
+ ++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 example +std::copy(first, last, result) states that result cannot be in the range +[first, last). However, does this cover the case where result is a +reverse_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 of +each 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 passed +by reference or any value in any range passed to a function in a way not +defined in the definition of that function, the result is undefined. +
+ ++Such code would have to at least cover chapters 23 and 25 (the sections +I read through carefully). I can see no harm on applying it to much of +the 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 would +allow a number of small optimisations, such as caching values passed +by const reference. +
+ ++Matt Austern adds that this issue also exists for the insert and +erase members of the ordered and unordered associative containers. +
+ +[ +Berlin: Lots of controversey over how this should be solved. Lots of confusion +as to whether we're talking about self referencing iterators or references. +Needs a good survey as to the cases where this matters, for which +implementations, and how expensive it is to fix each case. +]
+ + + + +Proposed resolution:
+ + +Rationale:
++Recommend NAD. +
+Section: 23.4 [unord], TR1 6.3.4 [tr.unord.unord] Status: NAD + Submitter: Paolo Carlini Date: 2005-10-12
+View other active issues in [unord].
+View all other issues in [unord].
+View all issues with NAD status.
+Discussion:
++while implementing the resolution of issue 6.19 I'm noticing the +following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and +unordered_multiset: +
+ ++ ++ "The iterator and const_iterator types are both const types. It is +unspecified whether they are the same type" +
+Now, according to the resolution of 6.19, we have overloads of insert +with hint and erase (single and range) both for iterator and +const_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 plain +iterators 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 both const
+constant 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 members +are collapsed into one signature). Alisdair to open a separate issue on the +chapter 17 wording. + + + + + +Section: 17.4.3.10 [res.on.required] Status: NAD Editorial + Submitter: David Abrahams Date: 2005-10-25
+View all issues with NAD Editorial status.
+Discussion:
++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 defined +behavior. That conflicts with the only reasonable definition of +precondition: that a violation leads to undefined behavior. Any other +definition muddies the waters when it comes to analyzing program +correctness, because precondition violations may be routinely done in +correct code (e.g. you can use std::vector::at with the full +expectation that you'll get an exception when your index is out of +range, catch the exception, and continue). Not only is it a bad +example to set, but it encourages needless complication and redundancy +in 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. We +could make that simplifying change (and many others like it) even +without changing 17.4.3.8/1; the wording there just seems to encourage +the redundant and error-prone Requires: clause. +
+ +[ +Batavia: Alan and Pete to work. +]
+ + +[ +Bellevue: NAD Editorial, this group likes +N2121, +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's +Required behavior: paragraph results in undefined behavior +
unless the function's Throws: paragraph specifies throwing +an 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 survey +N2121. +]
+ + + + + + + +Section: 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial + Submitter: David Abrahams Date: 2005-11-29
+View all issues with Pending NAD Editorial status.
+Duplicate of: 348
+Discussion:
++Where possible, tuple comparison operators <,<=,=>, and > ought to be +defined in terms of std::less rather than operator<, in order to +support comparison of tuples of pointers. +
+ + +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. +
+ + + + + +Section: 23.1 [container.requirements] Status: Dup + Submitter: Joaquín M López Muñoz Date: 2005-12-17
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Dup status.
+Duplicate of: 589
+Discussion:
++The iterator constructor X(i,j) for containers as defined in 23.1.1 and +23.2.2 does only require that i and j be input iterators but +nothing is said about their associated value_type. There are three +sensible +options: +
++The issue has practical implications, and stdlib vendors have +taken divergent approaches to it: Dinkumware follows 2, +libstdc++ follows 3. +
++The same problem applies to the definition of insert(p,i,j) for +sequences and insert(i,j) for associative contianers, as well as +assign. +
+ +[ +The following added by Howard and the example code was originally written by +Dietmar. +]
+ ++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.2 [diff.library] Status: NAD Editorial + Submitter: Martin Sebor Date: 2005-11-25
+View all issues with NAD 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 provides +54 standard macros from the C library, as shown in Table 95." While +table 95 does have 54 entries, since a couple of them (including the +NULL macro) are listed more than once, the actual number of macros +defined by the C++ Standard Library may not be 54. +
+ + +Proposed resolution:
++I propose we add <clocale> and <cstdlib> to Table 96 and remove the +number of macros from C.2, p2 and reword the sentence as follows: +
++ ++The C++ Standard library
provides 54 standard macros from+defines a number macros corresponding to those defined by the C +Standard library, as shown in Table 96. +
[ +Portland: Resolution is considered editorial. It will be incorporated into the WD. +]
+ + + + + + + +Section: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD + Submitter: Matt Austern Date: 2006-01-10
+View all other issues in [rand].
+View all issues with NAD status.
+Discussion:
++Paragraph 10 describes how a variate generator uses numbers produced by an +engine to pass to a generator. The sentence that concerns me is: "Otherwise, if +the value for engine_value_type::result_type is true and the value for +Distribution::input_type is false [i.e. if the engine produces integers and the +engine wants floating-point values], then the numbers in s_eng are divided by +engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the +engine is producing integers, both the numerator and the denominator are +integers and we'll be doing integer division, which I don't think is what we +want. 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: 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] Status: NAD + Submitter: Matt Austern Date: 2006-01-10
+View all issues with NAD status.
+Discussion:
++Class random_device "produces non-deterministic random numbers", using some +external source of entropy. In most real-world systems, the amount of available +entropy is limited. Suppose that entropy has been exhausted. What is an +implementation permitted to do? In particular, is it permitted to block +indefinitely until more random bits are available, or is the implementation +required to detect failure immediately? This is not an academic question. On +Linux a straightforward implementation would read from /dev/random, and "When +the entropy pool is empty, reads to /dev/random will block until additional +environmental noise is gathered." Programmers need to know whether random_device +is permitted to (or possibly even required to?) behave the same way. +
+ +[ +Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin +may block? +]
+ + ++See N2391 and +N2423 +for some further discussion. +
+ + +Proposed resolution:
++Adopt the proposed resolution in +N2423 (NAD). +
+ + + + + +Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD Editorial + Submitter: Matt Austern Date: 2006-01-10
+View all other issues in [rand.dist].
+View all issues with NAD Editorial status.
+Discussion:
++Paragraph 1 says that "A binomial distributon random distribution produces +integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and +p are the parameters of the distribution. OK, that tells us what t, p, and i +are. What's n? +
+ + +Proposed resolution:
++Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. +
+ +[ +Portland: Subsumed by N2111. +]
+ + + + + + +Section: 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial + Submitter: Paolo Carlini Date: 2006-01-30
+View all other issues in [cstdint.syn].
+View all issues with NAD Editorial status.
+Discussion:
++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 and uintptr_t, are not marked as such and +probably should, consistently with C99, 7.18.1.4. +
+ + +Proposed resolution:
++Change 18.3.1 [cstdint.syn]: +
+ ++ + + +... +typedef signed integer type intptr_t; // optional +... +typedef unsigned integer type uintptr_t; // optional +... +
Rationale:
+Recommend NAD and fix as editorial with the proposed resolution. + + + + + +Section: 18.2.1.5 [numeric.special] Status: NAD + Submitter: Howard Hinnant Date: 2006-01-29
+View all other issues in [numeric.special].
+View all issues with NAD status.
+Discussion:
++I believe we have a bug in the resolution of: +lwg 184 +(WP status). +
+ ++The resolution spells out each member of numeric_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't numeric_limits<bool>::traps be +true? +
+ + +Proposed resolution:
++Change 18.2.1.5p3: +
+ ++ ++-3- The specialization for bool shall 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 bool +value that will trap. +]
+ + + + + + + +Section: TR1 8.21 [tr.c99.boolh] Status: NAD Editorial + Submitter: Paolo Carlini Date: 2006-02-02
+View all issues with NAD 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: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: NAD Editorial + Submitter: Paolo Carlini Date: 2006-02-06
+View all other issues in [cstdint].
+View all issues with NAD 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 different +return types (lldiv_t and imaxdiv_t, respectively). Similar issue with +abs(_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 _Longlong +types (rightfully, because not moved over directly from C99), whereas +there is no equivalent in 8.11: the abs and div overloads for intmax_t +types appear only in the synopsis and are not described anywhere, in +particular 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 TR1 8.11.1 [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 TR1 8.11.2 [tr.c99.cinttypes.def]: +]
+ + ++ ++The header defines all functions, types, and macros the same as C99 +subclause 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 abs and div may well be equivalent to +those that take long long arguments. If so, the implementation is +responsible 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 template +type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef +for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would +need a non-normative note declaring that the types lldiv_t and imaxdiv_t +may not be unique if intmax_t==_longlong. +]
+ +
Section: 24.1.1 [input.iterators] Status: NAD Editorial + Submitter: David Abrahams Date: 2006-02-09
+View all other issues in [input.iterators].
+View all issues with NAD 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, but +that is clearly not meant to denote a member of type T. Also, there's +no description in 24.1.1 of what lowercase a means. IMO the above +should have been...Hah, a and b are already covered in 24.1/11, so maybe it +should have just been: +
+ + +Proposed resolution:
++Change 24.1.1p1: +
++ ++-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. +
[ +Portland: Editorial. +]
+ + + + + + + +Section: 20.1.2 [allocator.requirements] Status: NAD + Submitter: Sergey P. Derevyago Date: 2006-02-17
+View other active issues in [allocator.requirements].
+View all other issues in [allocator.requirements].
+View all issues with NAD status.
+Discussion:
++User-defined allocators without default constructor are not explicitly +supported by the standard but they can be supported just like std::vector +supports elements without default constructor. +
++As a result, there exist implementations that work well with such allocators +and implementations that don't. +
+ ++1) The standard doesn't explicitly state this intent but it should. In +particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator +instances 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 to +get_allocator()" topic. +
+ ++1) Explicitly state the intent to allow for user-defined allocators without +default constructor in 20.1.5 Allocator requirements. +
++2) Correct all the places, where a correct allocator object is available +through 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 on +another: +
+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 without +default stl_allocator() constructor. +
++The obvious way to solve the compile-time problems is to intentionally define +a 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 gets +called by operator+(const char*, const string&) under the current 21.3.7.1p2 +wording. +
+ + +Proposed resolution:
++
+ + +Rationale:
++Recommend NAD. operator+() with string already requires the desired +semantics of copying the allocator from one of the strings (lhs when there is a choice). +
+ + + + + +Section: 27.4.4.3 [iostate.flags] Status: Dup + Submitter: Seungbeom Kim Date: 2006-03-10
+View all other issues in [iostate.flags].
+View all issues with Dup status.
+Duplicate of: 272
+Discussion:
++Section: 27.4.4.3 [lib.iostate.flags] +
++Paragraph 4 says: +
+++ ++void clear(iostate state = goodbit); ++Postcondition: If rdbuf()!=0 then state == rdstate(); +otherwise rdstate()==state|ios_base::badbit. +
+
+The postcondition "rdstate()==state|ios_base::badbit" is parsed as +"(rdstate()==state)|ios_base::badbit", which is probably what the +committee meant. +
+ + + + +Rationale:
+ + + + + + +Section: 21.1 [char.traits] Status: NAD + Submitter: Jack Reeves Date: 2006-04-06
+View all other issues in [char.traits].
+View all issues with NAD status.
+Discussion:
++Currently, the Standard Library specifies only a declaration for template class +char_traits<> and requires the implementation provide two explicit +specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard +should require explicit specializations for all built-in character types, i.e. +char, wchar_t, unsigned char, and signed char. +
++I have put together a paper +(N1985) +that describes this in more detail and +includes all the necessary wording. +
+[ +Portland: Jack will rewrite +N1985 +to propose a primary template that will work with other integral types. +]
+ +[ +Toronto: issue has grown with addition of char16_t and char32_t. +]
+ + +[ +post Bellevue: +]
+ + +++ ++We suggest that Jack be asked about the status of his paper, and if it +is not forthcoming, the work-item be assigned to someone else. If no one +steps forward to do the paper before the next meeting, we propose to +make this NAD without further discussion. We leave this Open for now, +but our recommendation is NAD. +
++Note: the issue statement should be updated, as the Toronto comment has +already been resolved. E.g., char_traits specializations for char16_t +and char32_t are now in the working paper. +
+
[ +Sophia Antipolis: +]
+ + ++Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting. ++ + +
Proposed resolution:
+ + + + + +Section: 1.2 [intro.refs] Status: NAD Editorial + Submitter: Beman Dawes Date: 2006-04-08
+View all other issues in [intro.refs].
+View all issues with NAD Editorial status.
+Discussion:
++1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC +9899:1990, Programming languages - C. Should that be changed to ISO/IEC +9899: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: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD + Submitter: Howard Hinnant Date: 2006-04-11
+View all other issues in [rand].
+View all issues with NAD 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 give +this 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 longer +exists in the current WD. +]
+ + + +Rationale:
++NAD. Will be moot once +N2135 +is adopted. +
+ + + + + +Section: 23.1.5 [unord.req] Status: NAD + Submitter: Joaquín M López Muñoz Date: 2006-06-13
+View other active issues in [unord.req].
+View all other issues in [unord.req].
+View all issues with NAD status.
+Discussion:
++See +N2023 +for full discussion. +
+ + +Proposed resolution:
++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 to iterator, so +that +
+ ++ +iterator 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. +
+ + + +Rationale:
++N2023 +was discussed in Portland and the consensus was that there appears to be +no need for either change proposed in the paper. The consensus opinion +was that since the iterator could serve as its own proxy, there appears +to be no need for the change. In general, "converts to" is undesirable +because it interferes with template matching. +
+ ++Post Toronto: There does not at this time appear to be consensus with the Portland consensus. +
+ +[ +Bellevue: +]
+ + ++The Bellevue review of this issue reached consensus with the Portland +consensus, in contravention of the Toronto non-consensus. Common +implementations have the iterator readily available, and most common +uses depend on the iterator being returned. ++ + + + + + +
Section: 26.7 [c.math] Status: NAD + Submitter: Beman Dawes Date: 2006-06-15
+View all other issues in [c.math].
+View all issues with NAD status.
+Discussion:
++There is no div() function for unsigned integer types. +
++There are several possible resolutions. The simplest one is noted below. Other +possibilities 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 because +the signed version exist just to define the implementation-defined behavior +of signed integer division. Unsigned integer division has no implementation-defined +behavior and thus does not need this treatment. + + + + + +Section: 26.7 [c.math] Status: NAD + Submitter: Beman Dawes Date: 2006-06-15
+View all other issues in [c.math].
+View all issues with NAD status.
+Discussion:
++There is no pow() 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 have double pow(integral, integral) from 26.7 [c.math] p11. + + + + + +Section: D.7.2.1 [depr.istrstream.cons] Status: NAD Editorial + Submitter: Martin Sebor Date: 2006-06-22
+View all issues with NAD Editorial status.
+Discussion:
+
+
+The iststream(char*, streamsize) ctor is in the class
+synopsis in D.7.2 but its signature is missing in the description
+below (in D.7.2.1).
+
+
Proposed resolution:
+
+
+This seems like a simple editorial issue and the missing signature can
+be added to the one for const char* in paragraph 2.
+
+
[ +post Oxford: Noted that it is already fixed in +N2284 +]
+ + + + + + +Section: 20.5 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial + Submitter: Beman Dawes Date: 2006-08-10
+View all other issues in [meta].
+View all issues with NAD Editorial status.
+Discussion:
++20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type +traits 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 Wording +also 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 the +current working draft. +]
+ + + + + + + +Section: 18.2.1.2 [numeric.limits.members] Status: NAD Editorial + Submitter: whyglinux Date: 2006-08-08
+View all other issues in [numeric.limits.members].
+View all issues with NAD 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 the +representation." +
+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 for +value types." +
+Integer types (which are bool, char, wchar_t, and the signed and +unsigned integer types) and arithmetic types (which are integer and +floating types) are all built-in types and thus there are no +non-built-in (that is, user-defined) integer or arithmetic types. Since +the redundant "built-in" in the above 2 sentences can mislead that +there 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 the +representation." +
+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 for +value types." +
Rationale:
++Recommend NAD / Editorial. The proposed resolution is accepted as editorial. +
+ + + + + +Section: 27.8.1.9 [ifstream.members] Status: NAD Editorial + Submitter: Christopher Kohlhoff Date: 2006-08-17
+View all other issues in [ifstream.members].
+View all issues with NAD 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 the +filebuf on success, null on failure, so I think it is meant to +say "if that function returns a null pointer". Oddly, it is +correct for basic_ofstream. +
+ + +Proposed resolution:
++Change 27.8.1.9 [ifstream.members], p5: +
+ ++ ++Effects: Calls rdbuf()->close() and, if that function +fails (returns
falsea null pointer), +calls setstate(failbit) (which may throw ios_base::failure +(27.4.4.3)). +
+Change 27.8.1.17 [fstream.members], p5: +
+ ++ + + ++Effects: Calls rdbuf()->close() and, if that function +fails (returns
falsea null pointer), +calls setstate(failbit) (which may throw ios_base::failure +(27.4.4.3)). +
[ +Kona (2007): Proposed Disposition: NAD, Editorial +]
+ + + + + +Section: 20.1.1 [utility.arg.requirements] Status: Pending NAD Editorial + Submitter: Niels Dekker Date: 2006-11-02
+View other active issues in [utility.arg.requirements].
+View all other issues in [utility.arg.requirements].
+View all issues with Pending NAD Editorial status.
+Discussion:
++It seems undesirable to define the Swappable requirement in terms of +CopyConstructible and Assignable requirements. And likewise, once the +MoveConstructible and MoveAssignable requirements (N1860) have made it +into the Working Draft, it seems undesirable to define the Swappable +requirement in terms of those requirements. Instead, it appears +preferable to have the Swappable requirement defined exclusively in +terms of the existence of an appropriate swap function. +
++Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) +says: +
++I can think of three disadvantages of this definition: ++The Swappable requirement is met by satisfying one or more of the +following conditions:
++
+- +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +
+- +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. +
+
+A client might want to stop T from satisfying the Swappable +requirement, because swapping by means of copy construction and +assignment might throw an exception, and she might find a throwing +swap unacceptable for her type. On the other hand, she might not feel +the need to fully implement her own swap function for this type. In +this case she would want to be able to simply prevent algorithms that +would swap objects of type T from being used, e.g., by declaring a +swap function for T, and leaving this function purposely undefined. +This would trigger a link error, if an attempt would be made to use +such an algorithm for this type. For most standard library +implementations, this practice would indeed have the effect of +stopping T from satisfying the Swappable requirement. +
++While I'm aware about the fact that people have mixed feelings about +providing a specialization of std::swap, it is well-defined to do so. +It sounds rather counter-intuitive to say that T is not Swappable, if +it has a valid and semantically correct specialization of std::swap. +Also in practice, providing such a specialization will have the same +effect as satisfying the Swappable requirement. +
++I'm aware that the intention of the Draft is to prefer calling the +swap function of T over doing copy construction and assignments. Still +in my opinion, it would be better to make this clear in the wording of +the definition of Swappable. +
++I would like to have the Swappable requirement defined in such a way +that the following code fragment will correctly swap two objects of a +type T, if and only if T is Swappable: +
+using std::swap; + swap(t, u); // t and u are of type T. ++
+This is also the way Scott Meyers recommends calling a swap function, +in Effective C++, Third Edition, item 25. +
++Most aspects of this issue have been dealt with in a discussion on +comp.std.c++ about the Swappable requirement, from 13 September to 4 +October 2006, including valuable input by David Abrahams, Pete Becker, +Greg Herlihy, Howard Hinnant and others. +
+ +Proposed resolution:
++Change section 20.1.4 [lib.swappable] as follows: +
++ + ++The Swappable requirement is met by satisfying +
+one or more of the following conditions:+the following condition:+ +
+- +
+T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1);+- +
++T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. ++T is Swappable if an unqualified function call swap(t,u) is valid +within the namespace std, and has the semantics described in Table 33. +
Rationale:
++Recommend NAD. Concepts, specifically +N2082 +and +N2084, +will essentially rewrite this section and provide the desired semantics. +
+ + + + + +Section: 21.5 [c.strings] Status: NAD Editorial + Submitter: Bo Persson Date: 2006-12-11
+View all other issues in [c.strings].
+View all issues with NAD 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: 17 [library] Status: Pending NAD Editorial + Submitter: Martin Sebor Date: 2007-01-20
+View all other issues in [library].
+View all issues with Pending NAD Editorial status.
+Discussion:
+
+
+Many member functions of basic_string are overloaded,
+with some of the overloads taking a string argument,
+others value_type*, others size_type, and
+others still iterators. Often, the requirements on one of
+the overloads are expressed in the form of Effects,
+Throws, and in the Working Paper
+(N2134)
+also Remark clauses, while those on the rest of the overloads
+via a reference to this overload and using a Returns clause.
+
+
+
+ +The difference between the two forms of specification is that per +17.3.1.3 [structure.specifications], p3, an Effects clause specifies +"actions performed by the functions," i.e., its observable +effects, while a Returns clause is "a description of the +return value(s) of a function" that does not impose any +requirements on the function's observable effects. + ++
+ +Since only Notes are explicitly defined to be informative and +all other paragraphs are explicitly defined to be normative, like +Effects and Returns, the new Remark clauses also +impose normative requirements. + ++
+ +So by this strict reading of the standard there are some member +functions ofbasic_string that are required to throw an
+exception under some conditions or use specific traits members while
+many other otherwise equivalent overloads, while obliged to return the
+same values, aren't required to follow the exact same requirements
+with regards to the observable effects.
+
+ +
+ +Here's an example of this problem that was precipitated by the change +from informative Notes to normative Remarks (presumably made to +address 424): + ++
+ +In the Working Paper,find(string, size_type) contains a
+Remark clause (which is just a Note in the current
+standard) requiring it to use traits::eq().
+
+ +
+ +find(const charT *s, size_type pos) is specified to
+return find(string(s), pos) by a Returns clause
+and so it is not required to use traits::eq(). However,
+the Working Paper has replaced the original informative Note
+about the function using traits::length() with a
+normative requirement in the form of a Remark. Calling
+traits::length() may be suboptimal, for example when the
+argument is a very long array whose initial substring doesn't appear
+anywhere in *this.
+
+ +
+ +Here's another similar example, one that existed even prior to the +introduction of Remarks: + ++
+ + insert(size_type pos, string, size_type, size_type) is
+required to throw out_of_range if pos >
+size().
+
+ +
+ +insert(size_type pos, string str) is specified to return
+insert(pos, str, 0, npos) by a Returns clause and
+so its effects when pos > size() are strictly speaking
+unspecified.
+
+
+ + +I believe a careful review of the current Effects and +Returns clauses is needed in order to identify all such +problematic cases. In addition, a review of the Working Paper should +be done to make sure that the newly introduced normative Remark +clauses do not impose any undesirable normative requirements in place +of the original informative Notes. + +
+[ +Batavia: Alan and Pete to work. +]
+ + +[ +Bellevue: Marked as NAD Editorial. +]
+ + +[ +Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. +Reopened. +]
+ + + + +Proposed resolution:
++
+ + + + + +Section: 17.3.1.3 [structure.specifications] Status: NAD Editorial + Submitter: Martin Sebor Date: 2007-01-20
+View all other issues in [structure.specifications].
+View all issues with NAD Editorial status.
+Discussion:
++ +The Remark clauses newly introduced into the Working Paper +(N2134) +are not mentioned in 17.3.1.3 [structure.specifications] where we list the +meaning of Effects, Requires, and other clauses (with +the exception of Notes which are documented as informative in +17.3.1.1 [structure.summary], p2, and which they replace in many cases). + +
++ +Propose add a bullet for Remarks along with a brief description. + +
+[ +Batavia: Alan and Pete to work. +]
+ + +[ +Bellevue: Already resolved in current working paper. +]
+ + + +Proposed resolution:
++
+ + + + + +Section: 18.5.1.1 [new.delete.single] Status: NAD + Submitter: P.J. Plauger Date: 2007-01-23
+View all other issues in [new.delete.single].
+View all issues with NAD status.
+Discussion:
++I recognize the need for nothrow guarantees in the exception reporting +mechanism, but I strongly believe that implementors also need an escape hatch +when memory gets really low. (Like, there's not enough heap to construct and +copy exception objects, or not enough stack to process the throw.) I'd like to +think we can put this escape hatch in 18.5.1.1 [new.delete.single], +operator new, but I'm not sure how to do it. We need more than a +footnote, but the wording has to be a bit vague. The idea is that if +new can't allocate something sufficiently small, it has the right to +abort/call terminate/call unexpected. +
+ +[ +Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within +its resource limits", so no further escape hatch is necessary. +]
+ + + +Proposed resolution:
++
+ + + + + +Section: 20.6.15.2.5 [func.wrap.func.targ] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-02-03
+View all issues with NAD Editorial status.
+Discussion:
++20.6.15.2.5 [func.wrap.func.targ], p4 says: +
++ ++Returns: If type() == typeid(T), a pointer to the stored +function target; otherwise a null pointer. +
Proposed resolution:
++Change 20.6.15.2.5 [func.wrap.func.targ], p4: +
+ ++ ++Returns: If
type()target_type() == typeid(T) && typeid(T) != +typeid(void), a pointer to the stored function target; +otherwise a null pointer. +
[ +Pete: Agreed. It's editorial, so I'll fix it. +]
+ + + + + + + +Section: 26.5.2.3 [valarray.access] Status: NAD Editorial + Submitter: Bo Persson Date: 2007-02-11
+View all other issues in [valarray.access].
+View all issues with NAD 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: 26.7 [c.math] Status: NAD Editorial + Submitter: Bo Persson Date: 2007-02-13
+View all other issues in [c.math].
+View all issues with NAD Editorial status.
+Discussion:
++26.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 26.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: 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] Status: NAD + Submitter: Daniel Krügler Date: 2007-02-17
+View all other issues in [istream::extractors].
+View all issues with NAD status.
+Discussion:
++There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13 +from 14882:2003(E), namely 64 and 413. +
+ ++Even with these proposed corrections, already maintained in N2134, +I have the feeling, that the current wording does still not properly +handle the "exceptional" situation. The combination of para 14 +
+ ++ ++"[..] Characters are extracted and inserted until +any 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), +which +may throw ios_base::failure (27.4.4.3). If it inserted no characters +because it caught an exception thrown while extracting characters +from *this and failbit is on in exceptions() (27.4.4.3), then the +caught +exception is rethrown." +
+both in N2134 seems to imply that any exception, which occurs +*after* at least one character has been inserted is caught and lost +for +ever. It seems that even if failbit is on in exceptions() rethrow is +not +allowed due to the wording "If it inserted no characters because it +caught an exception thrown while extracting". +
+ ++Is this behaviour by design? +
+ ++I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9 +(also +N2134) does not demonstrate such an exception-loss-behaviour. +On the other side, I wonder concerning several subtle differences +compared 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 such +an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14. +
+ ++2) Paragraph 9 says: +
+ ++ ++"If the function inserts no characters, it calls setstate(failbit) +(which +may throw ios_base::failure (27.4.4.3)). If an exception was thrown +while extracting a character, the function sets failbit in error +state, +and if failbit is on in exceptions() the caught exception is +rethrown." +
+The sentence starting with "If an exception was thrown" seems to +imply that such an exception *should* be caught before. +
+ + +Proposed resolution:
++(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence +
+ ++ ++If the function inserts no characters, it calls +setstate(failbit), which may throw ios_base::failure +(27.4.4.3). If
it inserted no characters because it caught an +exception thrown while extracting characters from *this+an exception was thrown while extracting a character from +*this, the function sets failbit in error state, +and failbit is on in exceptions() (27.4.4.3), then the +caught exception is rethrown. +
+(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: +
+ +++ + + ++Gets characters from sb and inserts them in *this. +Characters are read from sb and inserted until any of the +following 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 which +case the exception is caught).
+
Rationale:
+This extractor is described as a formatted input function so the +exception behavior is already specified. There is additional behavior +described in this section that applies to the case in which failbit is +set. This doesn't contradict the usual exception behavior for formatted +input functions because that applies to the case in which badbit is set. + + + + + +Section: 27.6.4 [ext.manip] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-02-18
+View other active issues in [ext.manip].
+View all other issues in [ext.manip].
+View all issues with NAD Editorial status.
+Discussion:
++The function f in para 4 (27.6.4 [ext.manip]) references an unknown strm +in the following line: +
+ ++ + +mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon); +
Proposed resolution:
++Change 27.6.4 [ext.manip], p4: +
+ ++ +mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon); +
[ +Oxford: Editorial. +]
+ + + + + + + +Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-02-20
+View all other issues in [ifstream.members].
+View all issues with NAD Editorial status.
+Discussion:
++The standard wording of N2134 has extended the 14882:2003(E) +wording for the ifstream/ofstream/fstream open function to fix +a long standing problem, see 409. +
+ ++Now it's properly written as +
+ ++ ++"If that function does not return a null pointer calls clear(), +otherwise +calls 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 and +ofstream (because clear *does* indeed modify the error state) and +should be removed (Interestingly fstream itself never had these, +although +they where needed for that time). +
+ + +Proposed resolution:
++In 27.8.1.9 [ifstream.members], remove footnote: +
+ ++ ++
334) A successful open does not change the error state.+
+In 27.8.1.13 [ofstream.members], remove footnote: +
+ ++ + + + + + ++
335) A successful open does not change the error state.+
Section: 28.10 [re.results] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-02-26
+View all other issues in [re.results].
+View all issues with NAD Editorial status.
+Discussion:
++According to the description given in 28.10 [re.results]/2 the class template +match_results "shall satisfy the requirements of a Sequence, [..], +except that only operations defined for const-qualified Sequences +are supported". +Comparing the provided operations from 28.10 [re.results]/3 with the +sequence/container tables 80 and 81 one recognizes the following +missing 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 bidirectional +iterators. Aren't these supported by match_result? This is not +explicitely expressed, but it's somewhat implied by two arguments: +
++(a) Several typedefs delegate to +iterator_traits<BidirectionalIterator>. +
++(b) The existence of const_reference operator[](size_type n) const +implies even random-access iteration. +I also suggest, that match_result should explicitly mention, +which minimum iterator category is supported and if this does +not include random-access the existence of operator[] is +somewhat 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 the match_results synopsis after end() in 28.10 [re.results] +para 3: +
+ ++ +const_iterator cbegin() const; +const_iterator cend() const; +
+In section 28.10.3 [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 in +N2409 +except removing the entry in the table container requirements. Moved to Review. +]
+ + +[ +Bellevue: Proposed wording now in the WP. +]
+ + + + + +Section: 28.11.3 [re.alg.search] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-02-26
+View all issues with NAD Editorial status.
+Discussion:
++28.11.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 category +the parameter iterator belongs to. This is inconsistent +to the preceding declaration in the synopsis section +28.4 [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.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with +"BidirectionalIterator" +
+ ++ + +template <class+iteratorBidirectionalIterator, 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 of +type match_results<
+iterator+BidirectionalIterator> and then returning the result +of regex_search(first, last, what, e, flags). +
Rationale:
+Applied to working paper while issue was still in New status. + + + + + +Section: 28.12.1.1 [re.regiter.cnstr] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-03-03
+View all issues with NAD Editorial status.
+Discussion:
++In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: +
+ +++ ++Effects: Initializes begin and end to point to the beginning and the +end of the target sequence, sets pregex to &re, sets flags to f,[..] +
+There are two issues with this description: +
+ +Proposed resolution:
++In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by +
+ ++ + + + + ++Effects: Initializes begin and end to point to +the beginning and the end of the target sequence designated by the +iterator range [a, b), sets pregex to +&re, sets flags to
f+m, then calls regex_search(begin, end, match, +*pregex, flags). If this call returns false the +constructor sets *this to the end-of-sequence iterator. +
Section: 28.12.2.1 [re.tokiter.cnstr] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-03-03
+View all other issues in [re.tokiter.cnstr].
+View all issues with NAD Editorial status.
+Discussion:
++In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration +and 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 an +unknown value R, which should be N. +
++2) Paragraph 2 of the same section says in its last sentence: +
+ ++ ++The third constructor initializes the member subs to hold a +copy of the sequence of integer values pointed to by the iterator range +[&submatches, &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 N to 0, and +position to position_iterator(a, b, re, f). +
+where a non-existing parameter "f" is mentioned, which must be +replaced +by the parameter "m". +
+ + +Proposed resolution:
++Change 28.12.2.1 [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.12.2.1 [re.tokiter.cnstr]/2: +
+ ++ ++Effects: The first constructor initializes the member +subs to hold the single value submatch. The second +constructor initializes the member subs to hold a copy of the +argument submatches. The third constructor initializes the +member subs to hold a copy of the sequence of integer values +pointed to by the iterator range [&submatches, &submatches + +
RN). +
+Change 28.12.2.1 [re.tokiter.cnstr]/3: +
+ ++ + + + + + ++Each constructor then sets N to 0, and +position to position_iterator(a, b, re,
f+m). If position is not an end-of-sequence +iterator the constructor sets result to the address of the +current match. Otherwise if any of the values stored in subs is +equal to -1 the constructor sets *this to a suffix +iterator that points to the range [a, b), otherwise the +constructor sets *this to an end-of-sequence iterator. +
Section: 1.2 [intro.refs] Status: NAD + Submitter: Alisdair Meredith Date: 2007-03-08
+View all other issues in [intro.refs].
+View all issues with NAD status.
+Discussion:
++
+++ ++1.2 [intro.refs] Normative references +
+ ++The following standards contain provisions which, through reference in +this text, constitute provisions of this Interna- tional Standard. At +the time of publication, the editions indicated were valid. All +standards are subject to revision, and parties to agreements based on +this International Standard are encouraged to investigate the +possibility of applying the most recent editions of the standards +indicated below. Members of IEC and ISO maintain registers of currently +valid International Standards. +
+ ++
+- Ecma International, ECMAScript Language Specification, Standard +Ecma-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: C +Integrity
+- 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 System +Interface (POSIX)
+- ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet +Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual +Plane
+
+I'm not sure how many of those reserve naming patterns that might affect +us, 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 the +individual names themselves - although we may want to list C keywords +that are valid identifiers in C++ but likely to cause trouble in shared +headers (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 a
+discussion of the system error proposal, where it was pointed out an all-caps
+identifier starting with a capital E conflicted with reserved macro names for
+both Posix and C. I had absolutely no idea of this rule, and suspect I was
+not the only one in the room.
+
+Resolution will require someone with access to all the listed documents to
+research their respective name reservation rules, or people with access to
+specific 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: 26.4.2 [rand.synopsis] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-03-08
+View all other issues in [rand.synopsis].
+View all issues with NAD Editorial status.
+Discussion:
++26.4.2 [rand.synopsis] the header <random> synopsis +contains an unreasonable closing curly brace inside the +subtract_with_carry_engine declaration. +
+ + +Proposed resolution:
++Change the current declaration in 26.4.2 [rand.synopsis] +
+ ++ + +template <class UIntType, size_t w}, size_t s, size_t r> +class subtract_with_carry_engine; +
[ +Pete: Recommends editorial. +]
+ + + + + +Section: 17.4.2.1 [using.headers] Status: NAD + Submitter: Gennaro Prota Date: 2007-03-14
+View all issues with NAD status.
+Discussion:
++17.4.2.1 [using.headers] states: +
+ ++ ++A translation unit shall include a header only outside of any +external declaration or definition, [...] +
+I see three problems with this requirement: +
+ +The C++ standard doesn't define what an "external declaration" or +an "external definition" are (incidentally the C99 standard does, and +has a sentence very similar to the above regarding header inclusion). +
+I think the intent is that the #include directive shall lexically +appear outside *any* declaration; instead, when the issue was pointed +out on comp.std.c++ at least one poster interpreted "external +declaration" as "declaration of an identifier with external linkage". +If this were the correct interpretation, then the two inclusions below +would 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; is +this the intent? It was pointed out on comp.std.c++ (by several +posters) 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 is +interesting and affects one of the points in the explicit namespaces +proposal (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" + } +
Proposed resolution:
++
+ + +Rationale:
+We believe that the existing language does not cause any real confusion +and any new formulation of the rules that we could come up with are +unlikely to be better than what's already in the standard. + + + + + +Section: 20.6 [function.objects] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-03-19
+View all other issues in [function.objects].
+View all issues with NAD Editorial status.
+Discussion:
++The header <functional> synopsis in 20.6 [function.objects] +contains the following two free comparison operator templates +for the function class template +
+ ++ +template<class Function1, class Function2> +void operator==(const function<Function1>&, const function<Function2>&); +template<class Function1, class Function2> +void operator!=(const function<Function1>&, const function<Function2>&); +
+which are nowhere described. I assume that they are relicts before the +corresponding two private and undefined member templates in the function +template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free +function templates should be removed, because using an undefined entity +would lead to an ODR violation of the user. +
+ + +Proposed resolution:
++Remove the above mentioned two function templates from +the header <functional> synopsis (20.6 [function.objects]) +
+ ++ + + +template<class Function1, class Function2> +void operator==(const function<Function1>&, const function<Function2>&); +template<class Function1, class Function2> +void operator!=(const function<Function1>&, const function<Function2>&);+
Rationale:
+Fixed by +N2292 +Standard Library Applications for Deleted Functions. + + + + + +Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: NAD + Submitter: Cosmin Truta Date: 2007-04-05
+View other active issues in [facet.num.get.virtuals].
+View all other issues in [facet.num.get.virtuals].
+View all issues with NAD status.
+Discussion:
+
+From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
+that the value read from a stream must be stored
+even if the placement of thousands separators does not conform to the
+grouping() specification from the numpunct facet.
+Since incorrectly-placed thousands separators are flagged as an extraction
+failure (by the means of failbit), we believe it is better not
+to store the value. A consistent strategy, in which any kind of extraction
+failure leaves the input item intact, is conceptually cleaner, is able to avoid
+corner-case traps, and is also more understandable from the programmer's point
+of 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 its +stream. If no error was encountered, the value read is assigned through v; +otherwise, v is left unchanged." +
+This statement implies that rdstate() alone is sufficient to
+determine whether an extracted value is to be assigned to the input item
+val passed to do_get. However, this is in disagreement
+with the current C++ Standard. The above-mentioned assumption is true in all
+cases, except when there are mismatches in digit grouping. In the latter case,
+the parsed value is assigned to val, and, at the same time, err
+is assigned to ios_base::failbit (essentially "lying" about the
+success of the operation). Is this intentional? The current behavior raises
+both consistency and usability concerns.
+
+Although digit grouping is outside the scope of scanf (on which
+the virtual methods of num_get are based), handling of grouping
+should be consistent with the overall behavior of scanf. The specification of
+scanf makes a distinction between input failures and matching
+failures, and yet both kinds of failures have no effect on the input items
+passed to scanf. A mismatch in digit grouping logically falls in
+the category of matching failures, and it would be more consistent, and less
+surprising to the user, to leave the input item intact whenever a failure is
+being signaled.
+
+The extraction of bool is another example outside the scope of
+scanf, and yet consistent, even in the event of a successful
+extraction of a long but a failed conversion from
+long to bool.
+
+Inconsistency is further aggravated by the fact that, when failbit is set,
+subsequent extraction operations are no-ops until failbit is
+explicitly cleared. Assuming that there is no explicit handling of
+rdstate() (as in cin>>i>>j) it is
+counter-intuitive to be able to extract an integer with mismatched digit
+grouping, but to be unable to extract another, properly-formatted integer
+that immediately follows.
+
+Moreover, setting failbit, and selectively assigning a value to
+the input item, raises usability problems. Either the strategy of
+scanf (when there is no extracted value in case of failure), or
+the strategy of the strtol family (when there is always an
+extracted value, and there are well-defined defaults in case of a failure) are
+easy to understand and easy to use. On the other hand, if failbit
+alone cannot consistently make a difference between a failed extraction, and a
+successful but not-quite-correct extraction whose output happens to be the same
+as 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 casual
+reader, but it has also been confusing to some book authors. Besides
+Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
+Langer and Kreft) are describing the same mistaken assumption. Although books
+are not to be used instead of the standard reference, the readers of these
+books, as well as the people who are generally familiar to scanf,
+are even more likely to misinterpret the standard, and expect the input items
+to remain intact when a failure occurs.
+
Proposed resolution:
+ ++Change 22.2.2.1.2 [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 of +N2327 +makes this resolution obsolete. + + + + + +Section: 17.3.1.3 [structure.specifications] Status: NAD + Submitter: Thomas Plum Date: 2007-04-16
+View all other issues in [structure.specifications].
+View all issues with NAD status.
+Discussion:
++17.3.1.3 [structure.specifications] para 5 says +
+ ++ ++-5- Complexity requirements specified in the library +clauses are upper bounds, and implementations that provide better +complexity guarantees satisfy the requirements. +
+The following +objection has been raised: +
+ ++ ++The library clauses suggest general +guidelines regarding complexity, but we have been unable to discover +any absolute hard-and-fast formulae for these requirements. Unless +or until the Library group standardizes specific hard-and-fast +formulae, 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 been +identified, and big-O notation always involves constant factors. + + + + + +Section: 28.12.2 [re.tokiter] Status: Pending NAD Editorial + Submitter: Eric Niebler Date: 2007-06-02
+View all other issues in [re.tokiter].
+View all issues with Pending NAD Editorial status.
+Discussion:
++28.12.2 [re.tokiter], p3 says: +
+++ ++After it is constructed, the iterator finds and stores a value +match_results<BidirectionalIterator> position and sets the +internal count N to zero. +
+
+Should read: +
+ +++ ++After it is constructed, the iterator finds and stores a value +
+match_resultsregex_iterator<BidirectionalIterator, charT, traits> +position and sets the internal count N to zero. +
[ +John adds: +]
+ + ++ + + ++Yep, looks like a typo/administrative fix to me. +
Proposed resolution:
++
+ + + + + +Section: 28.10 [re.results] Status: NAD Editorial + Submitter: Nozomu Katoo Date: 2007-05-27
+View all other issues in [re.results].
+View all issues with NAD Editorial status.
+Discussion:
++In 28.4 [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 of +match_results should be used in comparison) are not described in any +following sections. +
+ +[ +John adds: +]
+ + ++ ++That looks like a bug: operator== should return true only if +the two objects refer to the same match - ie if one object was constructed as a +copy of the other. +
[ +Kona (2007): Bill and Pete to add minor wording to that proposed in +N2409. +]
+ + + +Proposed resolution:
++Add a new section after 28.10.6 [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: true only 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. +]
+ + + + + +Section: 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] Status: NAD + Submitter: Beman Dawes Date: 2007-06-14
+View all issues with NAD status.
+Discussion:
++The standard library uses the operator unspecified-bool-type() const idiom in +five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity +for example) the returned value is constrained to disallow +unintended conversions to int. The standardese is +
+++The return type shall not be convertible to int. +
+This constraint is omitted for unique_ptr and shared_ptr. It should be added for those. +
+ +[ +Bellevue: +]
+ + ++Close as NAD. Accepting paper +N2435 +makes it irrelevant. ++ + + +
Proposed resolution:
++To the Returns paragraph for operator unspecified-bool-type() +const +of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and +20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence: +
++ + ++The return type shall not be convertible to int. +
[ +Kona (2007): Uncertain if nullptr will address this issue. +]
+ + + + + +Section: 26.7 [c.math] Status: NAD Editorial + Submitter: Niels Dekker Date: 2007-06-10
+View all other issues in [c.math].
+View all issues with NAD Editorial status.
+Discussion:
++Quoting the latest draft (n2135), 26.7 [c.math]: +
+ ++++The added signatures are: +
++long abs(long); // labs() +long abs(long long); // llabs() +
+Shouldn't abs(long long) have long long as return type? +
+ + +Proposed resolution:
++Change 26.7 [c.math]: +
++ + +long long abs(long long); // llabs() +
Rationale:
+Had already been fixed in the WP by the time the LWG reviewed this. + + + + + +Section: 19.4 [syserr] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-06-24
+View other active issues in [syserr].
+View all other issues in [syserr].
+View all issues with NAD Editorial status.
+Discussion:
++The most recent state of +N2241 +as well as the current draft +N2284 +(section 19.4 [syserr], p.2) proposes a +new +enumeration type posix_errno immediatly in the namespace std. One of +the enumerators has the name invalid_argument, or fully qualified: +std::invalid_argument. This name clashes with the exception type +std::invalid_argument, see 19.1 [std.exceptions]/p.3. This clash makes +e.g. the following snippet invalid: +
+ +#include <system_error>
+#include <stdexcept>
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
++I propose that this enumeration type (and probably the remaining parts +of +<system_error> as well) should be moved into one additional inner +namespace, e.g. sys or system to reduce foreseeable future clashes +due +to the great number of members that std::posix_errno already contains +(Btw.: Why has the already proposed std::sys sub-namespace from +N2066 +been rejected?). A further clash candidate seems to be +std::protocol_error +(a reasonable name for an exception related to a std network library, +I guess). +
+ ++Another possible resolution would rely on the proposed strongly typed +enums, +as described in N2213. +But maybe the forbidden implicit conversion to integral types would +make +these enumerators less attractive in this special case? +
+ + +Proposed resolution:
++Fixed by issue 7 of N2422. +
+ + + + + + +Section: 18.7.5 [propagation] Status: NAD + Submitter: Jens Maurer Date: 2007-07-20
+View other active issues in [propagation].
+View all other issues in [propagation].
+View all issues with NAD status.
+Discussion:
+ ++From the Toronto Core wiki: +
+ ++What do you mean by "null pointer constant"? How do you guarantee that +exception_ptr() == 1 doesn't work? Do you even want to prevent that? +What's the semantics? What about void *p = 0; exception_ptr() == p? +Maybe disallow those in the interface, but how do you do that with +portable C++? Could specify just "make it work". +
+ ++Peter's response: +
+ ++null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it +work", can be implemented as assignment operator taking a unique pointer +to 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, and +while API is clearly implementable there is no need to spell out +implementation details. +
+
Proposed resolution:
++
+ + + + + +Section: 26.5.2.3 [valarray.access] Status: Pending NAD Editorial + Submitter: Daniel Krügler Date: 2007-08-27
+View all other issues in [valarray.access].
+View all issues with Pending NAD Editorial status.
+Discussion:
++Since the return type of valarray's operator[] const overload has been +changed to const T& as described in 389 several paragraphs of +the section 26.5.2.3 [valarray.access] are now +incompletely +specified, because many requirements and guarantees should now also +apply to the const overload. Most notably, the address and reference +guarantees should be extended to the const overload case. +
+ + +Proposed resolution:
++Change 26.5.2.3 [valarray.access]: +
+ +++ + + + + + ++-1-
+ +When applied to a constant array, the subscript operator returns a +reference to the corresponding element of the array. When applied to a +non-constant array, tThe subscript operator returns a +reference to the corresponding element of the array. ++-3- The expression &a[i+j] == &a[i] + j evaluates as true for all size_t i +and size_t j such that i+j is less +than the length of the
+ +non-constantarray a. ++-4- Likewise, the expression &a[i] != &b[j] evaluates +as true for any two
+ +non-constantarrays a and +b and for any size_t i and size_t j such that +i is less than the length of a and j is less +than the length of b. This property indicates an absence of +aliasing and may be used to advantage by optimizing +compilers.281) ++-5- The reference returned by the subscript operator for an
+ +non-constantarray is guaranteed to be valid until +the member function resize(size_t, T) (26.5.2.7) is called for that array or until the lifetime +of that array ends, whichever happens first. +
Section: 23.1.3 [sequence.reqmts] Status: Pending NAD Editorial + Submitter: David Abrahams Date: 2007-09-16
+View all other issues in [sequence.reqmts].
+View all issues with Pending NAD Editorial status.
+Discussion:
++Table 90: (Optional sequence container operations) states the +"assertion note pre/post-condition" of operator[] 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 +
Section: 26.4.1.3 [rand.req.eng] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all other issues in [rand.req.eng].
+View all issues with NAD status.
+Discussion:
++The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any +arithmetic type as a seed, which is then casted to the engine's result_type and subsequently +used for seeding the state of the engine. The requirement stated as "Creates an engine with +initial state determined by static_cast<X::result_type>(s)" forces random number engines +to either use a seeding method that completely depends on the result_type (see the discussion +of seeding for the mersenne_twister_engine in point T2 above) or at least to throw away "bits +of randomness" in the seed value if the result_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. +
+ ++Posible resolution: I propose to change the wording to a version similar to "Creates an +engine with initial state determined by static_cast<UintType>(s), where UintType is an +implementation specific unsigned integer type." +
+ ++Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types. +
+ ++Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified. +
+ ++See N2424 +for further discussion. +
+ +[ +Stephan Tolksdorf adds pre-Bellevue: +]
+ + +++ ++In reply to the discussion in +N2424 +regarding this issue: +
++The descriptions of all engines and engine adaptors given in sections +26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete +types of the integer arguments for seeding. Hence, relaxing the general +requirement in 26.4.1.3 [rand.req.eng] would not affect portability and +reproducibility of the standard library. Furthermore, it is not clear to +me 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 other +random number engines that do not have to cast all arithmetic seed +arguments to their result_types. +
+
[ +Bellevue: +]
+ + ++Propose close NAD for the reasons given in N2424. ++ + + + +
Proposed resolution:
++See N2424 +for further discussion. +
+ +[ +Stephan Tolksdorf adds pre-Bellevue: +]
+ + +++ + + + + + ++Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3 +
+ ++Creates an engine with initial state determined by ++ +static_cast<X::result_type>(s)++Similarly, change 26.4.1.4 [rand.req.adapt]/3 e) +
+ ++When X::X is invoked with+ +an X::result_typevalue s +of arithmetic type (3.9.1), ... +
Section: 26.4.1.4 [rand.req.adapt] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all issues with NAD status.
+Discussion:
++If an engine adaptor is invoked with an argument of type seed_seq, then all base +engines are specified to be seeded with this seed_seq. As seed_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 of +seed_seq does not allow for a generally satisfying specification. +
+ ++Posssible resolution: [As above] +
+ ++See N2424 +for further discussion. +
+ +[ +Bellevue: +]
+ + ++Close NAD for the reasons given in N2424. ++ + + +
Proposed resolution:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 26.4.7.1 [rand.util.seedseq] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View other active issues in [rand.util.seedseq].
+View all other issues in [rand.util.seedseq].
+View all issues with NAD status.
+Discussion:
++The proper way to seed random number engines seems to be the most frequently +discussed issue of the 26.4 [rand] proposal. While the new seed_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: +
+ ++Supplement the seed_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 cause +this problem to be solved by that route. ++ + +
Proposed resolution:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 26.4.1.5 [rand.req.dist] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all issues with NAD status.
+Discussion:
++The requirement "P shall have a declaration of the form typedef 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:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all issues with NAD status.
+Discussion:
++In my opinion the choice of name for the t parameter of the binomial_distribution +is very unfortunate. In virtually every internet reference, book and software implementation +this parameter is called n 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 of k for the parameter of the negative binomial distributions is rather unusual. +The most common choice for the negative binomial distribution seems to be r 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 parameters +to n and r. +
+ +[ +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:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View other active issues in [rand.dist.samp.discrete].
+View all other issues in [rand.dist.samp.discrete].
+View all issues with NAD status.
+Discussion:
++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 in +N2424 +of this issue: +
++Rescaled floating-point parameter vectors can not be expected to compare +equal because of the limited precision of floating-point numbers. +My proposal would at least guarantee that a parameter +vector (of type double) passed into the distribution would compare equal +with the one returned by the probabilities() method. Furthermore, I do +not understand why "the changed requirement would lead to a significant +increase in the amount of state in the distribution object". A typical +implementation's state would increase by exactly one number: the sum of +all probabilities. The textual representation for serialization would +not need to grow at all. Finally, the proposed replacement "0 < n <= +numeric_limits<IntType>::max() + 1" makes the implementation +unnecessarily complicated, "0 < n <= numeric_limits<IntType>::max()" +would be better. +
+
[ +Bellevue: +]
+ + +++ + ++In N2424. We agree with the observation and the proposed resolution to +part b). We recommend the wording n > 0 be replaced with 0 < n +numeric_limits::max() + 1. However, we disagree with part a), as it +would interfere with the definition of parameters' equality. Further, +the changed requirement would lead to a significant increase in the +amount of state of the distribution object. +
+ ++As it stands now, it is convenient, and the changes proposed make it +much less so. +
+ ++NAD. Part a the current behavior is desirable. Part b, any constructor +can fail, but the rules under which it can fail do not need to be listed +here. +
+
Proposed resolution:
++See N2424 +for the proposed resolution. +
+ +[ +Stephan Tolksdorf adds pre-Bellevue: +]
+ + +++ + + + + ++In 26.4.8.5.1 [rand.dist.samp.discrete]: +
+ ++Proposed wording a): +
+ +++ ++Changae in para. 2 +
+ ++Constructs a discrete_distribution object with n=1 and p0 = w0 = 1 ++ ++and change in para. 5 +
+ ++Returns: A vector<double> whose size member returns n and whose +operator[] member returns+ +pk+the weight wk as a double value +when invoked with argument k for k = 0, +..., n-1 ++Proposed wording b): +
+ +++ ++Change in para. 3: +
+ ++If firstW == lastW, let the sequence w have length n = 1 and consist +of the single value w0 = 1. Otherwise, [firstW,lastW) shall form a +sequence w of length n+ +> 0+such that 0 < n <= numeric_limits<IntType>::max(), +and *firstW shall yield a value w0 +convertible to double. [Note: The values wk are commonly known +as the weights . -- end note] +
Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View other active issues in [rand.dist.samp.pconst].
+View all other issues in [rand.dist.samp.pconst].
+View all issues with NAD status.
+Discussion:
++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 an InputIteratorW lastW argument to the interface. +
+ +[ +Stephan Tolksdorf adds pre-Bellevue: +]
+ ++In reply to the discussion in +N2424 +I'd like to make the same comments as for 736. ++ +
[ +Bellevue: +]
+ + ++In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD. ++ + +
Proposed resolution:
++See N2424 +for the proposed resolution. +
+ +[ +Stephan Tolksdorf adds pre-Bellevue: +]
+ + +++ + + + + + ++In 26.4.8.5.2 [rand.dist.samp.pconst]: +
+ ++Proposed wording a) +
+ +++ ++Change in para. 2 +
++Constructs a piecewise_constant_distribution object with n = 1, p0 = w0 = 1, +b0 = 0, and b1 = 1 ++ ++and change in para. 5 +
+ ++A vector<result_type> whose size member returns n and whose operator[] +member returns+ +pk+the weight wk as a double value +when invoked with argument k for k = 0, ..., n-1 ++Proposed 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 sequence w starting from firstW shall be at least n, +*firstW shall return a value w0 that is convertible to double, and any +wk for k >= n shall be ignored by the distribution+[firstW, lastW) shall form a sequence w of length n whose leading element +w0 shall be convertible to double +
Section: 26.4.4.1 [rand.adapt.disc] Status: Pending NAD Editorial + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all issues with Pending NAD Editorial status.
+Discussion:
++Since the template parameter p and r are of type size_t, the member n in the class +exposition should have type size_t, too. +
+ + +Proposed resolution:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 26.4.7.2 [rand.util.canonical] Status: NAD + Submitter: Stephan Tolksdorf Date: 2007-09-21
+View all other issues in [rand.util.canonical].
+View all issues with NAD status.
+Discussion:
++The complexity of generate_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)). +
+ ++See N2424 +for further discussion. +
+ +[ +Bellevue: +]
+ + ++In N2424. Close NAD as described there. ++ + + +
Proposed resolution:
++See N2424 +for the proposed resolution. +
+ + + + + +Section: 20.7.12.2.11 [util.smartptr.getdeleter] Status: NAD + Submitter: Daniel Krügler Date: 2007-09-27
+View all other issues in [util.smartptr.getdeleter].
+View all issues with NAD status.
+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 synopsis +of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare: +
+ ++ +template<class D, class T> D* get_deleter(shared_ptr<T> const& p); +
+This allows to retrieve the pointer to a mutable deleter of a const +shared_ptr (if that owns one) and therefore contradicts the usual +philosophy that associated functors are either read-only (e.g. +key_comp or value_comp of std::map) or do at least reflect +the mutability of the owner (as seen for the both overloads of +unique_ptr::get_deleter). +Even the next similar counter-part of get_deleter - the two +overloads of function::target in the class template function +synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do +properly mirror the const-state of the owner. +
+ +Possible proposed resolutions: + ++Replace the declarations of get_deleter in the header <memory> +synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the +following alternatives (A) or (B): +
+ ++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 if D is the wrong type, while the latter would +never throw. This approach would reflect the current praxis of +use_facet/has_facet, with the twist of returning the deleter by value as +container::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: 18.7.5 [propagation] Status: NAD + Submitter: Alisdair Meredith Date: 2007-10-10
+View other active issues in [propagation].
+View all other issues in [propagation].
+View all issues with NAD status.
+Discussion:
++It could be I did not understand the design rationale, but I thought +copy_exception would produce an exception_ptr to the most-derived (dynamic) +type of the passed exception. Instead it slices, which appears to be less +useful, 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 whose +static type is identical to the dynamic type and thus there is no +slicing involved. +
+
Proposed resolution:
++
+ + + + + +Section: 20.5.4.3 [meta.unary.prop] Status: NAD + Submitter: Alisdair Meredith Date: 2007-10-10
+View all other issues in [meta.unary.prop].
+View all issues with NAD status.
+Discussion:
++I am trying to decide is a pure virtual function is a necessary as well as +sufficient 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 the +core 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. +
+ + + + + +Section: 20.7.10.1 [uninitialized.copy] Status: NAD Editorial + Submitter: Daniel Krügler Date: 2007-10-15
+View all other issues in [uninitialized.copy].
+View all issues with NAD Editorial status.
+Discussion:
++14882-2003, [lib.uninitialized.copy] is currently written as follows: +
+ +++ +template <class InputIterator, class ForwardIterator> + ForwardIterator uninitialized_copy(InputIterator first, InputIterator last, + ForwardIterator result); +++++-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 section +20.7.10.1 [uninitialized.copy]. +
+ ++It's not clear to me what the return clause is supposed to mean, I see +two +possible interpretations: +
+ ++The problem is: I see nothing in the standard which grants that this +interpretation +is correct, specifically [lib.structure.specifications] or +17.3.1.3 [structure.specifications] +resp. do not clarify which "look-up" rules apply for names found in +the elements +of the detailed specifications - Do they relate to the corresponding +synopsis or +to the effects clause (or possibly other elements)? Fortunately most +detailed +descriptions are unambigious in this regard, e.g. this problem does +not apply +for std::copy. +
+ + + +Proposed resolution:
++Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]): +
+ +++ + ++-2- Returns: The value of result after effects have taken place. +
+
[ +Bellevue: +]
+ + ++Resolution: NAD editorial -- project editor to decide if change is +worthwhile. Concern is that there are many other places this might +occur. ++ + + + +
Section: 23.2.5 [container.adaptors] Status: NAD Editorial + Submitter: Paolo Carlini Date: 2007-10-31
+View all issues with NAD Editorial status.
+Discussion:
++After n2369 we have a single push_back overload in the sequence containers, +of the "emplace" type. At variance with that, still in n2461, we have +two separate overloads, the C++03 one + one taking an rvalue reference +in the container adaptors. Therefore, simply from a consistency point of +view, I was wondering whether the container adaptors should be aligned +with the specifications of the sequence container themselves: thus have +a single push along the lines: +
+ +template<typename... _Args>
+void
+push(_Args&&... __args)
+ { c.push_back(std::forward<_Args>(__args)...); }
+[ +Related to 767 +]
+ + + +Proposed resolution:
++Change 23.2.5.1.1 [queue.defn]: +
+ ++ +void push(const value_type& x) { c.push_back(x); }+void push(value_type&& x) { c.push_back(std::move(x)); }+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); } +
+Change 23.2.5.2 [priority.queue]: +
+ ++ +void push(const value_type& x) { c.push_back(x); }+void push(value_type&& x) { c.push_back(std::move(x)); }+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); } +
+Change 23.2.5.2.2 [priqueue.members]: +
+ +++ ++void push(const value_type& x);+++ ++
+Effects:++c.push_back(x);+push_heap(c.begin(), c.end(), comp);+template<class... Args> void push(+value_typeArgs&&...xargs); ++++Effects: +
++c.push_back(std::moveforward<Args>(xargs)...); +push_heap(c.begin(), c.end(), comp); +
+Change 23.2.5.3.1 [stack.defn]: +
+ ++ + + +void push(const value_type& x) { c.push_back(x); }+void push(value_type&& x) { c.push_back(std::move(x)); }+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); } +
Rationale:
++Addressed by +N2680 Proposed Wording for Placement Insert (Revision 1). +
+ + + + + +Section: 23.2.6 [vector] Status: NAD Editorial + Submitter: Paolo Carlini Date: 2007-11-04
+View all other issues in [vector].
+View all issues with NAD Editorial status.
+Discussion:
++In the synopsis 23.2.6 [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.2.6.4 [vector.modifiers] is fine. +
+ + + +Proposed resolution:
++Change the synopsis in 23.2.6 [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.1.4 [associative.reqmts] Status: NAD + Submitter: Sylvain Pion Date: 2007-12-04
+View all other issues in [associative.reqmts].
+View all issues with NAD status.
+Discussion:
++The associative containers provide 2 overloads of emplace(): +
+ ++ +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 passing +a const_iterator as first argument. +
+ +[ +Related to 767 +]
+ + +[ +Bellevue: +]
+ + +++
+This can be disambiguated by passing "begin" as the first argument in +the case when the non-default choice is desired. We believe that desire +will be rare. +
++Resolution: Change state to NAD. +
+ + +Proposed resolution:
++Rename one of the two overloads. +For example to emplace_here, hint_emplace... +
+ + + + + +Section: 23.1.5 [unord.req] Status: NAD + Submitter: Joe Gottman Date: 2007-11-29
+View other active issues in [unord.req].
+View all other issues in [unord.req].
+View all issues with NAD status.
+Discussion:
++ 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, is O(bucket_count()) which may be much +larger than O(size()). +
++ If b is an non-const unordered container of type B and k is an +object of it's key_type, then b.equal_range(k) currently returns +pair<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
+}
++If b.equal_range(k) returns a non-empty range (i.e. b contains at least +on element whose key is equivalent to k), then every iterator in the +half-open range [lb, ub) will be in the same bucket, but ub will likely +either be in a different bucket or be equal to b.end(). In either case, +iterating between ub - 1 and ub could take a much longer time than +iterating through the rest of the range. +
++If instead of returning pair<iterator, iterator>, equal_range were to +return pair<local_iterator, local_iterator>, then ub (which, like lb, +would now be a local_iterator) could be guaranteed to always be in the +same bucket as lb. In the cases where currently ub is equal to b.end() +or is in a different bucket, ub would be equal to b.end(b.bucket(key)). + This would make iterating between lb and ub much faster, as every +iteration would be constant time. +
+ +[ +Bellevue: +]
+ + ++The proposed resolution breaks consistency with other container types +for dubious benefit, and iterators are already constant time. ++ + + +
Proposed resolution:
++Change the entry for equal_range in Table 93 (23.1.5 [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> for const b. | +Returns a range containing all elements with keys equivalent to k. Returns make_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: 23 [containers] Status: NAD Editorial + Submitter: Sylvain Pion Date: 2007-12-28
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with NAD Editorial status.
+Discussion:
++Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile: +
+ +#include <vector>
+
+int main()
+{
+ std::vector<char *> v;
+ v.push_back(0);
+}
++now fails with the following error message: +
+ +.../include/c++/4.3.0/ext/new_allocator.h: In member +function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, +_Args&& ...) [with _Args = int, _Tp = char*]': +.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void +std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with +_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' +test.cpp:6: instantiated from here +.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid +conversion from 'int' to 'char*' ++ +
+As far as I know, g++ follows the current draft here. +
++Does the committee really intend to break compatibility for such cases? +
+ +[ +Sylvain adds: +]
+ + +++ ++I just noticed that std::pair has the same issue. +The following now fails with GCC's -std=c++0x mode: +
+ ++ +#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} ++I have not made any general audit for such problems elsewhere. +
+
[ +Related to 756 +]
+ + +[ +Bellevue: +]
+ + +++ + + ++Motivation is to handle the old-style int-zero-valued NULL pointers. +Problem: this solution requires concepts in some cases, which some users +will be slow to adopt. Some discussion of alternatives involving +prohibiting variadic forms and additional library-implementation +complexity. +
++Discussion of "perfect world" solutions, the only such solution put +forward being to retroactively prohibit use of the integer zero for a +NULL pointer. This approach was deemed unacceptable given the large +bodies of pre-existing code that do use integer zero for a NULL pointer. +
++Another approach is to change the member names. Yet another approach is +to forbid the extension in absence of concepts. +
++Resolution: These issues (756, 767, 760, 763) will be subsumed into a +paper to be produced by Alan Talbot in time for review at the 2008 +meeting in France. Once this paper is produced, these issues will be +moved to NAD. +
+
Proposed resolution:
++Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: +
+ +++ ++
++ + +expression return type assertion/note
pre-/post-conditioncontainer ++ + ++a.push_front(t) + ++void + ++a.insert(a.begin(), t) +
+Requires: T shall be CopyConstructible. ++list, deque + ++ + ++a.push_front(rv) + ++void + ++a.insert(a.begin(), rv) +
+Requires: T shall be MoveConstructible. ++list, deque + ++ + ++a.push_back(t) + ++void + ++a.insert(a.end(), t) +
+Requires: T shall be CopyConstructible. ++list, deque, vector, basic_string + ++ + ++a.push_back(rv) + ++void + ++a.insert(a.end(), rv) +
+Requires: T shall be MoveConstructible. ++list, deque, vector, basic_string + +
+Change the synopsis in 23.2.2 [deque]: +
+ ++ +void push_front(const T& x); +void push_front(T&& x); +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
+Change 23.2.2.3 [deque.modifiers]: +
+ ++ +void push_front(const T& x); +void push_front(T&& x); +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
+Change the synopsis in 23.2.4 [list]: +
+ ++ +void push_front(const T& x); +void push_front(T&& x); +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
+Change 23.2.4.3 [list.modifiers]: +
+ ++ +void push_front(const T& x); +void push_front(T&& x); +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
+Change the synopsis in 23.2.6 [vector]: +
+ ++ +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
+Change 23.2.6.4 [vector.modifiers]: +
+ ++ + + + +void push_back(const T& x); +void push_back(T&& x); +template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args); +
Rationale:
++Addressed by +N2680 Proposed Wording for Placement Insert (Revision 1). +
+ ++If there is still an issue with pair, Howard should submit another issue. +
+ + + + + +Section: 26.4.8.1 [rand.dist.uni] Status: NAD + Submitter: P.J. Plauger Date: 2008-01-14
+View all other issues in [rand.dist.uni].
+View all issues with NAD status.
+Discussion:
+[ +Bellevue: +]
+ + ++NAD. Withdrawn. ++ + +
Proposed resolution:
++
+ + + + + +Section: 30.3.3.2.3 [thread.lock.unique.mod] Status: NAD + Submitter: Constantine Sapuntzakis Date: 2008-02-02
+View all issues with NAD status.
+Discussion:
++unique_lock::release will probably lead to many mistakes where people +call release instead of unlock. I just coded such a mistake using the +boost pre-1.35 threads library last week. +
+ ++In many threading libraries, a call with release in it unlocks the +lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore). +
+ ++I don't call unique_lock::lock much at all, so I don't get to see the +symmetry between ::lock and ::unlock. I usually use the constructor to +lock the mutex. So I'm left to remember whether to call release or +unlock during the few times I need to release the mutex before the scope +ends. If I get it wrong, the compiler doesn't warn me. +
+ ++An alternative name for release may be disown. +
+ ++This might be a rare case where usability is hurt by consistency with +the rest of the C++ standard (e.g. std::auto_ptr::release). +
+ +[ +Bellevue: +]
+ + ++Change a name from release to disown. However prior art uses the release +name. Compatibility with prior art is more important that any possible +benefit such a change might make. We do not see the benefit for +changing. NAD ++ + +
Proposed resolution:
++Change the synopsis in 30.3.3.2 [thread.lock.unique]: +
+ +template <class Mutex>
+class unique_lock
+{
+public:
+ ...
+ mutex_type* release disown();
+ ...
+};
++Change 30.3.3.2.3 [thread.lock.unique.mod]: +
+ ++ + + + + +mutex_type *releasedisown(); +
Section: X [datetime.system] Status: NAD Editorial + Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03
+View all issues with NAD Editorial status.
+Discussion:
++The draft C++0x thread library requires that the time points of type +system_time and returned by get_system_time() represent Coordinated +Universal Time (UTC) (section X [datetime.system]). This can lead to +surprising behavior when a library user performs a duration-based wait, +such as condition_variable::timed_wait(). A complete explanation of the +problem may be found in the +Rationale for the Monotonic Clock +section in POSIX, but in summary: +
+ ++POSIX solves the problem by introducing a new monotonic clock, which is +unaffected by changes to the system time. When a condition variable is +initialized, the user may specify whether the monotonic clock is to be +used. (It is worth noting that on POSIX systems it is not possible to +use condition_variable::native_handle() to access this facility, since +the desired clock type must be specified during construction of the +condition variable object.) +
+ ++In the context of the C++0x thread library, there are added dimensions +to the problem due to the need to support platforms other than POSIX: +
+ ++One possible minimal solution: +
+ +Proposed resolution:
++
+ + +Rationale:
+Addressed by +N2661: A Foundation to Sleep On. + + + + + +Section: 26.4.4.4 [rand.adapt.xor] Status: NAD + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.adapt.xor].
+View all issues with NAD status.
+Discussion:
++xor_combine::seed(result_type) and seed(seed_seq&) don't say what +happens to each of the sub-engine seeds. (Should probably do the same +to both, unlike TR1.) +
+ +[ +Bellevue: +]
+ + ++Overcome by the previous proposal. NAD mooted by resolution of 789. ++ + + +
Proposed resolution:
+ + + + + +Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD + Submitter: P.J. Plauger Date: 2008-02-09
+View other active issues in [rand.dist.samp.pconst].
+View all other issues in [rand.dist.samp.pconst].
+View all issues with NAD status.
+Discussion:
++piecewise_constant_distribution::densities() should be probabilities(), +just like discrete_distribution. (There's no real use for weights divided +by areas.) +
+ +[ +Bellevue: +]
+ + +++ + + ++Fermilab does not agree with this summary. As defined in the equation in +26.4.8.5.2/4, the quantities are indeed probability densities not +probabilities. Because we view this distribution as a parameterization +of a *probability density function*, we prefer to work in terms of +probability densities. +
+ ++We don't think this should be changed. +
+ ++If there is a technical argument about why the implementation dealing +with these values can't be as efficient as one dealing with +probabilities, we might reconsider. We don't care about this one member +function being somewhat more or less efficient; we care about the size +of the distribution object and the speed of the calls to generate +variates. +
+
Proposed resolution:
+ ++Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]: +
+ +template <class RealType = double>
+class piecewise_constant_distribution
+{
+public:
+ ...
+ vector<double> densities probabilities() const;
+ ...
+};
++Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: +
+ ++ + + + + + +vector<double>densitiesprobabilities() const; +
Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Dup + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.dist.samp.genpdf].
+View all issues with Dup status.
+Duplicate of: 732
+Discussion:
++general_pdf_distribution should be dropped. (It's a research topic in +adaptive numerical integration.) +
+ +[ +Stephan Tolksdorf notes: +]
+ + ++This appears to be a duplicate of 732. ++ + +
Proposed resolution:
+ + + + + + +Section: 26.4.5 [rand.predef] Status: NAD + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.predef].
+View all issues with NAD status.
+Discussion:
++The 10,000th value returned by ranlux48_base is supposed to be +61839128582725. We get 192113843633948. (Note that the underlying +generator was changed in Kona.) +
+ +[ +Bellevue: +]
+ + ++Submitter withdraws defect. ++ + + +
Proposed resolution:
++Change 26.4.5 [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-constructed +object of type ranlux48_base shall produce the value ++61839128582725192113843633948. +
Section: 26.4.5 [rand.predef] Status: NAD + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.predef].
+View all issues with NAD status.
+Discussion:
++The 10,000th value returned by ranlux48 is supposed to be +249142670248501. We get 88229545517833. (Note that this depends +on ranlux48_base.) +
+[ +Bellevue: +]
+ + ++Submitter withdraws defect. ++ + + +
Proposed resolution:
++Change 26.4.5 [rand.predef]/p6: +
+ +++ + + + + +typedef discard_block_engine<ranlux48_base, 389, 11> + ranlux48 +++Required behavior: The 10000th consecutive invocation of a default-constructed +object of type ranlux48 shall produce the value ++24914267024850188229545517833. +
Section: 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] Status: NAD + Submitter: Stephan Tolksdorf Date: 2008-02-18
+View all other issues in [rand.eng.mers].
+View all issues with NAD status.
+Discussion:
++TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that operator== for the mersenne_twister +returns true if and only if the states of two mersenne_twisters, +consisting each of n integers between 0 and 2w - 1, are completely +equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given +definition of the state also includes the lower r bits of x(i-n), which +will never be used to generate a random number. If two mersenne_twisters +only differ in the lower bits of x(i-n) they will not compare equal, +although they will produce an identical sequence of random numbers. +
+ ++26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour +of operator== but uses a similar definition of the state and, just like +TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a +mersenne_twister_engine to consist of Xi-n to Xi-1, including the +lower bits of Xi-n. This leads to two problems: First, the +unsuspecting implementer is likely to erroneously compare the lower r +bits of Xi-n in operator==. Second, if only the lower r bits differ, +two mersenne_twister_engines will compare equal (if correctly +implemented) but have different textual representations, which +conceptually is a bit ugly. +
+ ++I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which +clarifies that the lower r bits of Xi-n are not to be compared in +operator== and operator!=. It would only be consequent if furthermore +the specification for the textual respresentation was changed to +Xi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), ..., Xi-1 or +something similar. +
+ ++These changes would likely have no practical effect, but would allow an +implementation that does the right thing to be standard-conformant. +
+ +[ +Bellevue: +]
+ + +++ + ++Fermi Lab has no objection to the proposed change. However it feels that +more time is needed to check the details, which would suggest a change +to REVIEW. +
++Bill feels that this is NAD, not enough practical importance to abandon +the simple definition of equality, and someone would have to do a lot +more study to ensure that all cases are covered for a very small +payback. The submitter admits that "These changes would likely have no +practical effect,", and according to Plum's razor this means that it is +not worth the effort! +
++Revisted: Agree that the fact that there is no practical difference means that no change can be justified. +
+
Proposed resolution:
++In 26.4.3.2 [rand.eng.mers]: +
+ +++ + + + + ++Insert at the end of para 2.: +
+ ++[Note: The lower r bits of Xi-n do not influence +the state transition and hence should not be compared when comparing two +mersenne_twister_engine objects. -- end note] ++ ++In para 5. change: +
+ ++The textual representation of xi consists of the values of +Xi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), +..., Xi-1, in that order. ++
Section: 26.4.5 [rand.predef] Status: NAD + Submitter: P.J. Plauger Date: 2008-02-20
+View all other issues in [rand.predef].
+View all issues with NAD status.
+Discussion:
++The 10,000th value returned by knuth_b is supposed to be +1112339016. We get 2126698284. +
+ + +Proposed resolution:
++Change 26.4.5 [rand.predef]/p8: +
+ +++ + +typedef shuffle_order_engine<minstd_rand0, 256> + knuth_b; +++Required behavior: The 10000th consecutive invocation of a default-constructed +object of type knuth_b shall produce the value ++11123390162126698284. +
[ +Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD. +]
+ + + + + +Section: 22.2.2.2 [locale.nm.put] Status: NAD + Submitter: Peter Dimov Date: 2008-04-07
+View all issues with NAD status.
+Discussion:
++In the spirit of printf vs iostream... +
+ ++POSIX printf says that %'d should insert grouping characters (and the +implication is that in the absence of ' no grouping characters are +inserted). The num_put facet, on the other hand, seems to always insert +grouping characters. Can this be considered a defect worth fixing for +C++0x? Maybe ios_base needs an additional flag? +
+ +[ +Pablo Halpern: +]
+ + ++I'm not sure it constitutes a defect, but I would be in favor of adding +another flag (and corresponding manipulator). ++ +
[ +Martin Sebor: +]
+ + ++I don't know if it qualifies as a defect but I agree that there +should be an easy way to control whether the thousands separator +should or shouldn't be inserted. A new flag would be in line with +the current design of iostreams (like boolalpha, showpos, or +showbase). ++ +
[ +Sophia Antipolis: +]
+ + ++This is not a part of C99. LWG suggests submitting a paper may be appropriate. ++ + + +
Proposed resolution:
++
+ + + + + +Section: 21.1.3 [char.traits.specializations] Status: NAD Editorial + Submitter: Dietmar Kühl Date: 2008-04-23
+View all other issues in [char.traits.specializations].
+View all issues with NAD Editorial status.
+Discussion:
+
+ In Table 56 (Traits requirements) the not_eof() member function
+ is using an argument of type e which denotes an object of
+ type X::int_type. However, the specializations in
+ 21.1.3 [char.traits.specializations] all use char_type.
+ This would effectively mean that the argument type actually can't
+ represent EOF in the first place. I'm pretty sure that the type used
+ to be int_type which is quite obviously the only sensible
+ argument.
+
+ This issue is close to being editorial. I suspect that the proposal
+ changing this section to include the specializations for char16_t
+ and char32_t accidentally used the wrong type.
+
Proposed resolution:
+
+ In 21.1.3.1 [char.traits.specializations.char],
+ 21.1.3.2 [char.traits.specializations.char16_t],
+ 21.1.3.3 [char.traits.specializations.char32_t], and
+ [char.traits.specializations.wchar_t] correct the
+ argument type from char_type to int_type.
+
Rationale:
+Already fixed in WP. + + + + + +Section: 20.2.3 [pairs] Status: NAD + Submitter: Thorsten Ottosen Date: 2008-05-23
+View all other issues in [pairs].
+View all issues with NAD status.
+Discussion:
++I have one issue with std::pair. Well, it might just be a very annoying +historical accident, but why is there no default template argument for +the second template argument? This is so annoying when the type in +question is looong and hard to write (type deduction with auto won't +help those cases where we use it as a return or argument type). +
+ + +Proposed resolution:
++Change the synopsis in 20.2 [utility] to read: +
+ ++ +template <class T1, class T2 = T1> struct pair; +
+Change 20.2.3 [pairs] to read: +
+ +namespace std {
+ template <class T1, class T2 = T1>
+ struct pair {
+ typedef T1 first_type;
+ typedef T2 second_type;
+ ...
+Rationale:
+std::pair is a heterogeneous container. + + + + + + \ No newline at end of file