From 301a9fb249131bad2b88ddea549cfee9b577c9e0 Mon Sep 17 00:00:00 2001
From: Paolo Carlini Reference ISO/IEC IS 14882:1998(E) Also see: Section: 23.2.5 [vector] Status: Open
+ Section: 23.2.6 [vector] Status: Open
Submitter: AFNOR Date: 1998-10-07 View all other issues in [vector]. View all issues with Open status. Section: 27.7 [string.streams], 27.8 [file.streams] Status: Open
+ Submitter: Angelika Langer Date: 1999-02-22 View all other issues in [string.streams]. View all issues with Open status. Discussion: The following question came from Thorsten Herlemann: You can set a mode when constructing or opening a file-stream or
+ filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
+ that mode later on, e.g. in my own operator << or operator
+ >> or when I want to check whether a file-stream or
+ file-buffer object passed as parameter is opened for input or output
+ or binary? Is there no possibility? Is this a design-error in the
+ standard C++ library? It is indeed impossible to find out what a stream's or stream
+buffer's open mode is, and without that knowledge you don't know
+how certain operations behave. Just think of the append mode. Both streams and stream buffers should have a mode() function that returns the
+current open mode setting. [
+post Bellevue: Alisdair requested to re-Open.
+] Proposed resolution: For stream buffers, add a function to the base class as a non-virtual function
+qualified as const to 27.5.2 [streambuf]: openmode mode() const; Returns the current open mode. With streams, I'm not sure what to suggest. In principle, the mode
+could already be returned by ios_base, but the mode is only
+initialized for file and string stream objects, unless I'm overlooking
+anything. For this reason it should be added to the most derived
+stream classes. Alternatively, it could be added to basic_ios
+and would be default initialized in basic_ios<>::init(). Rationale: This might be an interesting extension for some future, but it is
+not a defect in the current standard. The Proposed Resolution is
+retained for future reference. Section: 23 [containers] Status: Open
+ Submitter: Dave Abrahams Date: 1999-07-01 View other active issues in [containers]. View all other issues in [containers]. View all issues with Open status. Discussion: It is the constness of the container which should control whether
+it can be modified through a member function such as erase(), not the
+constness of the iterators. The iterators only serve to give
+positioning information. Here's a simple and typical example problem which is currently very
+difficult or impossible to solve without the change proposed
+below. Wrap a standard container C in a class W which allows clients to
+find and read (but not modify) a subrange of (C.begin(), C.end()]. The
+only modification clients are allowed to make to elements in this
+subrange is to erase them from C through the use of a member function
+of W. [
+post Bellevue, Alisdair adds:
+]
+This issue was implemented by
+N2350
+for everything but basic_string.
+
+Note that the specific example in this issue (basic_string) is the one place
+we forgot to amend in
+N2350,
+so we might open this issue for that
+single container?
+ Proposed resolution: Change all non-const iterator parameters of standard library
+container member functions to accept const_iterator parameters.
+Note that this change applies to all library clauses, including
+strings. For example, in 21.3.5.5 change: Rationale: The issue was discussed at length. It was generally agreed that 1)
+There is no major technical argument against the change (although
+there is a minor argument that some obscure programs may break), and
+2) Such a change would not break const correctness. The concerns about
+making the change were 1) it is user detectable (although only in
+boundary cases), 2) it changes a large number of signatures, and 3) it
+seems more of a design issue that an out-and-out defect. The LWG believes that this issue should be considered as part of a
+general review of const issues for the next revision of the
+standard. Also see issue 200. Section: 25.3.7 [alg.min.max] Status: Open
+ Submitter: Mark Rintoul Date: 1999-08-26 View other active issues in [alg.min.max]. View all other issues in [alg.min.max]. View all issues with Open status. Discussion: Both std::min and std::max are defined as template functions. This
+is very different than the definition of std::plus (and similar
+structs) which are defined as function objects which inherit
+std::binary_function. [
+post Bellevue: Alisdair requested to re-Open.
+] Rationale: Although perhaps an unfortunate design decision, the omission is not a defect
+in the current standard. A future standard may wish to consider additional
+function objects. Section: 27.5.2 [streambuf] Status: Open
@@ -1210,7 +1459,6 @@ with a return type of convertible to T and operational semantics of
Section: 27.6 [iostream.format] Status: Open
Submitter: Martin Sebor Date: 2001-03-19 View other active issues in [iostream.format]. View all other issues in [iostream.format]. View all issues with Open status. Discussion:
-
Doc. no.
-N2456=07-0326
+N2612=08-0122
Date:
-2007-10-20
+2008-05-18
Project:
@@ -27,7 +27,7 @@ del {background-color:#FFA0A0}
Howard Hinnant <howard.hinnant@gmail.com>
C++ Standard Library Active Issues List (Revision R52)
+C++ Standard Library Active Issues List (Revision R56)
Revision History
+
@@ -141,13 +224,13 @@ del {background-color:#FFA0A0}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -103,16 +186,16 @@ del {background-color:#FFA0A0}
-
-
-
-
-
-
96. Vector<bool> is not a container
-
+128. Need open_mode() function for file stream, string streams, file buffers, and string buffers
+
+
+
+
+180. Container member iterator arguments constness has unintended consequences
+
+
+
+
+
+
+
+ iterator erase(iterator p);
+
+to:
+ iterator erase(const_iterator p);
+
+190. min() and max() functions should be std::binary_functions
+
+
+ This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
+a function object that inherits std::binary_function.
255. Why do basic_streambuf<>::pbump() and gbump() take an int?
309. Does sentry catch exceptions?
[ +post Bellevue: +]
+ + ++Position taken in prior reviews is that the idea of a table of header +dependencies is a good one. Our view is that a full paper is needed to +do justice to this, and we've made that recommendation to the issue +author. ++ +
Proposed resolution:
@@ -1982,10 +2243,10 @@ partial can only occur if (from_next != from_end)?
Section: 26.3 [complex.numbers] Status: Open +
Section: 26.3 [complex.numbers] Status: Ready Submitter: Gabriel Dos Reis Date: 2002-11-08
View all other issues in [complex.numbers].
-View all issues with Open status.
+View all issues with Ready status.
Discussion:
The absence of explicit description of std::complex<T> layout @@ -2027,9 +2288,9 @@ of std::complex<> is not justified.
In the header synopsis in 26.3.1 [complex.synopsis], replace
-template<class T> T real(const complex<T>&); - template<class T> T imag(const complex<T>&); -+
+In 26.3.2 [complex] Add the member functions +
-with
+-void real(T); +void imag(T); +
template<class T> const T& real(const complex<T>&); - template<class T> T& real( complex<T>&); - template<class T> const T& imag(const complex<T>&); - template<class T> T& imag( complex<T>&); -+
+Add to 26.3.4 [complex.members] +
-In 26.3.7 [complex.value.ops] paragraph 1, change
-template<class T> T real(const complex<T>&); ++T real() const;-to
-template<class T> const T& real(const complex<T>&); - template<class T> T& real( complex<T>&); ++Returns: the value of the real component ++void real(T val);-and change the Returns clause to "Returns: The real -part of x.
- -In 26.3.7 [complex.value.ops] paragraph 2, change
-template<class T> T imag(const complex<T>&); ++Assigns val to the real component. ++T imag() const;-to
-template<class T> const T& imag(const complex<T>&); - template<class T> T& imag( complex<T>&); ++Returns: the value of the imaginary component ++void imag(T val);-and change the Returns clause to "Returns: The imaginary -part of x.
++Assigns val to the imaginary component. ++[Kona: The layout guarantee is absolutely necessary for C compatibility. However, there was disagreement about the other part @@ -2095,6 +2358,14 @@ part of x.
[pre-Sydney: Howard summarized the options in n1589.]
+[ +Bellevue: +]
+ + ++Second half of proposed wording replaced and moved to Ready. +Rationale:
@@ -2215,6 +2486,7 @@ functions should be changed as proposed below.396. what are characters zero and one
Section: 23.3.5.1 [bitset.cons] Status: Open Submitter: Martin Sebor Date: 2003-01-05
+View other active issues in [bitset.cons].
View all other issues in [bitset.cons].
View all issues with Open status.
Discussion:
@@ -2305,6 +2577,15 @@ is zero. Otherwise, the element has the value 1. +[ +post Bellevue: +]
+ + ++We are happy with the resolution as proposed, and we move this to Ready. ++ @@ -2348,7 +2629,7 @@ sentry::~sentry() should internally catch any exceptions it might cause.[ -See 418 and 622 for related issues. +See 418 and 622 for related issues. ]
@@ -2661,7 +2942,7 @@ object throws.[ -See 397 and 622 for related issues. +See 397 and 622 for related issues. ]
@@ -3023,88 +3304,6 @@ ostream::write(). -
-424. normative notes
-Section: 17.3.1.1 [structure.summary] Status: Open - Submitter: Martin Sebor Date: 2003-09-18
-View all issues with Open 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.6.1.1 [allocator.members], p3,
-20.6.1.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.1 [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. -]
- - - -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. -]
- - - - -
427. stage 2 and rationale of DR 221
Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open @@ -3184,8 +3383,155 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1). need wording to express this decision.]
+[ +Bellevue: +]
+ + ++Please note that the standard also fails to specify the behavior of +slice_array and gslice_array in the valid case. Bill Plauger will +endeavor to provide revised wording for slice_array and gslice_array. ++ +[ +post-Bellevue: Bill provided wording. +]
+ +Proposed resolution:
++Insert after 26.5.2.4 [valarray.sub], paragraph 1: +
+ +++ @@ -3312,6 +3658,7 @@ reachability.+The member operator is overloaded to provide several ways to select +sequences +of elements from among those controlled by *this. The first group of five +member operators work in conjunction with various overloads of operator= +(and other assigning operators) to allow selective replacement (slicing) of +the controlled sequence. The selected elements must exist. +
++The first member operator selects element off. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +v0[3] = 'A'; +// v0 == valarray<char>("abcAefghijklmnop", 16) ++The second member operator selects those elements of the controlled sequence +designated by slicearr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDE", 5); +v0[slice(2, 5, 3)] = v1; +// v0 == valarray<char>("abAdeBghCjkDmnEp", 16) ++The third member operator selects those elements of the controlled sequence +designated by gslicearr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDEF", 6); +const size_t lv[] = {2, 3}; +const size_t dv[] = {7, 2}; +const valarray<size_t> len(lv, 2), str(dv, 2); +v0[gslice(3, len, str)] = v1; +// v0 == valarray<char>("abcAeBgCijDlEnFp", 16) ++The fourth member operator selects those elements of the controlled sequence +designated by boolarr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABC", 3); +const bool vb[] = {false, false, true, true, false, true}; +v0[valarray<bool>(vb, 6)] = v1; +// v0 == valarray<char>("abABeCghijklmnop", 16) ++The fifth member operator selects those elements of the controlled sequence +designated by indarr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDE", 5); +const size_t vi[] = {7, 5, 2, 3, 8}; +v0[valarray<size_t>(vi, 5)] = v1; +// v0 == valarray<char>("abCDeBgAEjklmnop", 16) ++The second group of five member operators each construct an object that +represents the value(s) selected. The selected elements must exist. +
+ ++The sixth member operator returns the value of element off. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +// v0[3] returns 'd' ++The seventh member operator returns an object of class valarray<Ty> +containing those elements of the controlled sequence designated by slicearr. +For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +// v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5) ++The eighth member operator selects those elements of the controlled sequence +designated by gslicearr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +const size_t lv[] = {2, 3}; +const size_t dv[] = {7, 2}; +const valarray<size_t> len(lv, 2), str(dv, 2); +// v0[gslice(3, len, str)] returns +// valarray<char>("dfhkmo", 6) ++The ninth member operator selects those elements of the controlled sequence +designated by boolarr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +const bool vb[] = {false, false, true, true, false, true}; +// v0[valarray<bool>(vb, 6)] returns +// valarray<char>("cdf", 3) ++The last member operator selects those elements of the controlled sequence +designated by indarr. For example: +
+ ++ +valarray<char> v0("abcdefghijklmnop", 16); +const size_t vi[] = {7, 5, 2, 3, 8}; +// v0[valarray<size_t>(vi, 5)] returns +// valarray<char>("hfcdi", 5) +View other active issues in [filebuf.members].
View all other issues in [filebuf.members].
View all issues with Open status.
+Duplicate of: 105
Discussion:
basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);@@ -3421,6 +3768,33 @@ std::basic_string? (3) We might want to wait until we see Beman's filesystem library; we might decide that it obviates this.] +[ +post Bellevue: +]
+ + +++ @@ -3563,157 +3937,414 @@ technique to perform the comparison:+Move again to Ready. +
++There is a timing issue here. Since the filesystem library will not be +in C++0x, this should be brought forward. This solution would remain +valid in the context of the proposed filesystem. +
++This issue has been kicking around for a while, and the wchar_t addition +alone would help many users. Thus, we suggest putting this on the +reflector list with an invitation for someone to produce proposed +wording that covers basic_fstream. In the meantime, we suggest that the +proposed wording be adopted as-is. +
++If more of the Lillehammer questions come back, they should be +introduced as separate issues. +
+
-462. Destroying objects with static storage duration
-Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: Open - Submitter: Bill Plauger Date: 2004-03-23
+463. auto_ptr usability issues
+Section: D.9.1 [auto.ptr] Status: Open + Submitter: Rani Sharoni Date: 2003-12-07
+View all other issues in [auto.ptr].
View all issues with Open 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. +TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() +member of auto_ptr (20.4.5.3/4) obsolete.
-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. +The sole purpose of this obsolete conversion member is to enable copy +initialization base from r-value derived (or any convertible types like +cv-types) case: +
+#include <memory> +using std::auto_ptr; + +struct B {}; +struct D : B {}; + +auto_ptr<D> source(); +int sink(auto_ptr<B>); +int x1 = sink( source() ); // #1 EDG - no suitable copy constructor ++ ++The excellent analysis of conversion operations that was given in the final +auto_ptr proposal +(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) +explicitly specifies this case analysis (case 4). DR #84 makes the analysis +wrong and actually comes to forbid the loophole that was exploited by the +auto_ptr designers.
-[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.]
++I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that +ever allowed this case. This is probably because it requires 3 user defined +conversions and in fact current compilers conform to DR #84. +
+ ++I was surprised to discover that the obsolete conversion member actually has +negative impact of the copy initialization base from l-value derived +case:
+auto_ptr<D> dp; +int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies ++ ++I'm sure that the original intention was allowing this initialization using +the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but +since in this copy initialization it's merely user defined conversion (UDC) +and the obsolete conversion member is UDC with the same rank (for the early +overloading stage) there is an ambiguity between them. +
+ ++Removing the obsolete member will have impact on code that explicitly +invokes it: +
+int y = sink(source().operator auto_ptr<B>()); ++ ++IMHO no one ever wrote such awkward code and the reasonable workaround for +#1 is: +
+int y = sink( auto_ptr<B>(source()) ); ++ ++I was even more surprised to find out that after removing the obsolete +conversion member the initialization was still ill-formed: +int x3 = sink(dp); // #3 EDG - no suitable copy constructor +
+ ++This copy initialization semantically requires copy constructor which means +that both template conversion constructor and the auto_ptr_ref conversion +member (20.4.5.3/3) are required which is what was explicitly forbidden in +DR #84. This is a bit amusing case in which removing ambiguity results with +no candidates. +
+ ++I also found exception safety issue with auto_ptr related to auto_ptr_ref: +
+int f(auto_ptr<B>, std::string); +auto_ptr<B> source2(); + +// string constructor throws while auto_ptr_ref +// "holds" the pointer +int x4 = f(source2(), "xyz"); // #4 ++ ++The theoretic execution sequence that will cause a leak: +
++
+ +- call auto_ptr<B>::operator auto_ptr_ref<B>()
+- call string::string(char const*) and throw
++According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member +returns auto_ptr_ref<Y> that holds *this and this is another defect since +the type of *this is auto_ptr<X> where X might be different from Y. Several +library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which +is much more reasonable. Other vendor implemented auto_ptr_ref as +defectively required and it results with awkward and catastrophic code: +int oops = sink(auto_ptr<B>(source())); // warning recursive on all control +paths +
+ ++Dave Abrahams noticed that there is no specification saying that +auto_ptr_ref copy constructor can't throw. +
+ ++My proposal comes to solve all the above issues and significantly simplify +auto_ptr implementation. One of the fundamental requirements from auto_ptr +is that it can be constructed in an intuitive manner (i.e. like ordinary +pointers) but with strict ownership semantics which yield that source +auto_ptr in initialization must be non-const. My idea is to add additional +constructor template with sole propose to generate ill-formed, diagnostic +required, instance for const auto_ptr arguments during instantiation of +declaration. This special constructor will not be instantiated for other +types which is achievable using 14.8.2/2 (SFINAE). Having this constructor +in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) +legitimate since the actual argument can't be const yet non const r-value +are acceptable. +
+ ++This implementation technique makes the "private auxiliary class" +auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, +GCC and VC) consume the new implementation as expected and allow all +intuitive initialization and assignment cases while rejecting illegal cases +that involve const auto_ptr arguments. +
+ +The proposed auto_ptr interface:
+ +namespace std { + template<class X> class auto_ptr { + public: + typedef X element_type; + + // 20.4.5.1 construct/copy/destroy: + explicit auto_ptr(X* p=0) throw(); + auto_ptr(auto_ptr&) throw(); + template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); + auto_ptr& operator=(auto_ptr&) throw(); + template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); + ~auto_ptr() throw(); + + // 20.4.5.2 members: + X& operator*() const throw(); + X* operator->() const throw(); + X* get() const throw(); + X* release() throw(); + void reset(X* p=0) throw(); + + private: + template<class U> + auto_ptr(U& rhs, typename +unspecified_error_on_const_auto_ptr<U>::type = 0); + }; +} ++ ++One compliant technique to implement the unspecified_error_on_const_auto_ptr +helper class is using additional private auto_ptr member class template like +the following: +
+template<typename T> struct unspecified_error_on_const_auto_ptr; + +template<typename T> +struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> +{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; }; ++ ++There are other techniques to implement this helper class that might work +better for different compliers (i.e. better diagnostics) and therefore I +suggest defining its semantic behavior without mandating any specific +implementation. IMO, and I didn't found any compiler that thinks otherwise, +14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest +verifying this with core language experts. +
+ +Further changes in standard text:
+Remove section 20.4.5.3
+ +Change 20.4.5/2 to read something like: +Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified +ill-formed declaration that will require unspecified diagnostic.
+ +Change 20.4.5.1/4,5,6 to read:
+ +template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();+4 Requires: Y* can be implicitly converted to X*.
+5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().
+6 Postconditions: *this holds the pointer returned from a.release().
+ +Change 20.4.5.1/10
+template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw(); +++10 Requires: Y* can be implicitly converted to X*. The expression delete +get() is well formed. +
+ +LWG TC DR #127 is obsolete.
+ ++Notice that the copy constructor and copy assignment operator should remain +as before and accept non-const auto_ptr& since they have effect on the form +of the implicitly declared copy constructor and copy assignment operator of +class that contains auto_ptr as member per 12.8/5,10: +
+struct X { + // implicit X(X&) + // implicit X& operator=(X&) + auto_ptr<D> aptr_; +}; ++ ++In most cases this indicates about sloppy programming but preserves the +current auto_ptr behavior. +
+ ++Dave Abrahams encouraged me to suggest fallback implementation in case that +my suggestion that involves removing of auto_ptr_ref will not be accepted. +In this case removing the obsolete conversion member to auto_ptr<Y> and +20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal +cases. The two constructors that I suggested will co exist with the current +members but will make auto_ptr_ref obsolete in initialization contexts. +auto_ptr_ref will be effective in assignment contexts as suggested in DR +#127 and I can't see any serious exception safety issues in those cases +(although it's possible to synthesize such). auto_ptr_ref<X> semantics will +have to be revised to say that it strictly holds pointer of type X and not +reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is +constructed from auto_ptr<X> in which X is different from Y (i.e. assignment +from r-value derived to base). +
+ +[Redmond: punt for the moment. We haven't decided yet whether we + want to fix auto_ptr for C++-0x, or remove it and replace it with + move_ptr and unique_ptr.]
[ -Batavia: Send to core with our recommendation that we should permit deferred -destruction but not require it. +Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases +and people know how to deal with it. Going forward unique_ptr is the recommended +tool. ]
[ -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: +2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis. ]
-- -#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() -Proposed resolution:
+Change the synopsis in D.9.1 [auto.ptr]:
++ +namespace std { +template <class Y> struct auto_ptr_ref {};+ + // exposition only + template <class T> struct constant_object; + + // exposition only + template <class T> + struct cannot_transfer_ownership_from + : constant_object<T> {}; + + template <class X> class auto_ptr { + public: + typedef X element_type; + + // D.9.1.1 construct/copy/destroy: + explicit auto_ptr(X* p =0) throw(); + auto_ptr(auto_ptr&) throw(); + template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); + auto_ptr& operator=(auto_ptr&) throw(); + template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw(); +auto_ptr& operator=(auto_ptr_ref<X> r) throw();+ ~auto_ptr() throw(); + + // D.9.1.2 members: + X& operator*() const throw(); + X* operator->() const throw(); + X* get() const throw(); + X* release() throw(); + void reset(X* p =0) throw(); + +// D.9.1.3 conversions:+auto_ptr(auto_ptr_ref<X>) throw();+template<class Y> operator auto_ptr_ref<Y>() throw();+template<class Y> operator auto_ptr<Y>() throw();+ + // exposition only + template<class U> + auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0); + }; + + template <> class auto_ptr<void> + { + public: + typedef void element_type; + }; + +} ++Remove D.9.1.3 [auto.ptr.conv]. +
+ ++Change D.9.1 [auto.ptr], p3: +
+ ++The auto_ptr provides a semantics of strict ownership. An +auto_ptr owns the object it holds a pointer to. Copying an +auto_ptr copies the pointer and transfers ownership to the +destination. If more than one auto_ptr owns the same object at +the same time the behavior of the program is undefined. Templates +constant_object and cannot_transfer_ownership_from, +and the final constructor of auto_ptr are for exposition only. +For any types X and Y, initializing +auto_ptr<X> from const auto_ptr<Y> is +ill-formed, diagnostic required. [Note: The uses of +auto_ptr include providing temporary exception-safety for +dynamically allocated memory, passing ownership of dynamically allocated +memory to a function, and returning dynamically allocated memory from a +function. auto_ptr does not meet the CopyConstructible +and Assignable requirements for Standard Library container +elements and thus instantiating a Standard Library container with an +auto_ptr results in undefined behavior. -- end note] ++ ++Change D.9.1.1 [auto.ptr.cons], p5: +
+ +++ +template<class Y> auto_ptr(auto_ptr<Y> const& a) throw(); +++++Requires: Y* can be implicitly converted to X*. +
++Effects: Calls const_cast<auto_ptr<Y>&>(a).release(). +
++Postconditions: *this holds the pointer returned from a.release(). +
++Change D.9.1.1 [auto.ptr.cons], p10: +
+ +++ +template<class Y> auto_ptr& operator=(auto_ptr<Y>+&a) throw(); ++++Requires: Y* can be implicitly converted to X*. +The expression delete get() is well formed. +
++Effects: Calls reset(a.release()). +
++Returns: *this. +
+
471. result of what() implementation-defined
-Section: 18.6.1 [type.info] Status: Open +
Section: 18.6.1 [type.info] Status: Ready Submitter: Martin Sebor Date: 2004-06-28
View all other issues in [type.info].
-View all issues with Open status.
+View all issues with Ready status.
Discussion:
[lib.exception] specifies the following:
@@ -3757,6 +4388,36 @@ Batavia: Howard provided wording. ] +[ +Bellevue: +]
+ + ++++Eric concerned this is unimplementable, due to nothrow guarantees. +Suggested implementation would involve reference counting. +
++Is the implied reference counting subtle enough to call out a note on +implementation? Probably not. +
++If reference counting required, could we tighten specification further +to require same pointer value? Probably an overspecification, especially +if exception classes defer evalutation of final string to calls to +what(). +
++Remember issue moved open and not resolved at Batavia, but cannot +remember who objected to canvas a disenting opinion - please speak up if +you disagree while reading these minutes! +
++Move to Ready as we are accepting words unmodified. +
+Proposed resolution:
@@ -3980,6 +4641,7 @@ wording (I believe) x,a,b,c could be written to in any order.492. Invalid iterator arithmetic expressions
Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open Submitter: Thomas Mang Date: 2004-12-12
+View other active issues in [containers].
View all other issues in [containers].
View all issues with Open status.
Discussion:
@@ -4142,6 +4804,16 @@ See DR 237. The resolution could then also read "Linear in last - first". +[ +Bellevue: +]
+ + ++Keep open and ask Bill to provide wording. ++ +Proposed resolution:
[Lillehammer: Minor issue, but real. We have a blanket statement @@ -4388,11 +5060,10 @@ Berlin: Bill to provide wording.
518. Are insert and erase stable for unordered_multiset and unordered_multimap?
-Section: 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] Status: Review +
Section: 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] Status: Ready Submitter: Matt Austern Date: 2005-07-03
-View other active issues in [unord.req].
View all other issues in [unord.req].
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
Issue 371 deals with stability of multiset/multimap under insert and erase @@ -4459,6 +5130,8 @@ preserves the relative ordering of equivalent elements.
522. Tuple doesn't define swap
Section: 20.3 [tuple], TR1 6.1 [tr.tuple] Status: Open Submitter: Andy Koenig Date: 2005-07-03
+View other active issues in [tuple].
+View all other issues in [tuple].
View all issues with Open status.
Discussion:
@@ -4477,10 +5150,80 @@ Toronto: Howard to provide wording (really this time). ]
+[ +Bellevue: Alisdair provided wording. +]
+ +Proposed resolution:
++Add these signatures to 20.3 [tuple] +
+ ++ +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>&& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>&& y); ++Add this signature to 20.3.1 [tuple.tuple] +
+ ++ +void swap(tuple&&); ++Add the following two sections to the end of the tuple clauses +
+ +++ + @@ -4618,155 +5361,11 @@ Pete: Possible general problem with case insensitive ranges. -+20.3.1.7 tuple swap [tuple.swap] +
+ +void swap(tuple&& rhs); ++ +++ ++Requires: Each type in Types shall be Swappable. +
++Effects: Calls swap for each element in *this and its corresponding element +in rhs. +
++Throws: Nothing, unless one of the element-wise swap calls throw an +exception. +
++20.3.1.8 tuple specialized algorithms [tuple.special] +
+ +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>&& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>&& y); ++ ++++Effects: x.swap(y) +
+
-527. tr1::bind has lost its Throws clause
-Section: 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: Open - Submitter: Peter Dimov Date: 2005-10-01
-View all issues with Open status.
-Discussion:
--The original bind proposal gives the guarantee that tr1::bind(f, t1, -..., tN) does not throw when the copy constructors of f, t1, ..., tN -don't. -
- --This guarantee is not present in the final version of TR1. -
- --I'm pretty certain that we never removed it on purpose. Editorial omission? :-) -
- -[ -Berlin: not quite editorial, needs proposed wording. -]
- -[ -Batavia: Doug to translate wording to variadic templates. -]
- - -[ -Toronto: We agree but aren't quite happy with the wording. The "t"'s no -longer refer to anything. Alan to provide improved wording. -]
- - - - -Proposed resolution:
--In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2: -
-- --Throws: Nothing unless one of the copy constructors of f, t1, t2, ..., tN -throws an exception. -
-Add a new paragraph after p4: -
-- - - - - --Throws: nothing unless one of the copy constructors of f, t1, t2, ..., tN -throws an exception. -
-529. The standard encourages redundant and confusing preconditions
-Section: 17.4.3.8 [res.on.required] Status: Open - Submitter: David Abrahams Date: 2005-10-25
-View all issues with Open 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. -]
- - - -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. -]
- - - - - - -
539. partial_sum and adjacent_difference should mention requirements
-Section: 26.6.3 [partial.sum] Status: Open +
Section: 26.6.3 [partial.sum] Status: Review Submitter: Marc Schoolderman Date: 2006-02-06
-View all issues with Open status.
+View all issues with Review status.
Discussion:
There are some problems in the definition of partial_sum and @@ -4912,12 +5511,38 @@ adding signatures to allow user to specify "accumulator". ]
+[ +Bellevue: +]
+ + ++The intent of the algorithms is to perform their calculations using the type of the input iterator. +Proposed wording provided. +Proposed resolution:
+Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
++The type of *first shall meet the requirements of CopyConstructible? +(20.1.3?) and Assignable (23.1?) types. The result of *i + *(i+1) or +binary_op(*i, *(i+1)) shall be convertible to this type. ++ ++Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: +
+ ++The type of *first shall meet the requirements of CopyConstructible? +(20.1.3) and Assignable (23.1) types. ++ + @@ -4951,11 +5576,11 @@ list, so that people may use long long as a hash key.
550. What should the return type of pow(float,int) be?
-Section: 26.7 [c.math] Status: Open +
Section: 26.7 [c.math] Status: Ready Submitter: Howard Hinnant Date: 2006-01-12
View other active issues in [c.math].
View all other issues in [c.math].
-View all issues with Open status.
+View all issues with Ready status.
Discussion:
Assuming we adopt the @@ -5015,52 +5640,73 @@ resolution")
[ -
-Howard, post Kona: -
++Howard, post Kona: +
-] +] +-Unfortunately I strongly disagree with a part of the resolution +Unfortunately I strongly disagree with a part of the resolution from Kona. I am moving from New to Open instead of to Review because I do not believe we have consensus on the intent of the resolution. -
+-This issue does not include ldexp, scalbln, and scalbn because +This issue does not include ldexp, scalbln, and scalbn because the second integral parameter in each of these signatures (from C99) is not a generic parameter according to C99 7.22p2. The corresponding C++ overloads are intended (as far as I know) to correspond directly to C99's definition of generic parameter. -
+-For similar reasons, I do not believe that the second long double parameter of +For similar reasons, I do not believe that the second long double parameter of nexttoward, nor the return type of this function, is in error. I believe the correct signature is: -
+-float nexttoward(float, long double); -+float nexttoward(float, long double); +-which is what both the C++0X working paper and C99 state (as far as I currently understand). -
+which is what both the C++0X working paper and C99 state (as far as I currently understand). +-This is really only about pow(float, int). And this is because C++98 took one +This is really only about pow(float, int). And this is because C++98 took one route (with pow only) and C99 took another (with many math functions in <tgmath.h>. The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99. -
+[ +Bellevue: +]
+ + ++This signature was not picked up from C99. Instead, if one types +pow(2.0f,2), the promotion rules will invoke "double pow(double, +double)", which generally gives special treatment for integral +exponents, preserving full accuracy of the result. New proposed +wording provided. +Proposed resolution:
-Change 26.7 [c.math] +Change 26.7 [c.math] p10:
-@@ -8686,248 +7975,6 @@ is just: istreambuf_iterator should have an operator->()! -float pow(float, float); -floatdouble pow(float, int); ++@@ -5128,406 +5774,10 @@ destroyed. -+The added signatures are: +
++... +float pow(float, int);+... +double pow(double, int);+... +long double pow(long double, int);
-557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)
-Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: Open - Submitter: Paolo Carlini Date: 2006-02-06
-View all other issues in [cstdint].
-View all issues with Open 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] -
-561. inserter overly generic
-Section: 24.4.2.6.5 [inserter] Status: Ready - Submitter: Howard Hinnant Date: 2006-02-21
-View all issues with Ready status.
-Discussion:
--The declaration of std::inserter is: -
- -- -template <class Container, class Iterator> -insert_iterator<Container> -inserter(Container& x, Iterator i); --The template parameter Iterator in this function is completely unrelated -to the template parameter Container when it doesn't need to be. This -causes the code to be overly generic. That is, any type at all can be deduced -as Iterator, whether or not it makes sense. Now the same is true of -Container. However, for every free (unconstrained) template parameter -one has in a signature, the opportunity for a mistaken binding grows geometrically. -
- --It would be much better if inserter had the following signature instead: -
- -- -template <class Container> -insert_iterator<Container> -inserter(Container& x, typename Container::iterator i); --Now there is only one free template parameter. And the second argument to -inserter must be implicitly convertible to the container's iterator, -else the call will not be a viable overload (allowing other functions in the -overload set to take precedence). Furthermore, the first parameter must have a -nested type named iterator, or again the binding to std::inserter -is not viable. Contrast this with the current situation -where any type can bind to Container or Iterator and those -types need not be anything closely related to containers or iterators. -
- --This can adversely impact well written code. Consider: -
- -- -#include <iterator> -#include <string> - -namespace my -{ - -template <class String> -struct my_type {}; - -struct my_container -{ -template <class String> -void push_back(const my_type<String>&); -}; - -template <class String> -void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);} - -} // my - -int main() -{ - my::my_container c; - my::my_type<std::string> m; - inserter(m, c); -} --Today this code fails because the call to inserter binds to -std::inserter instead of to my::inserter. However with the -proposed change std::inserter will no longer be a viable function which -leaves only my::inserter in the overload resolution set. Everything -works as the client intends. -
- --To make matters a little more insidious, the above example works today if you -simply change the first argument to an rvalue: -
- -- -inserter(my::my_type(), c); --It will also work if instantiated with some string type other than -std::string (or any other std type). It will also work if -<iterator> happens to not get included. -
- --And it will fail again for such inocuous reaons as my_type or -my_container privately deriving from any std type. -
- --It seems unfortunate that such simple changes in the client's code can result -in such radically differing behavior. -
- - - -Proposed resolution:
--Change 24.2: -
- -- --24.2 Header <iterator> synopsis -
--... -template <class Container, class Iterator> - insert_iterator<Container> inserter(Container& x,Iteratortypename Container::iterator i); -... --Change 24.4.2.5: -
- -- --24.4.2.5 Class template insert_iterator
--... -template <class Container, class Iterator> - insert_iterator<Container> inserter(Container& x,Iteratortypename Container::iterator i); -... --Change 24.4.2.6.5: -
- --- - - --24.4.2.6.5 inserter -
-template <class Container-, class Inserter> - insert_iterator<Container> inserter(Container& x,Insertertypename Container::iterator i); ----1- Returns: insert_iterator<Container>(x,
typename Container::iterator(i)). -[ -Kona (2007): This issue will probably be addressed as a part of the -concepts overhaul of the library anyway, but the proposed resolution is -correct in the absence of concepts. Proposed Disposition: Ready -]
- - - - - -
-562. stringbuf ctor inefficient
-Section: 27.7 [string.streams] Status: Ready - Submitter: Martin Sebor Date: 2006-02-23
-View all other issues in [string.streams].
-View all issues with Ready status.
-Discussion:
-- -For better efficiency, the requirement on the stringbuf ctor that -takes a string argument should be loosened up to let it set -
- - -epptr()
beyond just one past the last initialized -character just likeoverflow()
has been changed to be -allowed to do (see issue 432). That way the first call to -sputc()
on an object won't necessarily cause a call to -overflow
. The corresponding change should be made to the -string overload of thestr()
member function. - -Proposed resolution:
-- -Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: - -
- -- -explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& s- -tr, - ios_base::openmode which = ios_base::in | ios_base::out); ---3- Effects: Constructs an object of class basic_stringbuf, -initializing the base class with basic_streambuf() -(27.5.2.1), and initializing mode with which. -Then calls str(s).
-copies the content of -str into the basic_stringbuf underlying character -sequence. If which & ios_base::out is true, initializes the -output sequence such that pbase() points to the first underlying -character, epptr() points one past the last underlying character, and -pptr() is equal to epptr() if which & ios_base::ate -is true, otherwise pptr() is equal to pbase(). If -which & ios_base::in is true, initializes the input sequence such -that eback() and gptr() point to the first underlying -character and egptr() points one past the last underlying character.-- -Change the Effects clause of the
-str()
in 27.7.1.2, p2 to -read: - --- - ---2- Effects: Copies the contents of s into the -basic_stringbuf underlying character sequence and -initializes the input and output sequences according to mode. -
- -If -mode & ios_base::out is true, initializes the output -sequence such that pbase() points to the first underlying character, -epptr() points one past the last underlying character, and pptr() -is equal to epptr() if mode & ios_base::in -is true, otherwise pptr() is equal to pbase(). If -mode & ios_base::in is true, initializes the input sequence -such that eback() and gptr() point to the first underlying -character and egptr() points one past the last underlying character.-- --3- Postconditions: If
-mode & ios_base::out
is true, -pbase()
points to the first underlying character and -(epptr() >= pbase() + s.size())
holds; in addition, if -mode & ios_base::in
is true,(pptr() == pbase() -+ s.data())
holds, otherwise(pptr() == pbase())
-is true. Ifmode & ios_base::in
is true, -eback()
points to the first underlying character, and -(gptr() == eback())
and(egptr() == eback() + -s.size())
hold. - -[ -Kona (2007) Moved to Ready. -]
- - - - - -
-563. stringbuf seeking from end
-Section: 27.7.1.4 [stringbuf.virtuals] Status: Ready - Submitter: Martin Sebor Date: 2006-02-23
-View other active issues in [stringbuf.virtuals].
-View all other issues in [stringbuf.virtuals].
-View all issues with Ready status.
-Discussion:
--According to Table 92 (unchanged by issue 432), when
-(way == -end)
thenewoff
value in out mode is computed as -the difference betweenepptr()
andpbase()
. -- -This value isn't meaningful unless the value of
-epptr()
-can be precisely controlled by a program. That used to be possible -until we accepted the resolution of issue 432, but since then the -requirements onoverflow()
have been relaxed to allow it -to make more than 1 write position available (i.e., by setting -epptr()
to some unspecified value past -pptr()
). So after the first call to -overflow()
positioning the output sequence relative to -end will have unspecified results. - -- -In addition, in
- - -in|out
mode, since(egptr() == -epptr())
need not hold, there are two different possible values -fornewoff
:epptr() - pbase()
and -egptr() - eback()
. - -Proposed resolution:
-- -Change the
-newoff
column in the last row of Table 94 to -read: - -- - -- -the
endhigh mark pointer minus the beginning -pointer (). - -
xendhigh_mark - xbeg[ -Kona (2007) Moved to Ready. -]
- - - - -
564. stringbuf seekpos underspecified
Section: 27.7.1.4 [stringbuf.virtuals] Status: Open Submitter: Martin Sebor Date: 2006-02-23
-View other active issues in [stringbuf.virtuals].
View all other issues in [stringbuf.virtuals].
View all issues with Open status.
Discussion:
@@ -5658,74 +5908,6 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open -
-567. streambuf inserter and extractor should be unformatted
-Section: 27.6 [iostream.format] Status: Ready - Submitter: Martin Sebor Date: 2006-02-25
-View other active issues in [iostream.format].
-View all other issues in [iostream.format].
-View all issues with Ready status.
-Discussion:
-- -Issue 60 explicitly made the extractor and inserter operators that -take a basic_streambuf* argument formatted input and output -functions, respectively. I believe that's wrong, certainly in the -case of the extractor, since formatted functions begin by extracting -and discarding whitespace. The extractor should not discard any -characters. - -
- - -Proposed resolution:
-- -I propose to change each operator to behave as unformatted input and -output function, respectively. The changes below are relative to the -working draft document number N1804. - -
-- -Specifically, change 27.6.1.2.3, p14 as follows: - -
- ---- -Effects: Behaves as an unformatted input function -(as described in
-27.6.1.2.127.6.1.3, paragraph -1). - -- -And change 27.6.2.5.3, p7 as follows: - -
- --- - -- -Effects: Behaves as an unformatted output function -(as described in
-27.6.2.5.127.6.2.6, paragraph -1). - -[ -Kona (2007): Proposed Disposition: Ready -]
- - - - -
568. log2 overloads missing
Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New @@ -5754,6 +5936,8 @@ Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
570. Request adding additional explicit specializations of char_traits
Section: 21.1 [char.traits] Status: Open Submitter: Jack Reeves Date: 2006-04-06
+View other active issues in [char.traits].
+View all other issues in [char.traits].
View all issues with Open status.
Discussion:
@@ -5780,6 +5964,27 @@ Toronto: issue has grown with addition of char16_t and char32_t
+[ +post Bellevue: +]
+ + +++ ++We suggest that Jack be asked about the status of his paper, and if it +is not forthcoming, the work-item be assigned to someone else. If no one +steps forward to do the paper before the next meeting, we propose to +make this NAD without further discussion. We leave this Open for now, +but our recommendation is NAD. +
++Note: the issue statement should be updated, as the Toronto comment has +already been resolved. E.g., char_traits specializations for char16_t +and char32_t are now in the working paper. +
+Proposed resolution:
@@ -5843,10 +6048,10 @@ these definitions are horrible. Proposed Disposition: Open
574. DR 369 Contradicts Text
-Section: 27.3 [iostream.objects] Status: Review +
Section: 27.3 [iostream.objects] Status: Ready Submitter: Pete Becker Date: 2006-04-18
View all other issues in [iostream.objects].
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
lib.iostream.objects requires that the standard stream objects are never @@ -5893,81 +6098,6 @@ Disposition: Review -
-579. erase(iterator) for unordered containers should not return an iterator
-Section: 23.1.3 [unord.req] Status: Open - 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 Open 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. -
- - - - -
580. unused allocator members
Section: 20.1.2 [allocator.requirements] Status: Open @@ -6017,92 +6147,80 @@ pre-Oxford: Martin provided wording.
Proposed resolution:
-+
Specifically, I propose to change 23.1 [container.requirements], p9 as follows: -
-+ ++---9- Copy constructors for all container types defined in this clause -that are parametrized on
Allocator
copy -anthe allocator argument from their respective +-9- Copy constructors for all container types defined in this clause +that are parametrized onAllocator
copy +anthe allocator argument from their respective first parameters. -All other constructors for these container types take an-constAllocator&
argument (20.1.6), an +All other constructors for these container types take an+constAllocator&
argument (20.1.6), an allocator whosevalue_type
is the same as the container'svalue_type
. -A copy of this argumentisshall be used for any -memory allocation and deallocation performed,-by these constructors and by all member functions,during -the lifetime of each container object. Allocation shall be -performed "as if" by calling theallocate()
member -function on a copy of the allocator object of the appropriate type -New Footnote), and deallocation "as if" by calling -deallocate()
on a copy of the same allocator object of +A copy of this argumentisshall be used for any +memory allocation and deallocation performed,+by these constructors and by all member functions,during +the lifetime of each container object. Allocation shall be +performed "as if" by calling theallocate()
member +function on a copy of the allocator object of the appropriate type +New Footnote), and deallocation "as if" by calling +deallocate()
on a copy of the same allocator object of the corresponding type. -A copy of this argument shall also be used to construct and -destroy objects whose lifetime is managed by the container, including -but not limited to those of the container'svalue_type
, -and to obtain their address. All objects residing in storage -allocated by a container's allocator shall be constructed "as if" by -calling theconstruct()
member function on a copy of the -allocator object of the appropriate type. The same objects shall be -destroyed "as if" by callingdestroy()
on a copy of the -same allocator object of the same type. The address of such objects +A copy of this argument shall also be used to construct and +destroy objects whose lifetime is managed by the container, including +but not limited to those of the container'svalue_type
, +and to obtain their address. All objects residing in storage +allocated by a container's allocator shall be constructed "as if" by +calling theconstruct()
member function on a copy of the +allocator object of the appropriate type. The same objects shall be +destroyed "as if" by callingdestroy()
on a copy of the +same allocator object of the same type. The address of such objects shall be obtained "as if" by calling theaddress()
member -function on a copy of the allocator object of the appropriate +function on a copy of the allocator object of the appropriate type. -Finally, a copy of this argument shall be used by its container -object to determine the maximum number of objects of the container's -value_type
the container may store at the same time. The -container member functionmax_size()
-obtains this number -from the - value - returned by - a call - to +Finally, a copy of this argument shall be used by its container +object to determine the maximum number of objects of the container's +value_type
the container may store at the same time. The +container member functionmax_size()
obtains this number +from the value returned by a call toget_allocator().max_size()
. -In all container types defined in this clause that are -parametrized onAllocator
, the member -get_allocator()
returns - a copy - of the -Allocator
object - used to - construct the +In all container types defined in this clause that are +parametrized onAllocator
, the member +get_allocator()
returns a copy of the +Allocator
object used to construct the container.258)-New Footnote: This type may be different from
-Allocator
: -it may be - derived from -Allocator
via -Allocator::rebind<U>::other
for the appropriate +New Footnote: This type may be different fromAllocator
: +it may be derived fromAllocator
via +Allocator::rebind<U>::other
for the appropriate typeU
.+
+ The proposed wording seems cumbersome but I couldn't think of a better -way to describe the - requirement that containers use - their -
+Allocator
to manage only objects (regardless of their -type) that persist over their lifetimes and not, for example, -temporaries created on the stack. That is, containers shouldn't be -required to callAllocator::construct(Allocator::allocate(1), -elem)
just to construct a temporary copy of an element, or -Allocator::destroy(Allocator::address(temp), 1)
to +way to describe the requirement that containers use their +Allocator
to manage only objects (regardless of their +type) that persist over their lifetimes and not, for example, +temporaries created on the stack. That is, containers shouldn't be +required to callAllocator::construct(Allocator::allocate(1), +elem)
just to construct a temporary copy of an element, or +Allocator::destroy(Allocator::address(temp), 1)
to destroy temporaries. -[ @@ -6119,75 +6237,10 @@ post Oxford: This would be rendered NAD Editorial by acceptance of -
-581.
-flush()
not unformatted functionSection: 27.6.2.7 [ostream.unformatted] Status: Ready - Submitter: Martin Sebor Date: 2006-06-14
-View all other issues in [ostream.unformatted].
-View all issues with Ready status.
-Discussion:
-- -The resolution of issue 60 changed
-basic_ostream::flush()
-so as not to require it to behave as an unformatted output function. -That has at least two in my opinion problematic consequences: - -- -First,
-flush()
now callsrdbuf()->pubsync()
-unconditionally, without regard to the state of the stream. I can't -think of any reason whyflush()
should behave differently -from the vast majority of stream functions in this respect. - -- -Second,
- - -flush()
is not required to catch exceptions from -pubsync()
or setbadbit
in response to such -events. That doesn't seem right either, as most other stream functions -do so. - -Proposed resolution:
-- -I propose to revert the resolution of issue 60 with respect to -
- -flush()
. Specifically, I propose to change 27.6.2.6, p7 -as follows: - --Effects: Behaves as an unformatted output function (as described -in 27.6.2.6, paragraph 1). If
- - - -rdbuf()
is not a null -pointer, constructs a sentry object. If this object returns -true
when converted to a value of type bool the function -callsrdbuf()->pubsync()
. If that function returns --1 callssetstate(badbit)
(which may throw -ios_base::failure
(27.4.4.3)). Otherwise, if the -sentry object returnsfalse
, does nothing.Does -not behave as an unformatted output function (as described in -27.6.2.6, paragraph 1).-[ -Kona (2007): Proposed Disposition: Ready -]
- - - - -
582. specialized algorithms and volatile storage
-Section: 20.6.4.1 [uninitialized.copy] Status: Open +
Section: 20.6.10.1 [uninitialized.copy] Status: Open Submitter: Martin Sebor Date: 2006-06-14
-View other active issues in [uninitialized.copy].
View all other issues in [uninitialized.copy].
View all issues with Open status.
Discussion:
@@ -6587,6 +6640,8 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified
Section: 26.3.7 [complex.value.ops] Status: Ready Submitter: Stefan Große Pawig Date: 2006-09-24
+View other active issues in [complex.value.ops].
+View all other issues in [complex.value.ops].
View all issues with Ready status.
Discussion:
@@ -6691,6 +6746,14 @@ or (for C++0X) removed from the standard, since the functionality is already provided by the corresponding overloads of abs().
+[ +Bellevue: +]
+ + ++Bill believes that abs() is a suitable overload. We should remove fabs(). +Proposed resolution:
@@ -6699,19 +6762,19 @@ is already provided by the corresponding overloads of abs(). Change the synopsis in 26.3.1 [complex.synopsis]: -+template<class T>complex<T>fabs(const complex<T>&); +template<class T> complex<T> fabs(const complex<T>&);-Change 26.3.7 [complex.value.ops], p7: +Remove 26.3.7 [complex.value.ops], p7:
-@@ -6729,11 +6792,11 @@ Proposed Disposition: Readytemplate<class T>complex<T>fabs(const complex<T>& x); +template<class T> complex<T> fabs(const complex<T>& x);--7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1. +
-7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1.
596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes
-Section: 27.8.1.4 [filebuf.members] Status: Review +
Section: 27.8.1.4 [filebuf.members] Status: Ready Submitter: Thomas Plum Date: 2006-09-26
View other active issues in [filebuf.members].
View all other issues in [filebuf.members].
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke @@ -6916,7 +6979,8 @@ better than the other.
Robert comments:
-In general, a library of arithmetic types cannot exactly emulate the +
+In general, a library of arithmetic types cannot exactly emulate the behavior of the intrinsic numeric types. There are several ways to tell whether an implementation of the decimal types uses compiler intrinisics or a library. For example: @@ -7014,21 +7078,21 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
-612. numeric_limits::is_modulo insufficently defined
-Section: 18.2.1.2 [numeric.limits.members] Status: Open +
612. numeric_limits::is_modulo insufficiently defined
+Section: 18.2.1.2 [numeric.limits.members] Status: Ready Submitter: Chris Jefferson Date: 2006-11-10
View all other issues in [numeric.limits.members].
-View all issues with Open status.
+View all issues with Ready status.
Discussion:
18.2.1.2 55 states that "A type is modulo if it is possible to add two positive numbers together and have a result that wraps around to a third number that is less". -This seems insufficent for the following reasons: +This seems insufficient for the following reasons:
-
- Doesn't define what that value recieved is.
+- Doesn't define what that value received is.
- Doesn't state the result is repeatable
- Doesn't require that doing addition, subtraction and other operations on all values is defined behaviour.
@@ -7041,10 +7105,17 @@ Pete: is there an ISO definition of modulo? Underflow on signed behavior is und ] +[ +Bellevue: accept resolution, move to ready status. +Does this mandate that is_modulo be true on platforms for which int +happens to b modulo? A: the standard already seems to require that. +]
+ +Proposed resolution:
-Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is ammeded to: +Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to:
+@@ -7118,6 +7189,12 @@ all member functions, during the lifetime of each container object. ]
+[ +post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. +]
+ + +Proposed resolution:
@@ -7129,11 +7206,11 @@ all member functions, during the lifetime of each container object.
617. std::array is a sequence that doesn't satisfy the sequence requirements?
-Section: 23.2.1 [array] Status: New +
Section: 23.2.1 [array] Status: Open Submitter: Bo Persson Date: 2006-12-30
View other active issues in [array].
View all other issues in [array].
-View all issues with New status.
+View all issues with Open status.
Discussion:
The <array> header is given under 23.2 [sequences]. @@ -7164,9 +7241,9 @@ std::array does have, but array isn't mentioned.
618. valarray::cshift() effects on empty array
-Section: 26.5.2.7 [valarray.members] Status: Review +
Section: 26.5.2.7 [valarray.members] Status: Ready Submitter: Gabriel Dos Reis Date: 2007-01-10
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
I would respectfully request an issue be opened with the intention to @@ -7219,689 +7296,12 @@ Kona (2007) Changed proposed wording, added rationale and set to Review. -
-620. valid uses of empty valarrays
-Section: 26.5.2.1 [valarray.cons] Status: Ready - Submitter: Martin Sebor Date: 2007-01-20
-View other active issues in [valarray.cons].
-View all other issues in [valarray.cons].
-View all issues with Ready status.
-Discussion:
-- -The Effects clause for the default
-valarray
ctor -suggests that it is possible to increase the size of an empty -valarray
object by calling other non-const member -functions of the class besidesresize()
. However, such an -interpretation would be contradicted by the requirement on the copy -assignment operator (and apparently also that on the computed -assignments) that the assigned arrays be the same size. See the -reflector discussion starting with c++std-lib-17871. - -- -In addition, Footnote 280 uses some questionable normative -language. - -
- - -Proposed resolution:
-- -Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]): - -
--- - - - - -- -
-valarray();
- -- -Effects: Constructs an object of class -
-valarray<T>
,279) which has zero -lengthuntil it is passed into a library function as a modifiable -lvalue or through a non-constant this pointer.280) - -- -Postcondition:
-size() == 0
. - -- -Footnote 280: This default constructor is essential, since -arrays of
-valarray
are likely to prove useful. -There shall also be a way to change the size of an array after -initialization; this is supplied by the semanticsmay be -useful. The length of an empty array can be increased after -initialization by means of theresize()
member -function. - -
-621. non-const copy assignment operators of helper arrays
-Section: 26.5 [numarray] Status: Ready - Submitter: Martin Sebor Date: 2007-01-20
-View all other issues in [numarray].
-View all issues with Ready status.
-Discussion:
-- -The computed and "fill" assignment operators of
- -valarray
-helper array class templates (slice_array
, -gslice_array
,mask_array
, and -indirect_array
) are const member functions of each class -template (the latter by the resolution of 123 -since they have reference semantics and thus do not affect -the state of the object on which they are called. However, the copy -assignment operators of these class templates, which also have -reference semantics, are non-const. The absence of constness opens -the door to speculation about whether they really are intended to have -reference semantics (existing implementations vary widely). - --Pre-Kona, Martin adds: -
- --I realized that adding the const qualifier to the -functions as I suggested would break the const correctness of the -classes. A few possible solutions come to mind: -
- --
- - - -- Add the const qualifier to the return types of these functions.
-- Change the return type of all the functions to void to match -the signatures of all the other assignment operators these classes -define.
-- Prohibit the copy assignment of these classes by declaring the -copy assignment operators private (as is done and documented by -some implementations).
-Proposed resolution:
-- -Declare the copy assignment operators of all four helper array -class templates const. - -
-- -Specifically, make the following edits: - -
-- -Change the signature in 26.5.5 [template.slice.array] and -26.5.5.1 [slice.arr.assign] as follows: - -
---const slice_array& operator= (const slice_array&) const;
- -- -Change the signature in 26.5.7 [template.gslice.array] and -26.5.7.1 [gslice.array.assign] as follows: - -
---const gslice_array& operator= (const gslice_array&) const;
- -- -Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as -follows: - -
---const mask_array& operator= (const mask_array&) const;
- -- -Change the signature in 26.5.9 [template.indirect.array] and -26.5.9.1 [indirect.array.assign] as follows: - -
-- - --const indirect_array& operator= (const indirect_array&) const;
- -[ -Kona (2007) Added const qualification to the return types and set to Ready. -]
- - - - - -
-622. behavior of
-filebuf
dtor andclose
on errorSection: 27.8.1.17 [fstream.members] Status: Ready - Submitter: Martin Sebor Date: 2007-01-20
-View all issues with Ready status.
-Discussion:
-- -
-basic_filebuf
dtor is specified to have the following -straightforward effects: - --- -Effects: Destroys an object of class -
basic_filebuf
. Callsclose()
. - -- -
-close()
does a lot of potentially complicated processing, -including callingoverflow()
to write out the termination -sequence (to bring the output sequence to its initial shift -state). Since any of the functions called during the processing can -throw an exception, what should the effects of an exception be on the -dtor? Should the dtor catch and swallow it or should it propagate it -to the caller? The text doesn't seem to provide any guidance in this -regard other than the general restriction on throwing (but not -propagating) exceptions from destructors of library classes in -17.4.4.8 [res.on.exception.handling]. - -- -Further, the last thing
-close()
is specified to do is -callfclose()
to close theFILE
pointer. The -last sentence of the Effects clause reads: - --- -... If any of the calls to
overflow
or -std::fclose
fails thenclose
fails. - -- -This suggests that
-close()
might be required to call -fclose()
if and only if none of the calls to -overflow()
fails, and avoid closing theFILE
-otherwise. This way, ifoverflow()
failed to flush out -the data, the caller would have the opportunity to try to flush it -again (perhaps after trying to deal with whatever problem may have -caused the failure), rather than losing it outright. - -- -On the other hand, the function's Postcondition specifies that -
-is_open() == false
, which suggests that it should call -fclose()
unconditionally. However, since -Postcondition clauses are specified for many functions in the -standard, including constructors where they obviously cannot apply -after an exception, it's not clear whether this Postcondition -clause is intended to apply even after an exception. - -- -It might be worth noting that the traditional behavior (Classic -Iostreams
- -fstream::close()
and Cfclose()
) -is to close theFILE
unconditionally, regardless of -errors. - -[ -See 397 and 418 for related issues. -]
- - - - -Proposed resolution:
-- -After discussing this on the reflector (see the thread starting with -c++std-lib-17650) we propose that
-close()
be clarified to -match the traditional behavior, that is to close theFILE
-unconditionally, even after errors or exceptions. In addition, we -propose the dtor description be amended so as to explicitly require it -to catch and swallow any exceptions thrown byclose()
. - -- -Specifically, we propose to make the following edits in -27.8.1.4 [filebuf.members]: - -
-----basic_filebuf<charT,traits>* close();
- -- -Effects: If
-is_open() == false
, returns a null -pointer. If a put area exists, calls -overflow(traits::eof())
to flush characters. If the last -virtual member function called on*this
(between -underflow
,overflow
,seekoff
, -andseekpos
) wasoverflow
then calls -a_codecvt.unshift
(possibly several times) to determine a -termination sequence, inserts those characters and calls -overflow(traits::eof())
again. Finally, regardless -of whether any of the preceding calls fails or throws an exception, -the functionitcloses the file ("as if" by calling -std::fclose(file)
).334) If any of the calls -made by the functionto, includingoverflow
-orstd::fclose
, -fails thenclose
fails by returning a null pointer. -If one of these calls throws an exception, the exception is caught and -rethrown after closing the file. - -- -And to make the following edits in 27.8.1.2 [filebuf.cons]. - -
--- - - - - ---virtual ~basic_filebuf();
- -- -Effects: Destroys an object of class -
-basic_filebuf<charT,traits>
. Calls -close()
. If an exception occurs during the -destruction of the object, including the call toclose()
, -the exception is caught but not rethrown (see -17.4.4.8 [res.on.exception.handling]). - -
-623.
-pubimbue
forbidden to callimbue
Section: 27.1.1 [iostream.limits.imbue] Status: Ready - Submitter: Martin Sebor Date: 2007-01-20
-View all issues with Ready status.
-Discussion:
-- -27.1.1 [iostream.limits.imbue] specifies that "no function described in -clause 27 except for
-ios_base::imbue
causes any instance -ofbasic_ios::imbue
or -basic_streambuf::imbue
to be called." - -- -That contradicts the Effects clause for -
- - -basic_streambuf::pubimbue()
which requires the function -to do just that: callbasic_streambuf::imbue()
. - -Proposed resolution:
-- -To fix this, rephrase the sentence above to allow -
-pubimbue
to do what it was designed to do. Specifically. -change 27.1.1 [iostream.limits.imbue], p1 to read: - -- - - - - -- -No function described in clause 27 except for -
ios_base::imbue
andbasic_filebuf::pubimbue
-causes any instance ofbasic_ios::imbue
or -basic_streambuf::imbue
to be called. ... - -
-624.
-valarray
assignment and arrays of unequal lengthSection: 26.5.2.2 [valarray.assign] Status: Ready - Submitter: Martin Sebor Date: 2007-01-20
-View all issues with Ready status.
-Discussion:
-- -The behavior of the
-valarray
copy assignment operator is -defined only when both sides have the same number of elements and the -spec is explicit about assignments of arrays of unequal lengths having -undefined behavior. - -- -However, the generalized subscripting assignment operators overloaded -on
-slice_array
et al (26.5.2.2 [valarray.assign]) don't have any -such restriction, leading the reader to believe that the behavior of -these overloads is well defined regardless of the lengths of the -arguments. - -- -For example, based on the reading of the spec the behavior of the -snippet below can be expected to be well-defined: - -
-const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2 - const std::valarray<int> a (1, 3); // a = { 1, 1, 1 } - std::valarray<int> b (2, 4); // b = { 2, 2, 2, 2 } - - b = a [from_0_to_3]; --- -In practice,
- -b
may end up being{ 1, 1, 1 }
, -{ 1, 1, 1, 2 }
, or anything else, indicating that -existing implementations vary. - --Quoting from Section 3.4, Assignment operators, of Al Vermeulen's -Proposal for Standard C++ Array Classes (see c++std-lib-704; -N0308): -
-- -- ...if the size of the array on the right hand side of the equal - sign differs from the size of the array on the left, a run time - error occurs. How this error is handled is implementation - dependent; for compilers which support it, throwing an exception - would be reasonable. -
-And see more history in -N0280. -
- -- -It has been argued in discussions on the committee's reflector that -the semantics of all
-valarray
assignment operators should -be permitted to be undefined unless the length of the arrays being -assigned is the same as the length of the one being assigned from. See -the thread starting at c++std-lib-17786. - -- -In order to reflect such views, the standard must specify that the -size of the array referred to by the argument of the assignment must -match the size of the array under assignment, for example by adding a -Requires clause to 26.5.2.2 [valarray.assign] as follows: - -
-- -- -Requires: The length of the array to which the argument refers -equals
size()
. - -- -Note that it's far from clear that such leeway is necessary in order -to implement
- - -valarray
efficiently. - -Proposed resolution:
--Insert new paragraph into 26.5.2.2 [valarray.assign]: -
- --- - - - - -valarray<T>& operator=(const slice_array<T>&); -valarray<T>& operator=(const gslice_array<T>&); -valarray<T>& operator=(const mask_array<T>&); -valarray<T>& operator=(const indirect_array<T>&); -----Requires: The length of the array to which the argument refers -equals
-size()
. --These operators allow the results of a generalized subscripting operation to be assigned directly to a valarray. -
-
-625. mixed up Effects and Returns clauses
-Section: 17 [library] Status: Open - Submitter: Martin Sebor Date: 2007-01-20
-View all other issues in [library].
-View all issues with Open status.
-Discussion:
-- -Many member functions of
basic_string
are overloaded, -with some of the overloads taking astring
argument, -othersvalue_type*
, otherssize_type
, and -others stilliterators
. Often, the requirements on one of -the overloads are expressed in the form of Effects, -Throws, and in the Working Paper -(N2134) -also Remark clauses, while those on the rest of the overloads -via a reference to this overload and using a Returns clause. - --
- -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 usetraits::eq()
. - --
- -find(const charT *s, size_type pos)
is specified to -returnfind(string(s), pos)
by a Returns clause -and so it is not required to usetraits::eq()
. However, -the Working Paper has replaced the original informative Note -about the function usingtraits::length()
with a -normative requirement in the form of a Remark. Calling -traits::length()
may be suboptimal, for example when the -argument is a very long array whose initial substring doesn't appear -anywhere in*this
. - --
- -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 throwout_of_range
ifpos > -size()
. - --
- -insert(size_type pos, string str)
is specified to return -insert(pos, str, 0, npos)
by a Returns clause and -so its effects whenpos > size()
are strictly speaking -unspecified. - - -- -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. -]
- - - -Proposed resolution:
--
- - - - - -
-626. new Remark clauses not documented
-Section: 17.3.1.3 [structure.specifications] Status: Open - Submitter: Martin Sebor Date: 2007-01-20
-View all other issues in [structure.specifications].
-View all issues with Open 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. -]
- - - -Proposed resolution:
--
- - - - - -
-627. Low memory and exceptions
-Section: 18.5.1.1 [new.delete.single] Status: Open - Submitter: P.J. Plauger Date: 2007-01-23
-View all other issues in [new.delete.single].
-View all issues with Open 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. -
- - -Proposed resolution:
--
- - - - -
629. complex
-insertion and locale dependence Section: 26.3.6 [complex.ops] Status: Open +
Section: 26.3.6 [complex.ops] Status: Ready Submitter: Gabriel Dos Reis Date: 2007-01-28
View all other issues in [complex.ops].
-View all issues with Open status.
+View all issues with Ready status.
Discussion:
is there an issue opened for (0,3) as complex number with @@ -7927,12 +7327,39 @@ dedicated facet. Then complex should use that solution.
[ +Bellevue: +]
+ + +++After much discussion, we agreed on the following: Add a footnote: +
++[In a locale in which comma is being used as a decimal point character, +inserting "showbase" into the output stream forces all outputs to show +an explicit decimal point character; then all inserted complex sequences +will extract unambiguously.] +
++And move this to READY status. +
+Proposed resolution:
+Add a footnote to 26.3.6 [complex.ops] p16:
++[In a locale in which comma is being used as a decimal point character, +inserting "showbase" into the output stream forces all outputs to show +an explicit decimal point character; then all inserted complex sequences +will extract unambiguously.] ++ @@ -7941,7 +7368,6 @@ dedicated facet. Then complex should use that solution.630. arrays of valarray
Section: 26.5.2.1 [valarray.cons] Status: Open Submitter: Martin Sebor Date: 2007-01-28
-View other active issues in [valarray.cons].
View all other issues in [valarray.cons].
View all issues with Open status.
Discussion:
@@ -8012,6 +7438,16 @@ assignment operator. +[ +Bellevue: +]
+ + ++If no proposed wording by June meeting, this issue should be closed NAD. ++ +Proposed resolution:
@@ -8216,6 +7652,7 @@ away.
+Proposed resolution:
@@ -8229,6 +7666,17 @@ O(1). Alan has volunteered to provide wording. ] +
[ +Bellevue: +]
+ + ++Mandating O(1) size will not fly, too many implementations would be +invalidated. Alan to provide wording that toughens wording, but that +does not absolutely mandate O(1). ++ @@ -8317,9 +7765,9 @@ no resolution to this issue was recorded. Moved to Open.
638. deque end invalidation during erase
-Section: 23.2.2.3 [deque.modifiers] Status: Review +
Section: 23.2.2.3 [deque.modifiers] Status: Ready Submitter: Steve LoBasso Date: 2007-02-17
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
The standard states at 23.2.2.3 [deque.modifiers]/4: @@ -8353,6 +7801,17 @@ pop_front() with size() == 1
[ +Post Kona, Steve LoBasso notes: +]
+ + ++My only issue with the proposed resolution is that it might not be clear +that pop_front() [where size() == 1] can invalidate past-the-end +iterators. ++Proposed resolution:
@@ -8384,189 +7843,19 @@ Kona (2007): Proposed wording added and moved to Review. ] - - - -
-645. Missing members in match_results
-Section: 28.10 [re.results] Status: Review - Submitter: Daniel Krügler Date: 2007-02-26
-View other active issues in [re.results].
-View all other issues in [re.results].
-View all issues with Review 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: ]
- - - -
-653. Library reserved names
-Section: 1.2 [intro.refs] Status: Open - Submitter: Alisdair Meredith Date: 2007-03-08
-View all other issues in [intro.refs].
-View all issues with Open 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. -
- --
+Note that there is existing code that relies on iterators not being +invalidated, but there are also existing implementations that do +invalidate iterators. Thus, such code is not portable in any case. There +is a pop_front() note, which should possibly be a separate issue. Mike +Spertus to evaluate and, if need be, file an issue.- 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. -]Proposed resolution:
- - @@ -8581,26 +7870,26 @@ specific documents add their rules to this issue until the list is complete. Greg Herlihy has clearly demonstrated that a user defined input iterator should have an operator->(), even if its value type is a built-in type (comp.std.c++, "Re: Should any iterator -have an operator->() in C++0x?", March 2007). And as Howard +have an operator->() in C++0x?", March 2007). And as Howard Hinnant remarked in the same thread that the input iterator istreambuf_iterator doesn't have one, this must be a defect!Based on Greg's example, the following code demonstrates the issue: -
#include <iostream> - #include <fstream> - #include <streambuf> +#include <iostream> + #include <fstream> + #include <streambuf> - typedef char C; - int main () - { - std::ifstream s("filename", std::ios::in); - std::istreambuf_iterator<char> i(s); + typedef char C; + int main () + { + std::ifstream s("filename", std::ios::in); + std::istreambuf_iterator<char> i(s); - (*i).~C(); // This is well-formed... - i->~C(); // ... so this should be supported! - } + (*i).~C(); // This is well-formed... + i->~C(); // ... so this should be supported! + }@@ -8608,9 +7897,9 @@ Of course, operator-> is also needed when the value_type of istreambuf_iterator is a class.
-The operator-> could be implemented in various ways. For instance, +The operator-> could be implemented in various ways. For instance, by storing the current value inside the iterator, and returning its -address. Or by returning a proxy, like operator_arrow_proxy, from +address. Or by returning a proxy, like operator_arrow_proxy, from http://www.boost.org/boost/iterator/iterator_facade.hpp
@@ -8671,14 +7960,14 @@ may in fact be a proxy. AFAIK, the resolution of 445 ("iterator_traits::reference unspecified for some iterator categories") implies that for any iterator class Iter, the return type of operator->() is Iter::pointer, by -definition. I don't think Iter::pointer needs to be a raw pointer. +definition. I don't think Iter::pointer needs to be a raw pointer.
Still I wouldn't mind if the text "operator-> may return a proxy" would be removed from the resolution. I think it's up to the library -implementation, how to implement istreambuf_iterator::operator->(). As +implementation, how to implement istreambuf_iterator::operator->(). As longs as it behaves as expected: i->m should have the same effect as -(*i).m. Even for an explicit destructor call, i->~C(). The main issue +(*i).m. Even for an explicit destructor call, i->~C(). The main issue is just: istreambuf_iterator should have an operator->()!
-661. New 27.6.1.2.2 changes make special extractions useless
-Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: Ready - Submitter: Daniel Krügler Date: 2007-04-01
-View other active issues in [istream.formatted.arithmetic].
-View all other issues in [istream.formatted.arithmetic].
-View all issues with Ready status.
-Discussion:
--To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong -the explicit description of the extraction of the types short and int in -terms of as-if code fragments. -
- --
- - -- -The corresponding as-if extractions in paragraph 2 and 3 will never -result in a change of the operator>> argument val, because the -contents of the local variable lval is in no case written into val. -Furtheron both fragments need a currently missing parentheses in the -beginning of the if-statement to be valid C++. -
-- I would like to ask whether the omission of a similar explicit -extraction of unsigned short and unsigned int in terms of long - -compared to their corresponding new insertions, as described in -27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or -an -oversight. -
-Proposed resolution:
--
- - -- -
--In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment -
-- -typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; -iostate err = 0; -long lval; -use_facet<numget>(loc).get(*this, 0, *this, err, lval ); -if (err == 0) { -&&if (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))- err = ios_base::failbit; - else - val = static_cast<short>(lval); -} -setstate(err); --Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment -
- --typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; -iostate err = 0; -long lval; -use_facet<numget>(loc).get(*this, 0, *this, err, lval ); -if (err == 0) { -&&if (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))- err = ios_base::failbit; - else - val = static_cast<int>(lval); -} -setstate(err); -- ---- -
-[ -Kona (2007): Note to the editor: the name lval in the call to use_facet -is incorrectly italicized in the code fragments corresponding to -operator>>(short &) and operator >>(int &). Also, val -- which appears -twice on the line with the static_cast in the proposed resolution -- -should be italicized. Also, in response to part two of the issue: this -is deliberate. -]
- - - - - -
-664. do_unshift for codecvt<char, char, mbstate_t>
-Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: Ready - Submitter: Thomas Plum Date: 2007-04-16
-View other active issues in [locale.codecvt.virtuals].
-View all other issues in [locale.codecvt.virtuals].
-View all issues with Ready status.
-Discussion:
--22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift): -
- -- --Effects: Places characters starting at to that should be appended to -terminate a sequence when the current stateT is given by -state.237) Stores no more than (to_limit - -to) destination elements, and leaves the to_next -pointer pointing one beyond the last element successfully stored. -codecvt<char, char, mbstate_t> stores no characters. -
-The following objection has been raised: -
- -- --Since the C++ Standard permits a nontrivial conversion for the required -instantiations of codecvt, it is overly restrictive to say that -do_unshift must store no characters and return noconv. -
-[Plum ref _222152Y50] -
- - -Proposed resolution:
--Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: -
- --- - - - - --Effects: Places characters starting at to that should be -appended to terminate a sequence when the current stateT is -given by state.237) Stores no more than (to_limit -to) -destination elements, and leaves the to_next pointer pointing one -beyond the last element successfully stored.
-codecvt<char, char, -mbstate_t> stores no characters.-
-665. do_unshift return value
-Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: Ready - Submitter: Thomas Plum Date: 2007-04-16
-View other active issues in [locale.codecvt.virtuals].
-View all other issues in [locale.codecvt.virtuals].
-View all issues with Ready status.
-Discussion:
--22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: -
- -- --codecvt<char,char,mbstate_t>, returns noconv. -
-The following objection has been raised: -
- -- --Despite what the C++ Standard -says, unshift can't always return noconv for the default facets, since -they can be nontrivial. At least one implementation does whatever the -C functions do. -
-[Plum ref _222152Y62] -
- - -Proposed resolution:
--Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: -
- --- - - - - - -Returns: An enumeration value, as summarized in Table 76:
-...
--
-codecvt<char,char,mbstate_t>, returns noconv.-
-666. moneypunct::do_curr_symbol()
-Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: Ready - Submitter: Thomas Plum Date: 2007-04-16
-View all other issues in [locale.moneypunct.virtuals].
-View all issues with Ready status.
-Discussion:
--22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says -
- -- --257) For international -specializations (second template parameter true) this is always four -characters long, usually three letters and a space. -
-The following objection has been raised: -
- -- --The international currency -symbol is whatever the underlying locale says it is, not necessarily -four characters long. -
-[Plum ref _222632Y41] -
- - -Proposed resolution:
--Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: -
- --- - - - --253) For international specializations (second template -parameter true) this is
-alwaystypically -four characters long, usually three letters and a space. -
667. money_get's widened minus sign
Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open @@ -8941,9 +7988,9 @@ four characters long, usually three letters and a space.
@@ -8956,10 +8003,10 @@ objection has been raised: Some implementations interpret this to mean that a facet derived from ctype<wchar_t> can provide its own member do_widen(char) which produces e.g. L'@' for the "widened" minus sign, and that the -'@' symbol will appear in the resulting sequence of digits. Other +'@' symbol will appear in the resulting sequence of digits. Other implementations have assumed that one or more places in the standard permit the -implementation to "hard-wire" L'-' as the "widened" minus sign. Are -both interpretations permissible, or only one? +implementation to "hard-wire" L'-' as the "widened" minus sign. Are +both interpretations permissible, or only one?-The result is returned as an integral value -stored in units or as a sequence of digits possibly preceded by a -minus sign (as produced by ct.widen(c) where c is '-' or in the range +The result is returned as an integral value +stored in units or as a sequence of digits possibly preceded by a +minus sign (as produced by ct.widen(c) where c is '-' or in the range from '0' through '9', inclusive) stored in digits.
@@ -8976,6 +8023,18 @@ Kona (2007): Bill and Dietmar to provide proposed wording. ]
+[ +post Bellevue: Bill adds: +]
+ + ++The Standard is clear that the minus sign stored in digits is ct.widen('-'). +The subject string must contain characters c in the set [-0123456789] +which are translated by ct.widen(c) calls before being stored in digits; +the widened characters are not relevant to the parsing of the subject string. ++Proposed resolution:
@@ -8999,7 +8058,7 @@ Kona (2007): Bill and Dietmar to provide proposed wording.
@@ -9009,8 +8068,8 @@ objection has been raised:If pos or neg is empty, the sign component is -optional, and if no sign is detected, the result is given the sign +optional, and if no sign is detected, the result is given the sign that corresponds to the source of the empty string.
@@ -9046,14 +8105,14 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor-A negative_sign of "" means "there is no -way to write a negative sign" not "any null sequence is a negative +A negative_sign of "" means "there is no +way to write a negative sign" not "any null sequence is a negative sign, so it's always there when you look for it".
-If the first character of pos is equal to the first character of neg, +If the first character of pos is equal to the first character of neg, or if both strings are empty, the result is given a positive sign.
One interpretation is that an input sequence must match either the positive pattern or the negative pattern, and then in either event it -is interpreted as positive. The following objections has been raised: +is interpreted as positive. The following objections has been raised:
@@ -9091,7 +8150,7 @@ Bill to provide proposed wording and interpretation of existing wording.
@@ -9100,7 +8159,7 @@ The following objection has been raised:-The value space indicates that at least one space is required at +The value space indicates that at least one space is required at that position.
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) +Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
@@ -9201,11 +8260,11 @@ Kona (2007): Robert volunteers to propose wording.
672. Swappable requirements need updating
-Section: 20.1.1 [utility.arg.requirements] Status: Review +
Section: 20.1.1 [utility.arg.requirements] Status: Ready Submitter: Howard Hinnant Date: 2007-05-04
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
The current Swappable is: @@ -9361,16 +8420,18 @@ swap to be rvalues).
673. unique_ptr update
-Section: 20.6.5 [unique.ptr] Status: Open +
Section: 20.6.11 [unique.ptr] Status: Ready Submitter: Howard Hinnant Date: 2007-05-04
-View all issues with Open status.
+View other active issues in [unique.ptr].
+View all other issues in [unique.ptr].
+View all issues with Ready status.
Discussion:
Since the publication of N1856 there have been a few small but significant advances which should be included into unique_ptr. There exists a -reference implmenation +example implmenation for all of these changes.
@@ -9405,7 +8466,7 @@ pointer type is actually a T*. This can easily be accomplished for unique_ptr by having the deleter define the pointer type: D::pointer. Furthermore this type can easily be defaulted to T* should the deleter D choose not to define a pointer -type (reference implementation +type (example implementation here). This change has no run time overhead. It has no interface overhead on authors of custom delter types. It simply allows (but not requires) @@ -9482,7 +8543,7 @@ the proposed resolutions below.-Change 20.6.5.2 [unique.ptr.single]: +Change 20.6.11.2 [unique.ptr.single]:
template <class T, class D = default_delete<T>> class unique_ptr { @@ -9493,7 +8554,7 @@ Change 20.6.5.2 [unique.ptr.single]:-Change 20.6.5.2.4 [unique.ptr.single.observers]: +Change 20.6.11.2.4 [unique.ptr.single.observers]:
- - - - -T&typename add_lvalue_reference<T>::type operator*() const; @@ -9503,7 +8564,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]:-Change 20.6.5.2 [unique.ptr.single]: +Change 20.6.11.2 [unique.ptr.single]:
template <class T, class D = default_delete<T>> class unique_ptr { @@ -9529,13 +8590,13 @@ public: exists, then unique_ptr<T, D>::pointer is a typedef to remove_reference<D>::type::pointer. Otherwise unique_ptr<T, D>::pointer is a typedef to T*. -The type unique_ptr<T, D>::pointer must be CopyConstructible +The type unique_ptr<T, D>::pointer shall be CopyConstructible and CopyAssignable.-Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]:
unique_ptr(T*pointer p); @@ -9557,10 +8618,10 @@ unique_ptr(T*pointer p, const A&& d);-23- Requires: If D is not a reference type, construction of the deleter D from an rvalue of type E -must be well formed and not throw an exception. If D is a -reference type, then E must be the same type as D +
@@ -9575,20 +8636,20 @@ internally stored deleter which was constructed frommustshall be well formed and not throw an exception. If D is a +reference type, then Emustshall be the same type as D (diagnostic required).U*unique_ptr<U,E>::pointer -must be implicitly convertible toT*+mustshall be implicitly convertible toT*pointer.-Change 20.6.5.2.3 [unique.ptr.single.asgn]: +Change 20.6.11.2.3 [unique.ptr.single.asgn]:
-8- Requires: Assignment of the deleter D from an rvalue -D must not throw an exception.
U*-unique_ptr<U,E>::pointer must be implicitly +Dmustshall not throw an exception.U*+unique_ptr<U,E>::pointermustshall be implicitly convertible toT*pointer.-Change 20.6.5.2.4 [unique.ptr.single.observers]: +Change 20.6.11.2.4 [unique.ptr.single.observers]:
@@ -9598,7 +8659,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]:-Change 20.6.5.2.5 [unique.ptr.single.modifiers]: +Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
@@ -9608,7 +8669,7 @@ Change 20.6.5.2.5 [unique.ptr.single.modifiers]:-Change 20.6.5.3 [unique.ptr.runtime]: +Change 20.6.11.3 [unique.ptr.runtime]:
template <class T, class D> class unique_ptr<T[], D> { @@ -9628,7 +8689,7 @@ public:-Change 20.6.5.3.1 [unique.ptr.runtime.ctor]: +Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
@@ -9647,7 +8708,7 @@ these members. -- end note]-Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]: +Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
@@ -9662,89 +8723,53 @@ templated overload. -- end note]--Change 20.6.5.4 [unique.ptr.compiletime]: -
- -- -template <class T, class D, size_t N> class unique_ptr<T[N], D> { -public: - typedef implementation pointer; - ... - explicit unique_ptr(T*pointer p); - ... - unique_ptr(T*pointer p, implementation defined d); - unique_ptr(T*pointer p, implementation defined d); - ... -T*pointer get() const; - ... -T*pointer release(); - void reset(T*pointer p =0pointer()); -}; --Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]: -
- ---void reset(- -T*pointer p =0pointer()); ---1- Requires: Does not accept pointer types which are convertible -to
- -T*pointer (dignostic required). [Note: One implementation -technique is to create a private templated overload. --end note] --Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]:
unique_ptr();-Requires: D must be default constructible, and that -construction must not throw an exception. D must not be a +Requires: D
mustshall be default constructible, and that +constructionmustshall not throw an exception. Dmustshall not be a reference type or pointer type (diagnostic required).unique_ptr(T*pointer p);-Requires: The expression D()(p) must be well formed. -The default constructor of D must not throw an exception. -D must not be a reference type or pointer type (diagnostic +Requires: The expression D()(p)
mustshall be well formed. +The default constructor of Dmustshall not throw an exception. +Dmustshall not be a reference type or pointer type (diagnostic required).-Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]:
unique_ptr();-Requires: D must be default constructible, and that -construction must not throw an exception. D must not be a +Requires: D
mustshall be default constructible, and that +constructionmustshall not throw an exception. Dmustshall not be a reference type or pointer type (diagnostic required).unique_ptr(T*pointer p);@@ -9759,110 +8784,13 @@ required). --Requires: The expression D()(p) must be well formed. -The default constructor of D must not throw an exception. -D must not be a reference type or pointer type (diagnostic +Requires: The expression D()(p)
mustshall be well formed. +The default constructor of Dmustshall not throw an exception. +Dmustshall not be a reference type or pointer type (diagnostic required).
-674. shared_ptr interface changes for consistency with N1856
-Section: 20.6.6.2 [util.smartptr.shared] Status: Ready - Submitter: Peter Dimov Date: 2007-05-05
-View other active issues in [util.smartptr.shared].
-View all other issues in [util.smartptr.shared].
-View all issues with Ready status.
-Discussion:
--N1856 does not propose -any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate -and to interoperate with unique_ptr as it does with auto_ptr. -
- - -Proposed resolution:
- --Change 20.6.6.2 [util.smartptr.shared] as follows: -
- --- -template<class Y> explicit shared_ptr(auto_ptr<Y>-&&& r); -template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete; -template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r); -... -template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r); -template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete; -template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);-Change 20.6.6.2.1 [util.smartptr.shared.const] as follows: -
- --- -template<class Y> shared_ptr(auto_ptr<Y>-&&& r);-Add to 20.6.6.2.1 [util.smartptr.shared.const]: -
- --- -template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);-- -- --Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is - not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) ) - otherwise. -
- --Exception safety: If an exception is thrown, the constructor has no effect. -
--Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows: -
- --- -template<class Y> shared_ptr& operator=(auto_ptr<Y>-&&& r);-Add to 20.6.6.2.3 [util.smartptr.shared.assign]: -
- --- - - -template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);- --- ---4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this). -
---5- Returns: *this. -
-[ -Kona (2007): We may need to open an issue (743) to deal with the question of -whether shared_ptr needs an rvalue swap. -]
- - - - -
675. Move assignment of containers
-Section: 23.1 [container.requirements] Status: Ready +
Section: 23.1 [container.requirements] Status: Open Submitter: Howard Hinnant Date: 2007-05-05
View other active issues in [container.requirements].
View all other issues in [container.requirements].
-View all issues with Ready status.
+View all issues with Open status.
Discussion:
James Hopkin pointed out to me that if vector<T> move assignment is O(1) @@ -9928,16 +8856,30 @@ before this construction +
[ +post Bellevute Howard adds: +]
+ + ++++This issue was voted to WP in Bellevue, but accidently got stepped on by +N2525 +which was voted to WP simulataneously. Moving back to Open for the purpose of getting +the wording right. The intent of this issue and N2525 are not in conflict. +
+
676. Moving the unordered containers
-Section: 23.4 [unord] Status: Ready +
Section: 23.4 [unord] Status: Open Submitter: Howard Hinnant Date: 2007-05-05
View other active issues in [unord].
View all other issues in [unord].
-View all issues with Ready status.
+View all issues with Open status.
Discussion:
Move semantics are missing from the unordered containers. The proposed @@ -10535,311 +9477,45 @@ Add to 23.4.4.2 [unord.multiset.swap]: - - - -
-679. resize parameter by value
-Section: 23.2 [sequences] Status: Ready - Submitter: Howard Hinnant Date: 2007-06-11
-View all issues with Ready status.
-Discussion:
--The C++98 standard specifies that one member function alone of the containers -passes its parameter (T) by value instead of by const reference: -
- -- -void resize(size_type sz, T c = T()); --This fact has been discussed / debated repeatedly over the years, the first time -being even before C++98 was ratified. The rationale for passing this parameter by -value has been: -
- --- --So that self referencing statements are guaranteed to work, for example: -
--v.resize(v.size() + 1, v[0]); --However this rationale is not convincing as the signature for push_back is: -
- -- -void push_back(const T& x); --And push_back has similar semantics to resize (append). -And push_back must also work in the self referencing case: -
- -- -v.push_back(v[0]); // must work --The problem with passing T by value is that it can be significantly more -expensive than passing by reference. The converse is also true, however when it is -true it is usually far less dramatic (e.g. for scalar types). -
- --Even with move semantics available, passing this parameter by value can be expensive. -Consider for example vector<vector<int>>: -
- -- -std::vector<int> x(1000); -std::vector<std::vector<int>> v; -... -v.resize(v.size()+1, x); --In the pass-by-value case, x is copied once to the parameter of -resize. And then internally, since the code can not know at compile -time by how much resize is growing the vector, x is -usually copied (not moved) a second time from resize's parameter into its proper place -within the vector. -
- --With pass-by-const-reference, the x in the above example need be copied -only once. In this case, x has an expensive copy constructor and so any -copies that can be saved represents a significant savings. -
- --If we can be efficient for push_back, we should be efficient for resize -as well. The resize taking a reference parameter has been coded and shipped in the -CodeWarrior library with no reports of problems which I am aware of. -
- - - -Proposed resolution:
--Change 23.2.2 [deque], p2: -
- -- -class deque { - ... - void resize(size_type sz, const T& c); --Change 23.2.2.2 [deque.capacity], p3: -
- -- -void resize(size_type sz, const T& c); --Change 23.2.3 [list], p2: -
- -- -class list { - ... - void resize(size_type sz, const T& c); --Change 23.2.3.2 [list.capacity], p3: -
- -- -void resize(size_type sz, const T& c); --Change 23.2.5 [vector], p2: -
- -- -class vector { - ... - void resize(size_type sz, const T& c); --Change 23.2.5.2 [vector.capacity], p11: -
- -- - - - - - -void resize(size_type sz, const T& c); -
-680. move_iterator operator-> return
-Section: 24.4.3.1 [move.iterator] Status: Ready - Submitter: Howard Hinnant Date: 2007-06-11
-View all issues with Ready status.
-Discussion:
--move_iterator's operator-> return type pointer -does not consistently match the type which is returned in the description -in 24.4.3.3.5 [move.iter.op.ref]. -
- -- - -template <class Iterator> -class move_iterator { -public: - ... - typedef typename iterator_traits<Iterator>::pointer pointer; - ... - pointer operator->() const {return current;} - ... -private: - Iterator current; // exposition only -}; --There are two possible fixes. -
- --
- -- pointer operator->() const {return &*current;}
-- typedef Iterator pointer;
--The first solution is the one chosen by reverse_iterator. A potential -disadvantage of this is it may not work well with iterators which return a -proxy on dereference and that proxy has overloaded operator&(). Proxy -references often need to overloaad operator&() to return a proxy -pointer. That proxy pointer may or may not be the same type as the iterator's -pointer type. -
- --By simply returning the Iterator and taking advantage of the fact that -the language forwards calls to operator-> automatically until it -finds a non-class type, the second solution avoids the issue of an overloaded -operator&() entirely. -
- -Proposed resolution:
--Change the synopsis in 24.4.3.1 [move.iterator]: -
- -- - - - - - -typedeftypename iterator_traits<Iterator>::pointerpointer; -
-684. Unclear which members of match_results should be used in comparison
-Section: 28.10 [re.results] Status: Review - Submitter: Nozomu Katoo Date: 2007-05-27
-View other active issues in [re.results].
-View all other issues in [re.results].
-View all issues with Review 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: +Voted to WP in Bellevue. ]
---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. +post Bellevue, Pete notes: ]
- -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. +Please remind people who are reviewing issues to check that the text +modifications match the current draft. Issue 676, for example, adds two +overloads for unordered_map::insert taking a hint. One takes a +const_iterator and returns a const_iterator, and the other takes an +iterator and returns an iterator. This was correct at the time the issue +was written, but was changed in Toronto so there is only one hint +overload, taking a const_iterator and returning an iterator.
--- -template<class BidirectionalIterator, class Allocator> - bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, - const match_results<BidirectionalIterator, Allocator>& m2); ----Returns: !(m1 == m2). +This issue is not ready. In addition to the relatively minor signature +problem I mentioned earlier, it puts requirements in the wrong places. +Instead of duplicating requirements throughout the template +specifications, it should put them in the front matter that talks about +requirements for unordered containers in general. This presentation +problem is editorial, but I'm not willing to do the extensive rewrite +that it requires. Please put it back into Open status.
--template<class BidirectionalIterator, class Allocator> - void swap(match_results<BidirectionalIterator, Allocator>& m1, - match_results<BidirectionalIterator, Allocator>& m2); -----Returns: m1.swap(m2). -
-
685. reverse_iterator/move_iterator difference has invalid signatures
-Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: Review +
Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: Ready Submitter: Bo Persson Date: 2007-06-10
-View all issues with Review status.
+View all issues with Ready status.
Discussion:
In C++03 the difference between two reverse_iterators @@ -10855,8 +9531,8 @@ In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdif
template<class Iterator1, class Iterator2> typename reverse_iterator<Iterator>::difference_type - operator-(const reverse_iterator<Iterator1>& x, - const reverse_iterator<Iterator2>& y); + operator-(const reverse_iterator<Iterator1>& x, + const reverse_iterator<Iterator2>& y);The return type is the same as the C++03 one, based on the no longer @@ -10882,13 +9558,8 @@ Change the synopsis in 24.4.1.1 [reverse.iterator]:
template <class Iterator1, class Iterator2>-typename reverse_iterator<Iterator>::difference_typeauto operator-( const reverse_iterator<Iterator1>& x, - const reverse_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2)); + const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);--Returns: y.current - x.current. -
-@@ -10899,7 +9570,7 @@ Change 24.4.1.3.19 [reverse.iter.opdiff]:
template <class Iterator1, class Iterator2>typename reverse_iterator<Iterator>::difference_typeauto operator-( const reverse_iterator<Iterator1>& x, - const reverse_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2)); + const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);@@ -10917,13 +9588,8 @@ Change the synopsis in 24.4.3.1 [move.iterator]:
template <class Iterator1, class Iterator2>-typename move_iterator<Iterator>::difference_typeauto operator-( const move_iterator<Iterator1>& x, - const move_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2)); + const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());--Returns: y.current - x.current. -
-@@ -10934,7 +9600,7 @@ Change 24.4.3.3.14 [move.iter.nonmember]:
template <class Iterator1, class Iterator2>typename move_iterator<Iterator>::difference_typeauto operator-( const move_iterator<Iterator1>& x, - const move_iterator<Iterator2>& y) -> decltype(operator-(Iterator1, Iterator2)); + const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());@@ -10943,122 +9609,23 @@ Change 24.4.3.3.14 [move.iter.nonmember]:
-686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type
-Section: 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] Status: Open - Submitter: Beman Dawes Date: 2007-06-14
-View all issues with Open status.
-Discussion:
--The standard library uses the operator unspecified-bool-type() const idiom in -five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity -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. -
- - -Proposed resolution:
--To the Returns paragraph for operator unspecified-bool-type() -const -of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.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. +Pre Bellevue: This issue needs to wait until the auto -> return language feature +goes in. ]
-
-687. shared_ptr conversion constructor not constrained
-Section: 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] Status: Ready - Submitter: Peter Dimov Date: 2007-05-10
-View all issues with Ready status.
-Discussion:
--Since all conversions from shared_ptr<T> to shared_ptr<U> have the same -rank regardless of the relationship between T and U, reasonable user -code that works with raw pointers fails with shared_ptr: -
- -- -void f( shared_ptr<void> ); -void f( shared_ptr<int> ); - -int main() -{ - f( shared_ptr<double>() ); // ambiguous -} --Now that we officially have enable_if, we can constrain the constructor -and the corresponding assignment operator to only participate in the -overload resolution when the pointer types are compatible. -
- - -Proposed resolution:
--In 20.6.6.2.1 [util.smartptr.shared.const], change: -
- -- ---14- Requires:
For the second constructorThe -second constructor shall not participate in the overload resolution -unless Y*shall beis implicitly convertible -to T*. --In 20.6.6.3.1 [util.smartptr.weak.const], change: -
- --- - - --template<class Y> weak_ptr(shared_ptr<Y> const& r);-weak_ptr(weak_ptr const& r);-template<class Y> weak_ptr(weak_ptr<Y> const& r);-weak_ptr(weak_ptr const& r); -template<class Y> weak_ptr(weak_ptr<Y> const& r); -template<class Y> weak_ptr(shared_ptr<Y> const& r); ----4- Requires:
FortThe second and -third constructors,shall not participate in the -overload resolution unless Y*shall be-is implicitly convertible to T*. -
688. reference_wrapper, cref unsafe, allow binding to rvalues
-Section: 20.5.5.1 [refwrap.const] Status: Ready +
Section: 20.5.5.1 [refwrap.const] Status: Open Submitter: Peter Dimov Date: 2007-05-10
-View other active issues in [refwrap.const].
View all other issues in [refwrap.const].
-View all issues with Ready status.
+View all issues with Open status.
Discussion:
A reference_wrapper can be constructed from an rvalue, either by using @@ -11076,60 +9643,13 @@ Also please see the thread starting at c++std-lib-17398 for some good discussion
Proposed resolution:
-In 20.5.5 [refwrap], add: +In 20.5 [function.objects], add the following two signatures to the synopsis:
-private: - explicit reference_wrapper(T&&); +-template <class T> void ref(const T&& t) = delete; +template <class T> void cref(const T&& t) = delete;-In 20.5.5.1 [refwrap.const], add: -
- --- -explicit reference_wrapper(T&&); -----?- Not defined to disallow creating a reference_wrapper from an rvalue. -
-In the synopsis of <functional> (20.5.5 [refwrap]), change the declarations -of ref and cref to: -
- -- -template<class T> reference_wrapper<T> ref(T&&); -template<class T> reference_wrapper<const T> cref(constT&&); --In 20.5.5.5 [refwrap.helpers], change: -
- --- -template<class T> reference_wrapper<T> ref(T&& t); ------1- Requires: t shall be an lvalue. -
-and change:
- ---template<class T> reference_wrapper<const T> cref(-constT&& t); -----6- Requires: t shall be an lvalue. -
-[ @@ -11138,35 +9658,20 @@ addresses the first part of the resolution but not the second. ]
+[ +Bellevue: Doug noticed problems with the current wording. +]
- -
-689. reference_wrapper constructor overly constrained
-Section: 20.5.5.1 [refwrap.const] Status: Ready - Submitter: Peter Dimov Date: 2007-05-10
-View other active issues in [refwrap.const].
-View all other issues in [refwrap.const].
-View all issues with Ready status.
-Discussion:
--The constructor of reference_wrapper is currently explicit. The primary -motivation behind this is the safety problem with respect to rvalues, -which is addressed by the proposed resolution of the previous issue. -Therefore we should consider relaxing the requirements on the -constructor since requests for the implicit conversion keep resurfacing. -
--Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. -
+[ +post Bellevue: Howard and Peter provided revised wording. +]
-Proposed resolution:
--Remove the explicit from the constructor of reference_wrapper. If the -proposed resolution of the previous issue is accepted, remove the -explicit from the T&& constructor as well to keep them in sync. -
+[ +This resolution depends on a "favorable" resolution of CWG 606: that is, +the "special deduction rule" is disabled with the const T&& pattern. +]
@@ -11260,9 +9765,10 @@ const_local_iterator cend(size_type n) const;
-692.
+get_money
andput_money
should be formatted I/O functions692.
get_money
andput_money
should be formatted I/O functionsSection: 27.6.4 [ext.manip] Status: New Submitter: Martin Sebor Date: 2007-06-22
+View other active issues in [ext.manip].
View all other issues in [ext.manip].
View all issues with New status.
Discussion:
@@ -11270,15 +9776,15 @@ const_local_iterator cend(size_type n) const; In a private email Bill Plauger notes:-I believe that the function that implements
get_money
+I believe that the function that implementsget_money
[from N2072] -should behave as a formatted input function, and the function that -implementsput_money
should behave as a formatted output -function. This has implications regarding the skipping of whitespace +should behave as a formatted input function, and the function that +implementsput_money
should behave as a formatted output +function. This has implications regarding the skipping of whitespace and the handling of errors, among other things.-The words don't say that right now and I'm far from convinced that +The words don't say that right now and I'm far from convinced that such a change is editorial.
@@ -11291,19 +9797,19 @@ formatted I/O functions do. The text in N2072 assumes so but the of brevity. The spec should be clarified to that effect.
-As for dealing with whitespace, I also agree it would make sense for -the extractors and inserters involving the new manipulators to treat +As for dealing with whitespace, I also agree it would make sense for +the extractors and inserters involving the new manipulators to treat it the same way as formatted I/O.
Proposed resolution:
-Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the +Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the following text:
@@ -11312,253 +9818,25 @@ Also change p4 of 27.6.4 [ext.manip] as follows:-Effects: The expression
in >> get_money(mon, intl)
+Effects: The expressionin >> get_money(mon, intl)
described below behaves as a formatted input function (as described in 27.6.1.2.1 [istream.formatted.reqmts]).+Returns: An object
s
of unspecified type such that -ifin
is an object of typebasic_istream<charT, -traits>
then the expressionin >> get_money(mon, intl)
behaves as a formatted input function -that callsf(in, mon, intl)
were +ifin
is an object of typebasic_istream<charT, +traits>
then the expressionin >> get_money(mon, intl)
behaves as a formatted input function +that callsf(in, mon, intl)
were called. The functionf
can be defined as...[ +post Bellevue: +]
- -
-693.
-std::bitset::all()
missingSection: 23.3.5 [template.bitset] Status: Ready - Submitter: Martin Sebor Date: 2007-06-22
-View other active issues in [template.bitset].
-View all other issues in [template.bitset].
-View all issues with Ready status.
-Discussion:
--The
- - -bitset
class template provides the member function -any()
to determine whether an object of the type has any -bits set, and the member functionnone()
to determine -whether all of an object's bits are clear. However, the template does -not provide a corresponding function to discover whether a -bitset
object has all its bits set. While it is -possible, even easy, to obtain this information by comparing the -result ofcount()
with the result ofsize()
-for equality (i.e., viab.count() == b.size()
) the -operation is less efficient than a member function designed -specifically for that purpose could be. (count()
must -count all non-zero bits in abitset
a word at a time -whileall()
could stop counting as soon as it encountered -the first word with a zero bit). -Proposed resolution:
--Add a declaration of the new member function
- -all()
to the -defintion of thebitset
template in 23.3.5 [template.bitset], p1, -right above the declaration ofany()
as shown below: -- -bool operator!=(const bitset<N>& rhs) const; -bool test(size_t pos) const; -bool all() const; -bool any() const; -bool none() const; --Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text: -
-- --
bool all() const;
--Returns:-count() == size()
. +We recommend moving immediately to Review. We've looked at the issue and +have a consensus that the proposed resolution is correct, but want an +iostream expert to sign off. Alisdair has taken the action item to putt +this up on the reflector for possible movement by Howard to Tenatively +Ready.-In addition, change the description of
-any()
and -none()
for consistency withall()
as -follows: -- - - - - --
-bool any() const;
----Returns:
-true
if any bit in*this
-is onecount() != 0
. --
-bool none() const;
----Returns:
-true
if no bit in*this
-is onecount() == 0
. -
-694.
-std::bitset
andlong long
Section: 23.3.5 [template.bitset] Status: Ready - Submitter: Martin Sebor Date: 2007-06-22
-View other active issues in [template.bitset].
-View all other issues in [template.bitset].
-View all issues with Ready status.
-Discussion:
--Objects of the
- - -bitset
class template specializations can -be constructed from and explicitly converted to values of the widest -C++ integer type,unsigned long
. With the introduction -oflong long
into the language the template should be -enhanced to make it possible to interoperate with values of this type -as well, or perhapsuintmax_t
. See c++std-lib-18274 for -a brief discussion in support of this change. -Proposed resolution:
--For simplicity, instead of adding overloads for
-unsigned long -long
and dealing with possible ambiguities in the spec, replace -thebitset
ctor that takes anunsigned long
-argument with one takingunsigned long long
in the -definition of the template as shown below. (The standard permits -implementations to add overloads on other integer types or employ -template tricks to achieve the same effect provided they don't cause -ambiguities or changes in behavior.) ---// [bitset.cons] constructors: -bitset(); -bitset(unsigned long long val); -template<class charT, class traits, class Allocator> -explicit bitset( - const basic_string<charT,traits,Allocator>& str, - typename basic_string<charT,traits,Allocator>::size_type pos = 0, - typename basic_string<charT,traits,Allocator>::size_type n = - basic_string<charT,traits,Allocator>::npos); ---Make a corresponding change in 23.3.5.1 [bitset.cons], p2: -
--- --
-bitset(unsigned long long val);
--Effects: Constructs an object of class bitset<N>, -initializing the first-M
bit positions to the -corresponding bit values inval
. -M
is the smaller ofN
and the -number of bits in the value representation (section [basic.types]) of -unsigned long long
. IfM < -N
istrue
, the remaining bit -positions are initialized to zero. --Additionally, introduce a new member function
-to_ullong()
-to make it possible to convertbitset
to values of the -new type. Add the following declaration to the definition of the -template, immediate after the declaration ofto_ulong()
-in 23.3.5 [template.bitset], p1, as shown below: ---// element access: -bool operator[](size_t pos) const; // for b[i]; -reference operator[](size_t pos); // for b[i]; -unsigned long to_ulong() const; -unsigned long long to_ullong() const; -template <class charT, class traits, class Allocator> -basic_string<charT, traits, Allocator> to_string() const; ---And add a description of the new member function to 23.3.5.2 [bitset.members], -below the description of the existing
-to_ulong()
(if -possible), with the following text: --- - - - - --
-unsigned long long to_ullong() const;
--Throws:-overflow_error
if the integral value -x
corresponding to the bits in*this
-cannot be represented as typeunsigned long long
. --Returns:-x
. -
-695. ctype<char>::classic_table() not accessible
-Section: 22.2.1.3 [facet.ctype.special] Status: Ready - Submitter: Martin Sebor Date: 2007-06-22
-View all issues with Ready status.
-Discussion:
--The
-ctype<char>::classic_table()
static member -function returns a pointer to an array of const -ctype_base::mask
objects (enums) that contains -ctype<char>::table_size
elements. The table -describes the properties of the character set in the "C" locale (i.e., -whether a character at an index given by its value is alpha, digit, -punct, etc.), and is typically used to initialize the -ctype<char>
facet in the classic "C" locale (the -protectedctype<char>
member function -table()
then returns the same value as -classic_table()
). --However, while
-ctype<char>::table_size
(the size of -the table) is a public static const member of the -ctype<char>
specialization, the -classic_table()
static member function is protected. That -makes getting at the classic data less than convenient (i.e., one has -to create a whole derived class just to get at the masks array). It -makes little sense to expose the size of the table in the public -interface while making the table itself protected, especially when the -table is a constant object. --The same argument can be made for the non-static protected member -function
- - -table()
. -Proposed resolution:
--Make the
-ctype<char>::classic_table()
and -ctype<char>::table()
member functions public by -moving their declarations into the public section of the definition of -specialization in 22.2.1.3 [facet.ctype.special] as shown below: --- @@ -11567,7 +9845,6 @@ virtual char do_toupper(char c) const;static locale::id id; - static const size_t table_size = IMPLEMENTATION_DEFINED; --protected:- const mask* table() const throw(); - static const mask* classic_table() throw(); -protected: - -~ctype(); // virtual -virtual char do_toupper(char c) const; -696.
istream::operator>>(int&)
brokenSection: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New Submitter: Martin Sebor Date: 2007-06-23
-View other active issues in [istream.formatted.arithmetic].
View all other issues in [istream.formatted.arithmetic].
View all issues with New status.
Discussion:
@@ -11613,66 +9890,6 @@ prevent the facet from storing the value. -
-697. New <system_error> header leads to name clashes
-Section: 19.4 [syserr] Status: New - Submitter: Daniel Krügler Date: 2007-06-24
-View all issues with New 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:
--
- - - - - -
698. Some system_error issues
Section: 19.4.5.1 [syserr.syserr.overview] Status: New @@ -11705,50 +9922,6 @@ accepting a const char*. -
-700. N1856 defines struct identity
-Section: 20.2.2 [forward] Status: Ready - Submitter: P.J. Plauger Date: 2007-07-01
-View all issues with Ready status.
-Discussion:
--N1856 -defines struct identity in <utility> which clashes with -the traditional definition of struct identity in <functional> -(not standard, but a common extension from old STL). Be nice -if we could avoid this name clash for backward compatibility. -
- - -Proposed resolution:
--Change 20.2.2 [forward]: -
- --- - - - - -template <class T> struct identity -{ - typedef T type; - const T& operator()(const T& x) const; -}; ---- -const T& operator()(const T& x) const; -----Returns: x. -
-
701. assoc laguerre poly's
Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New @@ -11761,11 +9934,11 @@ polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since N1687. However, the draft standard only specifies ranks of integer value m, while the associated Laguerre polynomials are actually valid for real -values of m > -1. In the case of non-integer values of m, the -definition Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n) -must be used, which also holds for integer values of m. See +values of m > -1. In the case of non-integer values of m, the +definition Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n) +must be used, which also holds for integer values of m. See Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for -the integer case. In fact fractional values are most commonly used in +the integer case. In fact fractional values are most commonly used in physics, for example to m = +/- 1/2 to describe the harmonic oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3 dimensions. @@ -11773,7 +9946,7 @@ dimensions.
If I am correct, the calculation of the more general case is no more difficult, and is in fact the function implemented in the GNU -Scientific Library. I would urge you to consider upgrading the +Scientific Library. I would urge you to consider upgrading the standard, either adding extra functions for real m or switching the current ones to double.
@@ -11794,7 +9967,7 @@ current ones to double.View all issues with New status.
Discussion:
-One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be +One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be |x| <= 1, not x >= 0.
@@ -11806,32 +9979,6 @@ One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should&nb -
-703. map::at() need a complexity specification
-Section: 23.3.1.2 [map.access] Status: Ready - Submitter: Joe Gottman Date: 2007-07-03
-View all other issues in [map.access].
-View all issues with Ready status.
-Discussion:
--map::at() need a complexity specification. -
- - -Proposed resolution:
--Add the following to the specification of map::at(), 23.3.1.2 [map.access]: -
--- - - - --Complexity: logarithmic. -
-
704. MoveAssignable requirement for container value type overly strict
Section: 23.1 [container.requirements] Status: Open @@ -11970,6 +10117,11 @@ Kona (2007): Howard and Alan to update requirements table in issue with emplace ]
+[ +Bellevue: This should be handled as part of the concepts work. +]
+ +Proposed resolution:
@@ -11979,144 +10131,6 @@ Kona (2007): Howard and Alan to update requirements table in issue with emplace -
-705. type-trait decay incompletely specified
-Section: 20.4.7 [meta.trans.other] Status: Ready - Submitter: Thorsten Ottosen Date: 2007-07-08
-View all issues with Ready status.
-Discussion:
--The current working draft has a type-trait decay in 20.4.7 [meta.trans.other]. -
- --Its use is to turn C++03 pass-by-value parameters into efficient C++0x -pass-by-rvalue-reference parameters. However, the current definition -introduces an incompatible change where the cv-qualification of the -parameter type is retained. The deduced type should loose such -cv-qualification, as pass-by-value does. -
- - -Proposed resolution:
--In 20.4.7 [meta.trans.other] change the last sentence: -
- -- --Otherwise the member typedef type equals remove_cv<U>::type. -
-In 20.3.1.2 [tuple.creation]/1 change: -
- -- - - - - - --
where each Vi in VTypes is X& if, for the -corresponding type Ti in Types, -remove_cv<remove_reference<Ti>::type>::type equals -reference_wrapper<X>, otherwise Vi is -decay<Ti>::type.-Let Ui be decay<Ti>::type for each -Ti in Types. Then each Vi in VTypes -is X& if Ui equals -reference_wrapper<X>, otherwise Vi is -Ui. -
-706. make_pair() should behave as make_tuple() wrt. reference_wrapper()
-Section: 20.2.3 [pairs] Status: Ready - Submitter: Thorsten Ottosen Date: 2007-07-08
-View all other issues in [pairs].
-View all issues with Ready status.
-Discussion:
--The current draft has make_pair() in 20.2.3 [pairs]/16 -and make_tuple() in 20.3.1.2 [tuple.creation]. -make_tuple() detects the presence of -reference_wrapper<X> arguments and "unwraps" the reference in -such cases. make_pair() would OTOH create a -reference_wrapper<X> member. I suggest that the two -functions are made to behave similar in this respect to minimize -confusion. -
- - -Proposed resolution:
--In 20.2 [utility] change the synopsis for make_pair() to read -
- -- -template <class T1, class T2> - pair<typename decay<T1>::typeV1,typename decay<T2>::typeV2> make_pair(T1&&, T2&&); --In 20.2.3 [pairs]/16 change the declaration to match the above synopsis. -Then change the 20.2.3 [pairs]/17 to: -
- --- - - - - - --Returns: pair<
-typename decay<T1>::typeV1,typename decay<T2>::typeV2>(forward<T1>(x),forward<T2>(y)) where V1 and -V2 are determined as follows: Let Ui be -decay<Ti>::type for each Ti. Then each -Vi is X& if Ui equals -reference_wrapper<X>, otherwise Vi is -Ui. -
-707. null pointer constant for exception_ptr
-Section: 18.7.1 [exception] Status: Open - Submitter: Jens Maurer Date: 2007-07-20
-View all issues with Open 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. -
- - - -Proposed resolution:
--
- - - - -
708. Locales need to be per thread and updated for POSIX changes
Section: 22 [localization] Status: Open @@ -12167,60 +10181,13 @@ Kona (2007): Bill and Nick to provide wording. -
-709. char_traits::not_eof has wrong signature
-Section: 21.1.3 [char.traits.specializations] Status: New - Submitter: Bo Persson Date: 2007-08-13
-View all issues with New status.
-Discussion:
--The changes made for constexpr in 21.1.3 [char.traits.specializations] have -not only changed the not_eof function from pass by const reference to -pass by value, it has also changed the parameter type from int_type to -char_type. -
--This doesn't work for type char, and is inconsistent with the -requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require]. -
- --Pete adds: -
- -- - - --For what it's worth, that may not have been an intentional change. -N2349, which detailed the changes for adding constant expressions to -the library, has strikeout bars through the const and the & that -surround the char_type argument, but none through char_type itself. -So the intention may have been just to change to pass by value, with -text incorrectly copied from the standard. -
Proposed resolution:
--Change the signature in 21.1.3.1 [char.traits.specializations.char], -21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t], -and 21.1.3.4 [char.traits.specializations.wchar.t] to -
- -- - - - - -static constexpr int_type not_eof(char_typeint_type c); -
710. Missing postconditions
-Section: 20.6.6.2 [util.smartptr.shared] Status: New +
Section: 20.6.12.2 [util.smartptr.shared] Status: Ready Submitter: Peter Dimov Date: 2007-08-24
View other active issues in [util.smartptr.shared].
View all other issues in [util.smartptr.shared].
-View all issues with New status.
+View all issues with Ready status.
Discussion:
A discussion on @@ -12230,10 +10197,27 @@ The shared_ptr move constructor and the cast functions are missing postconditions for the get() accessor.
+[ +Bellevue: +]
+ + ++++Move to "ready", adopting the first (Peter's) proposed resolution. +
++Note to the project editor: there is an editorial issue here. The +wording for the postconditions of the casts is slightly awkward, and the +editor should consider rewording "If w is the return value...", e. g. as +"For a return value w...". +
+Proposed resolution:
-Add to 20.6.6.2.1 [util.smartptr.shared.const]: +Add to 20.6.12.2.1 [util.smartptr.shared.const]:
@@ -12249,7 +10233,7 @@ shall be empty. r.get() == 0.-Add to 20.6.6.2.10 [util.smartptr.shared.cast]: +Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
@@ -12292,7 +10276,7 @@ the aliasing constructor as follows:-Change 20.6.6.2.10 [util.smartptr.shared.cast]: +Change 20.6.12.2.10 [util.smartptr.shared.cast]:
@@ -12339,10 +10323,10 @@ in the aliasing constructor postcondition "by reference".+
711. Contradiction in empty shared_ptr
-Section: 20.6.6.2.5 [util.smartptr.shared.obs] Status: New +
Section: 20.6.12.2.5 [util.smartptr.shared.obs] Status: Review Submitter: Peter Dimov Date: 2007-08-24
View all other issues in [util.smartptr.shared.obs].
-View all issues with New status.
+View all issues with Review status.
Discussion:
A discussion on @@ -12371,7 +10355,7 @@ with a non-NULL stored pointer.
-This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]: +This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
@@ -12382,11 +10366,34 @@ This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5[ +Bellevue: +]
+ + +++Adopt option 1 and move to review, not ready. +
++There was a lot of confusion about what an empty shared_ptr is (the term +isn't defined anywhere), and whether we have a good mental model for how +one behaves. We think it might be possible to deduce what the definition +should be, but the words just aren't there. We need to open an issue on +the use of this undefined term. (The resolution of that issue might +affect the resolution of issue 711.) +
++The LWG is getting more uncomfortable with the aliasing proposal (N2351) +now that we realize some of its implications, and we need to keep an eye +on it, but there isn't support for removing this feature at this time. +
+Proposed resolution:
-In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]: +In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
@@ -12402,7 +10409,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi-Change 20.6.6.2.1 [util.smartptr.shared.const]: +Change 20.6.12.2.1 [util.smartptr.shared.const]:
@@ -12517,10 +10524,11 @@ template<class ForwardIterator, class Size, class T,
715. minmax_element complexity is too lax
-Section: 25.3.7 [alg.min.max] Status: New +
Section: 25.3.7 [alg.min.max] Status: Ready Submitter: Matt Austern Date: 2007-08-30
+View other active issues in [alg.min.max].
View all other issues in [alg.min.max].
-View all issues with New status.
+View all issues with Ready status.
Discussion:
The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 * @@ -12549,12 +10557,11 @@ template<class ForwardIterator, class Compare>
Returns: make_pair(m, M), where m is
min_element(first, last) or min_element(first, last, -comp)the first iterator i in [first, -last) such that no other element in the range is smaller, and +comp) the first iterator in [first, +last) such that no iterator in the range refers to a smaller element, and where M ismax_element(first, last) or max_element(first, last, comp)the last iterator -i in [first, last) such that no other element in the -range is larger. +in [first, last) such that no iterator in the range refers to a larger element.Complexity: At most
max(2 * (last - first ) - 2, 0)@@ -12615,73 +10622,13 @@ Remove this mention of the CharacterClass production. -
-717. Incomplete valarray::operator[] specification in [valarray.access]
-Section: 26.5.2.3 [valarray.access] Status: New - Submitter: Daniel Krügler Date: 2007-08-27
-View all other issues in [valarray.access].
-View all issues with New 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. -
718. basic_string is not a sequence
-Section: 21.3 [basic.string] Status: New +
Section: 21.3 [basic.string] Status: Open Submitter: Bo Persson Date: 2007-08-18
View other active issues in [basic.string].
View all other issues in [basic.string].
-View all issues with New status.
+View all issues with Open status.
Discussion:
Paragraph 21.3 [basic.string]/3 states: @@ -12701,6 +10648,33 @@ Secondly, after the resent changes to containers (emplace, push_bac even close to conform to the current requirements.
+[ +Bellevue: +]
+ + +++ ++
+- emplace, for example, may not make sense for strings. Is also likely suboptimal
+- with concepts do we need to maintain string as sequence container?
+- One approach might be to say something like: string is a sequence except it doesn't have these functions
++
+General consensus is to suggest option 2. +- basic_string already has push_back
+- const_iterator parameters to insert and erase should be added to basic_string
+- this leaves emplace to handle -- we have the following options: +
++
+- option 1: add it to string even though it's optional
+- option 2: make emplace optional to sequences (move from table 89 to 90)
+- option 3: say string not sequence (the proposal),
+- option 4: add an exception to basic string wording.
+Proposed resolution:
@@ -12715,10 +10689,10 @@ different, a string abstraction in its own right.
719. std::is_literal type traits should be provided
-Section: 20.4 [meta] Status: New +
Section: 20.4 [meta] Status: Open Submitter: Daniel Krügler Date: 2007-08-25
View all other issues in [meta].
-View all issues with New status.
+View all issues with Open status.
Discussion:
Since the inclusion of constexpr in the standard draft N2369 we have @@ -12796,6 +10770,14 @@ reference type (instead of const T& we could decide to use T&&, but that is another issue).
+[ +Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits. +]
+ +Proposed resolution:
@@ -12839,11 +10821,11 @@ array of unknown bound, or
720. Omissions in constexpr usages
-Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: New +
Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Open Submitter: Daniel Krügler Date: 2007-08-25
View other active issues in [array].
View all other issues in [array].
-View all issues with New status.
+View all issues with Open status.
Discussion:
- @@ -12936,11 +10918,11 @@ void main()
722. Missing [c.math] functions nanf and nanl
-Section: 26.7 [c.math] Status: New +
Section: 26.7 [c.math] Status: Ready Submitter: Daniel Krügler Date: 2007-08-27
View other active issues in [c.math].
View all other issues in [c.math].
-View all issues with New status.
+View all issues with Ready status.
Discussion:
In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss @@ -13080,11 +11062,11 @@ to describe these additions.
724. DefaultConstructible is not defined
-Section: 20.1.1 [utility.arg.requirements] Status: New +
Section: 20.1.1 [utility.arg.requirements] Status: Open Submitter: Pablo Halpern Date: 2007-09-12
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
-View all issues with New status.
+View all issues with Open status.
Discussion:
The DefaultConstructible requirement is referenced in @@ -13093,6 +11075,43 @@ several places in the August 2007 working draft but is not defined anywhere.
+[ +Bellevue: +]
+ + ++++Walking into the default/value-initialization mess... +
++Why two lines? Because we need both expressions to be valid. +
++AJM not sure what the phrase "default constructed" means. This is +unfortunate, as the phrase is already used 24 times in the library! +
++Example: const int would not accept first line, but will accept the second. +
++This is an issue that must be solved by concepts, but we might need to solve it independantly first. +
++It seems that the requirements are the syntax in the proposed first +column is valid, but not clear what semantics we need. +
++A table where there is no post-condition seems odd, but appears to sum up our position best. +
++At a minimum an object is declared and is destuctible. +
++Move to open, as no-one happy to produce wording on the fly. +
+Proposed resolution:
@@ -13133,42 +11152,6 @@ following table: -
-725. Optional sequence container requirements column label
-Section: 23.1.1 [sequence.reqmts] Status: New - Submitter: David Abrahams Date: 2007-09-16
-View all other issues in [sequence.reqmts].
-View all issues with New 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 -
726. Missing regex_replace() overloads
Section: 28.11.4 [re.alg.replace] Status: New @@ -13190,7 +11173,7 @@ Two overloads of regex_replace() are currently provided: const basic_string<charT>& fmt, regex_constants::match_flag_type flags = regex_constants::match_default); - + template <class traits, class charT> basic_string<charT> regex_replace(const basic_string<charT>& s, @@ -13202,7 +11185,7 @@ template <class traits, class charT>
- Overloads taking const charT * are provided for regex_match() and -regex_search(), but not regex_replace(). This is inconsistent.
+regex_search(), but not regex_replace(). This is inconsistent.- @@ -13240,7 +11223,7 @@ a basic_string from each C string is the simplest workaround.
The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:
@@ -13219,9 +11202,9 @@ char[1]'".Users expect that anything taking a basic_string<charT> can also take a -const charT *. In their own code, when they write a function taking +const charT *. In their own code, when they write a function taking std::string (or std::wstring), they can pass a const char * (or const -wchar_t *), thanks to basic_string's implicit constructor. Because the +wchar_t *), thanks to basic_string's implicit constructor. Because the regex algorithms are templated on charT, they can't rely on basic_string's implicit constructor (as the compiler error message indicates, template argument deduction fails first). @@ -13229,10 +11212,10 @@ indicates, template argument deduction fails first).
If a user figures out what the compiler error message means, workarounds -are available - but they are all verbose. Explicit template arguments +are available - but they are all verbose. Explicit template arguments could be given to regex_replace(), allowing basic_string's implicit constructor to be invoked - but charT is the last template argument, not -the first, so this would be extremely verbose. Therefore, constructing +the first, so this would be extremely verbose. Therefore, constructing a basic_string from each C string is the simplest workaround.
- There is an efficiency consideration: constructing basic_strings can impose performance costs that could be avoided by a library -implementation taking C strings and dealing with them directly. +implementation taking C strings and dealing with them directly. (Currently, for replacement sources, C strings can be converted into iterator pairs at the cost of verbosity, but for format strings, there is no way to avoid constructing a basic_string.) @@ -13329,7 +11312,7 @@ charT* str and const charT* fmt). 28.11.4 [re.alg.replace]:
Discussion:
regex_match() and regex_search() take const basic_string<charT, ST, -SA>&. regex_replace() takes const basic_string<charT>&. This prevents +SA>&. regex_replace() takes const basic_string<charT>&. This prevents regex_replace() from accepting basic_strings with custom traits and allocators.
@@ -13339,7 +11322,7 @@ allocators.Overloads of regex_replace() taking basic_string should be additionally templated on class ST, class SA and take const basic_string<charT, ST, -SA>&. Consistency with regex_match() and regex_search() would place +SA>&. Consistency with regex_match() and regex_search() would place class ST, class SA as the first template arguments; compatibility with existing code using TR1 and giving explicit template arguments to regex_replace() would place class ST, class SA as the last template @@ -13352,9 +11335,10 @@ arguments.
728. Problem in [rand.eng.mers]/6
-Section: 26.4.3.2 [rand.eng.mers] Status: New +
Section: 26.4.3.2 [rand.eng.mers] Status: Review Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New status.
+View all other issues in [rand.eng.mers].
+View all issues with Review status.
Discussion:
The mersenne_twister_engine is required to use a seeding method that is given @@ -13379,184 +11363,66 @@ order) and always employ the 32-bit algorithm for seeding
-See N2423 +See N2424 for further discussion.
+[ +Bellevue: +]
+ + +++ ++Stephan Tolksdorf has additional comments on N2424. He comments: "there +is a typo in the required behaviour for mt19937_64: It should be the +10000th (not 100000th) invocation whose value is given, and the value +should be 9981545732273789042 (not 14002232017267485025)." These values +need checking. +
++Take the proposed recommendation in N2424 and move to REVIEW. +
+Proposed resolution:
-See N2423 +See N2424 for the proposed resolution.
+[ +Stephan Tolksdorf adds pre-Bellevue: +]
++I support the proposed resolution in +N2424, +but there is a typo in the +required behaviour for mt19937_64: It should be the 10000th (not +100000th) invocation whose value is given, and the value should be +9981545732273789042 (not 14002232017267485025). The change to para. 8 +proposed by Charles Karney should also be included in the proposed +wording. +-
-729. Problem in [rand.req.eng]/3
-Section: 26.4.1.3 [rand.req.eng] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all other issues in [rand.req.eng].
-View all issues with New 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 N2423 -for further discussion. -
- - - -Proposed resolution:
--See N2423 -for further discussion. -
- - - - - - -
-730. Comment on [rand.req.adapt]/3 e)
-Section: 26.4.1.4 [rand.req.adapt] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New 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 N2423 -for further discussion. -
- - - -Proposed resolution:
--See N2423 -for the proposed resolution. -
- - - - - -
-731. proposal for a customizable seed_seq
-Section: 26.4.7.1 [rand.util.seedseq] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all other issues in [rand.util.seedseq].
-View all issues with New 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: -
- --
- - -- -Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the -exact behaviour of the constructors and the randomize method are left unspecified and where the -const qualification for randomize is removed. Classes implementing this interface are additionally -required to specialize the traits class in c). -
-- -Provide the class seed_seq as a default implementation of the SeedSeq interface. -
-- -
--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.
-- -Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and -modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation -could be done using the SFINAE technique). -
-Proposed resolution:
--See N2423 -for the proposed resolution. -
- -
732. Defect in [rand.dist.samp.genpdf]
-Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: New +
Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Open Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New status.
+View all other issues in [rand.dist.samp.genpdf].
+View all issues with Open status.
+Duplicate of: 795
Discussion:
26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is @@ -13574,41 +11440,46 @@ nightmare. Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+[ +Bellevue: +]
-Proposed resolution:
+ ++-See N2423 -for the proposed resolution. +Disagreement persists.
- - - - - -
-733. Comment on [rand.req.dist]/9
-Section: 26.4.1.5 [rand.req.dist] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New 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.] +Objection to this issue is that this function takes a general functor. +The general approach would be to normalize this function, integrate it, +and take the inverse of the integral, which is not possible in general. +An example function is sin(1+n*x) -- for any spatial frequency that the +implementor chooses, there is a value of n that renders that choice +arbitrarily erroneous.
--Proposed resolution: I propose to drop this requirement. +Correction: The formula above should instead read 1+sin(n*x).
++Objector proposes the following possible compromise positions: +
++
+- +rand.dist.samp.genpdf takes an number of points so that implementor need not guess. +
+- replace rand.disk.samp.genpdf with an extension to either or both +of the discrete functions to take arguments that take a functor and +number of points in place of the list of probabilities. Reference +issues 793 and 794. +
+Proposed resolution:
-See N2423 +See N2424 for the proposed resolution.
@@ -13618,9 +11489,9 @@ for the proposed resolution.
734. Unnecessary restriction in [rand.dist.norm.chisq]
-Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: New +
Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Open Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New status.
+View all issues with Open status.
Discussion:
chi_squared_distribution, fisher_f_distribution and student_t_distribution @@ -13647,197 +11518,107 @@ log-factorial function). to double.
- -Proposed resolution:
--See N2423 -for the proposed resolution. -
+[ +Bellevue: +]
- - - -
-735. Unfortunate naming
-Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New 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. -
++In N2424. Not wildly enthusiastic, not really felt necessary. Less +frequently used in practice. Not terribly bad either. Move to OPEN. +Proposed resolution:
-See N2423 +See N2424 for the proposed resolution.
+[ +Stephan Tolksdorf adds pre-Bellevue: +]
- - -
-736. Comment on [rand.dist.samp.discrete]
-Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New status.
-Discussion:
--
- +- -The specification for discrete_distribution requires the member probabilities() -to return a vector of standardized probabilities, which forces the implementation every time to -divide each probability by the sum of all probabilities, as the sum will in practice almost never be -exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to -compute the standardized probabilities at all and could instead work with the non-standardized -probabilities and the sum. If there was no standardization the user would just get back the -probabilities that were previously supplied to the distribution object, which to me seems to be the -more obvious solution. -
-- -The behaviour of discrete_distribution is not specified in case the number of given -probabilities is larger than the maximum number representable by the IntType. -
-+-Possible resolution: I propose to change the specification such that the non-standardized -probabilities need to be returned and that an additional requirement is included for the number -of probabilities to be smaller than the maximum of IntType. +In 26.4.8.4.3 [rand.dist.norm.chisq]:
- -Proposed resolution:
+- - --See N2423 -for the proposed resolution. +Delete ", where n is a positive integer" in the first paragraph.
- - - - -
-737. Comment on [rand.dist.samp.pconst]
-Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New status.
-Discussion:
--
+- -The discussion in point T11 above regarding probabilities() similarly applies -to the method densities() of piecewise_constant_distribution. -
-- -
-The design of the constructor +Replace both occurrences of "explicit chi_squared_distribution(int n = 1);" +with "explicit chi_squared_distribution(RealType n = 1);".
-+ +template <class InputIteratorB, class InputIteratorW> -piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, - InputIteratorW firstW); + ++Replace both occurrences of "int n() const;" with "RealType n() const;". +
+ ++In 26.4.8.4.5 [rand.dist.norm.f]: +
+++Delete ", where m and n are positive integers" in the first paragraph. +
+ ++Replace both occurrences of +
+explicit fisher_f_distribution(int m = 1, int n = 1);-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. +with
-explicit fisher_f_distribution(RealType m = 1, RealType n = 1); +-Possible resolution: I propose to add an InputIteratorW lastW argument to the interface. -
- - -Proposed resolution:
--See N2423 -for the proposed resolution. -
- - - - - -
-738. Editorial issue in [rand.adapt.disc]/3
-Section: 26.4.4.1 [rand.adapt.disc] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all issues with New 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 N2423 -for the proposed resolution. -
- - - - - -
-739. Defect in [rand.util.canonical]/3
-Section: 26.4.7.2 [rand.util.canonical] Status: New - Submitter: Stephan Tolksdorf Date: 2007-09-21
-View all other issues in [rand.util.canonical].
-View all issues with New 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)). +Replace both occurrences of "int m() const;" with "RealType m() const;".
-See N2423 -for further discussion. +Replace both occurrences of "int n() const;" with "RealType n() const;".
+Proposed resolution:
-See N2423 -for the proposed resolution. +In 26.4.8.4.6 [rand.dist.norm.t]:
+++ ++Delete ", where n is a positive integer" in the first paragraph. +
+ ++Replace both occurrences of "explicit student_t_distribution(int n = 1);" +with "explicit student_t_distribution(RealType n = 1);". +
+ ++Replace both occurrences of "int n() const;" with "RealType n() const;". +
+
740. Please remove *_ptr<T[N]>
-Section: 20.6.5.4 [unique.ptr.compiletime] Status: New +
Section: 20.6.11.4 [unique.ptr.compiletime] Status: Ready Submitter: Herb Sutter Date: 2007-10-04
-View all issues with New status.
+View all issues with Ready status.
Discussion:
Please don't provide *_ptr<T[N]>. It doesn't enable any useful @@ -13874,10 +11655,34 @@ remove *_ptr<T[N]> which equally makes the smart pointer more lik std::array. :-)
+[ +Bellevue: +]
+ + +++ +Suggestion that fixed-size array instantiations are going to fail at +compile time anyway (if we remove specialization) due to pointer decay, +at least that appears to be result from available compilers. +
++So concerns about about requiring static_assert seem unfounded. +
+After a little more experimentation with compiler, it appears that +fixed size arrays would only work at all if we supply these explicit +specialization. So removing them appears less breaking than originally +thought. +
++straw poll unanimous move to Ready. +
+Proposed resolution:
-Change the synopsis under 20.6.5 [unique.ptr] p2: +Change the synopsis under 20.6.11 [unique.ptr] p2:
... @@ -13892,13 +11697,13 @@ template<class T, class D> class unique_ptr<T[], D>;-Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>. +Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>.
-Remove the entire section 20.6.5.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length -and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers], -20.6.5.4.3 [unique.ptr.compiletime.modifiers]. +Remove the entire section 20.6.11.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length +and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers], +20.6.11.4.3 [unique.ptr.compiletime.modifiers].
@@ -13906,109 +11711,13 @@ and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [uniqu -
-741. Const-incorrect get_deleter function for shared_ptr
-Section: 20.6.6.2.11 [util.smartptr.getdeleter] Status: New - Submitter: Daniel Krügler Date: 2007-09-27
-View all other issues in [util.smartptr.getdeleter].
-View all issues with New 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.6 [memory] and 20.6.6.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.5.15.2 [func.wrap.func] or in 20.5.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.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the -following alternatives (A) or (B): -
- --
- -- -Provide only the immutable variant. This would reflect the -current praxis of container::get_allocator(), map::key_comp(), or -map::value_comp. - -
--template<class D, class T> const D* get_deleter(shared_ptr<T> const& p); -- -Just remove the function. -
--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. -
-Proposed resolution:
--
- - - - -
742. Enabling swap for proxy iterators
-Section: 20.1.1 [utility.arg.requirements] Status: New +
Section: 20.1.1 [utility.arg.requirements] Status: Open Submitter: Howard Hinnant Date: 2007-10-10
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
-View all issues with New status.
+View all issues with Open status.
Discussion:
This issue was split from 672. 672 now just @@ -14071,6 +11780,37 @@ That is, no standard library code needs to change. We simply need to have a mor definition of Swappable.
+[ +Bellevue: +]
+ + ++++While we believe Concepts work will define a swappable concept, we +should still resolve this issue if possible to give guidance to the +Concepts work. +
++Would an ambiguous swap function in two namespaces found by ADL break +this wording? Suggest that the phrase "valid expression" means such a +pair of types would still not be swappable. +
++Motivation is proxy-iterators, but facility is considerably more +general. Are we happy going so far? +
++We think this wording is probably correct and probably an improvement on +what's there in the WP. On the other hand, what's already there in the +WP is awfully complicated. Why do we need the two bullet points? They're +too implementation-centric. They don't add anything to the semantics of +what swap() means, which is there in the post-condition. What's wrong +with saying that types are swappable if you can call swap() and it +satisfies the semantics of swapping? +
+Proposed resolution:
@@ -14132,12 +11872,12 @@ semantics described in this table.
743. rvalue swap for shared_ptr
-Section: 20.6.6.2.9 [util.smartptr.shared.spec] Status: New +
Section: 20.6.12.2.9 [util.smartptr.shared.spec] Status: Ready Submitter: Howard Hinnant Date: 2007-10-10
-View all issues with New status.
+View all issues with Ready status.
Discussion:
-When the LWG looked at 674 in Kona the following note was made: +When the LWG looked at 674 in Kona the following note was made:
@@ -14154,11 +11894,27 @@ I believe allowing rvalue shared_ptrs to swap is both appropriate, and consistent with how other library components are currently specified.
+[ +Bellevue: +]
+ + +++Concern that the three signatures for swap is needlessly complicated, +but this issue merely brings shared_ptr into equal complexity with the +rest of the library. Will open a new issue for concern about triplicate +signatures. +
++Adopt issue as written. +
+Proposed resolution:
-Change the synopsis in 20.6.6.2 [util.smartptr.shared]: +Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
void swap(shared_ptr&& r); @@ -14169,14 +11925,14 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>-Change 20.6.6.2.4 [util.smartptr.shared.mod]: +Change 20.6.12.2.4 [util.smartptr.shared.mod]:
void swap(shared_ptr&& r);-Change 20.6.6.2.9 [util.smartptr.shared.spec]: +Change 20.6.12.2.9 [util.smartptr.shared.spec]:
template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b); @@ -14190,15 +11946,15 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>
744. What is the lifetime of an exception pointed to by an exception_ptr?
-Section: 18.7.5 [propagation] Status: New +
Section: 18.7.5 [propagation] Status: Ready Submitter: Alisdair Meredith Date: 2007-10-10
View other active issues in [propagation].
View all other issues in [propagation].
-View all issues with New status.
+View all issues with Ready status.
Discussion:
Without some lifetime guarantee, it is hard to know how this type can be -used. Very specifically, I don't see how the current wording would +used. Very specifically, I don't see how the current wording would guarantee and exception_ptr caught at the end of one thread could be safely stored and rethrown in another thread - the original motivation for this API. @@ -14208,55 +11964,68 @@ API. explain?)
+[ +Bellevue: +]
-Proposed resolution:
+ +-
- - - - - -
-745. copy_exception API slices.
-Section: 18.7.5 [propagation] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10
-View other active issues in [propagation].
-View all other issues in [propagation].
-View all issues with New 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. +Agree the issue is real.
-(Peter Dimov suggests NAD) +Intent is lifetime is similar to a shared_ptr (and we might even want to +consider explicitly saying that it is a shared_ptr< unspecified type >).
++We expect that most implementations will use shared_ptr, and the +standard should be clear that the exception_ptr type is intended to be +something whose semantics are smart-pointer-like so that the user does +not need to worry about lifetime management. We still need someone to +draught those words - suggest emailing Peter Dimov. +
++Move to Open. +
+Proposed resolution:
+Change 18.7.5 [propagation]/7:
++-7- Returns: An exception_ptr object that refers to the currently +handled exception or a copy of the currently handled exception, or a +null exception_ptr object if no exception is being handled. +The referenced object remains valid at least as long as there is an +exception_ptr that refers to it. +If the function needs to allocate memory and the attempt +fails, it returns an exception_ptr object that refers to an instance of +bad_alloc. It is unspecified whether the return values of two successive +calls to current_exception refer to the same exception object. [Note: +that is, it is unspecified whether current_exception creates a new copy +each time it is called. --end note] ++
746. current_exception may fail with bad_alloc
-Section: 18.7.5 [propagation] Status: New +
Section: 18.7.5 [propagation] Status: Ready Submitter: Alisdair Meredith Date: 2007-10-10
View other active issues in [propagation].
View all other issues in [propagation].
-View all issues with New status.
+View all issues with Ready status.
Discussion:
I understand that the attempt to copy an exception may run out of memory, but I believe this is the only part of the standard that mandates failure with specifically bad_alloc, as opposed to allowing an -implementation-defined type derived from bad_alloc. For instance, the Core +implementation-defined type derived from bad_alloc. For instance, the Core language for a failed new expression is:
@@ -14274,29 +12043,60 @@ compatible-exception freedom paragraph in 17) I prefer the clause 17 approach myself, and maybe clean up any outstanding wording that could also rely on it. ++Although filed against a specific case, this issue is a problem throughout +the library. +
+ +[ +Bellevue: +]
+ + +++Is issue bigger than library? +
++No - Core are already very clear about their wording, which is inspiration for the issue. +
++While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue. +
++Accept the broad view and move to ready +
+Proposed resolution:
+Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
++A function may throw a type not listed in its Throws clause so long as it is +derived from a class named in the Throws clause, and would be caught by an +exception handler for the base type. ++
747. We have 3 separate type traits to identify classes supporting no-throw operations
-Section: 20.4.4.3 [meta.unary.prop] Status: New +
Section: 20.4.4.3 [meta.unary.prop] Status: Open Submitter: Alisdair Meredith Date: 2007-10-10
View other active issues in [meta.unary.prop].
View all other issues in [meta.unary.prop].
-View all issues with New status.
+View all issues with Open status.
Discussion:
We have 3 separate type traits to identify classes supporting no-throw operations, which are very useful when trying to provide exception safety -guarantees. However, I'm not entirely clear on what the current wording -requires of a conforming implementation. To quote from +guarantees. However, I'm not entirely clear on what the current wording +requires of a conforming implementation. To quote from has_nothrow_default_constructor:
@@ -14311,13 +12111,13 @@ E.g.
struct test{ - int x; - test() : x() {} + int x; + test() : x() {} };Should I expect a conforming compiler to - assert( has_nothrow_constructor<test>::value ) + assert( has_nothrow_constructor<test>::value )
Is this a QoI issue? @@ -14339,72 +12139,15 @@ but right now I don't know what to suggest putting in the footnote. Open if QoI should be allowed to detect further)
- -Proposed resolution:
--
+[ +Bellevue: +]
- - - -
-748. The is_abstract type trait is defined by reference to 10.4.
-Section: 20.4.4.3 [meta.unary.prop] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10
-View other active issues in [meta.unary.prop].
-View all other issues in [meta.unary.prop].
-View all issues with New 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:
--
- - - - - -
-749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
-Section: 20.4.4.3 [meta.unary.prop] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10
-View other active issues in [meta.unary.prop].
-View all other issues in [meta.unary.prop].
-View all issues with New status.
-Discussion:
--Unfortunately a class can have multiple copy constructors, and I believe to -be useful this trait should only return true is ALL copy constructors are -no-throw. -
--For instance: -
-@@ -14416,18 +12159,101 @@ For instance: +struct awkward { - awkward( const awkward & ) throw() {} - awkward( awkward & ) { throw "oops"; } }; -+This looks like a QoI issue. +In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. +Move to OPEN. Need to talk to Core about this.
+749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.
+Section: 20.4.4.3 [meta.unary.prop] Status: Ready + Submitter: Alisdair Meredith Date: 2007-10-10
+View other active issues in [meta.unary.prop].
+View all other issues in [meta.unary.prop].
+View all issues with Ready status.
+Discussion:
++Unfortunately a class can have multiple copy constructors, and I believe to +be useful this trait should only return true is ALL copy constructors are +no-throw. +
++For instance: +
+++ + +struct awkward { + awkward( const awkward & ) throw() {} + awkward( awkward & ) { throw "oops"; } }; ++Proposed resolution:
++Change 20.4.4.3 [meta.unary.prop]: +
+ +++ +has_trivial_copy_constructor++T is a trivial type (3.9) or a reference type or a class type+with a trivial copy constructor+where all copy constructors are trivial (12.8). +++ +has_trivial_assign++T is neither const nor a reference type, and T is a trivial type (3.9) +or a class type+with a trivial copy assignment operatorwhere all copy assignment operators are trivial (12.8). +++ +has_nothrow_copy_constructor++has_trivial_copy_constructor<T>::value is true or T is a class type+with +awhere all copy constructorsthat isare +known not to throw any exceptions or T is an +array of such a class type +++ + + + + +has_nothrow_assign++T is neither const nor a reference type, and +has_trivial_assign<T>::value is true or T is a class type+with a+where all copy +assignment operators takeingan lvalue of type T that is known not to +throw any exceptions or T is an array of such a class type. +
750. The current definition for is_convertible requires that the type be implicitly convertible, so explicit constructors are ignored.
-Section: 20.4.5 [meta.rel] Status: New +
Section: 20.4.5 [meta.rel] Status: Open Submitter: Alisdair Meredith Date: 2007-10-10
-View all issues with New status.
+View all issues with Open status.
Discussion:
With the pending arrival of explicit conversion functions though, I'm wondering if we want an additional trait, is_explictly_convertible?
+[ +Bellevue: +]
+ + ++Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits. ++Proposed resolution:
@@ -14439,8 +12265,10 @@ wondering if we want an additional trait, is_explictly_convertible?
751. change pass-by-reference members of vector<bool> to pass-by-value?
-Section: 23.2.6 [vector.bool] Status: New +
Section: 23.2.7 [vector.bool] Status: New Submitter: Alisdair Meredith Date: 2007-10-10
+View other active issues in [vector.bool].
+View all other issues in [vector.bool].
View all issues with New status.
Discussion:
@@ -14449,6 +12277,39 @@ Is there any chance we could change them to pass-by-value or would I be wasting everyone's time if wrote up an issue?
+[ +post Bellevue: +]
+ + +++ ++As we understand it, the original requester (Martin Sebor) would like +for implementations to be permitted to pass-by-value. Alisdair suggests +that if this is to be resolved, it should be resolved more generally, +e.g. in other containers as well. +
++We note that this would break ABI. However, we also suspect that this +might be covered under the "as-if" rule in section 1.9. +
++Many in the group feel that for vector<bool>, this is a "don't care", +and that at this point in the process it's not worth the bandwidth. +
++Issue 679 -- which was in ready status pre-Bellevue and is +now in the working paper -- is related to this, though not a duplicate. +
++Moving to Open with a task for Alisdair to craft a informative note to +be put whereever appropriate in the WP. This note would clarify places +where pass-by-const-ref can be transformed to pass-by-value under the +as-if rule. +
+Proposed resolution:
@@ -14510,11 +12371,11 @@ requirements on allocator types.
753. Move constructor in draft
-Section: 20.1.1 [utility.arg.requirements] Status: New +
Section: 20.1.1 [utility.arg.requirements] Status: Open Submitter: Yechezkel Mett Date: 2007-10-14
View other active issues in [utility.arg.requirements].
View all other issues in [utility.arg.requirements].
-View all issues with New status.
+View all issues with Open status.
Discussion:
The draft standard n2369 uses the term move constructor in a few @@ -14553,7 +12414,7 @@ in filling the above requirement.
For vector::reserve, vector::resize and the vector modifiers given in -23.2.5.4 [vector.modifiers] we have +23.2.6.4 [vector.modifiers] we have
@@ -14590,6 +12451,1053 @@ possibly more concise too. +Proposed resolution:
++Add new defintions to 17.1 [definitions]: +
+ +++ ++move constructor +
++a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a +side effect during the construction. +
++move assignment operator +
++an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a +side effect during the assignment. +
++move assignment +
++use of the move assignment operator. +
+[ +Howard adds post-Bellevue: +]
+ + +++ + + + + + ++Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. reserve et. al. will use a move constructor +if one is available, else it will use a copy constructor. A type may have both. If the move constructor is +used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording +is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am +unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) +
+
+755. std::vector and std:string lack explicit shrink-to-fit operations
+Section: 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] Status: Ready + Submitter: Beman Dawes Date: 2007-10-31
+View all other issues in [vector.capacity].
+View all issues with Ready status.
+Discussion:
++A std::vector can be shrunk-to-fit via the swap idiom: +
+ ++ +vector<int> v; +... +v.swap(vector<int>(v)); // shrink to fit ++++or: +
vector<int>(v).swap(v); // shrink to fit ++++or: +
swap(v, vector<int>(v)); // shrink to fit +++A non-binding request for shrink-to-fit can be made to a std::string via: +
+ ++ +string s; +... +s.reserve(0); ++Neither of these is at all obvious to beginners, and even some +experienced C++ programmers are not aware that shrink-to-fit is +trivially available. +
++Lack of explicit functions to perform these commonly requested +operations makes vector and string less usable for non-experts. Because +the idioms are somewhat obscure, code readability is impaired. It is +also unfortunate that two similar vector-like containers use different +syntax for the same operation. +
++The proposed resolution addresses these concerns. The proposed function +takes no arguments to keep the solution simple and focused. +
+ + +Proposed resolution:
++To Class template basic_string 21.3 [basic.string] synopsis, +Class template vector 23.2.6 [vector] synopsis, and Class +vector<bool> 23.2.7 [vector.bool] synopsis, add: +
+ ++ ++void shrink_to_fit(); ++To basic_string capacity 21.3.4 [string.capacity] and vector +capacity 23.2.6.2 [vector.capacity], add: +
+ +++ + + + + +void shrink_to_fit(); +++Remarks: shrink_to_fit is a non-binding request to reduce +capacity() to size(). [Note: The request is non-binding to +allow latitude for implementation-specific optimizations. +-- end note] ++
+756. Container adaptors push
+Section: 23.2.5 [container.adaptors] Status: Open + Submitter: Paolo Carlini Date: 2007-10-31
+View all issues with Open status.
+Discussion:
++After n2369 we have a single push_back overload in the sequence containers, +of the "emplace" type. At variance with that, still in n2461, we have +two separate overloads, the C++03 one + one taking an rvalue reference +in the container adaptors. Therefore, simply from a consistency point of +view, I was wondering whether the container adaptors should be aligned +with the specifications of the sequence container themselves: thus have +a single push along the lines: +
+ ++ +template<typename... _Args> +void +push(_Args&&... __args) + { c.push_back(std::forward<_Args>(__args)...); } +[ +Related to 767 +]
+ + + +Proposed resolution:
++Change 23.2.5.1.1 [queue.defn]: +
+ ++ +void push(const value_type& x) { c.push_back(x); }+void push(value_type&& x) { c.push_back(std::move(x)); }+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); } ++Change 23.2.5.2 [priority.queue]: +
+ ++ +void push(const value_type& x) { c.push_back(x); }+void push(value_type&& x) { c.push_back(std::move(x)); }+template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); } ++Change 23.2.5.2.2 [priqueue.members]: +
+ +++ ++void push(const value_type& x);+++ ++
+Effects:++c.push_back(x);+push_heap(c.begin(), c.end(), comp);+template<class... Args> void push(+value_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)...); } +
+758. shared_ptr and nullptr
+Section: 20.6.12.2 [util.smartptr.shared] Status: Ready + Submitter: Joe Gottman Date: 2007-10-31
+View other active issues in [util.smartptr.shared].
+View all other issues in [util.smartptr.shared].
+View all issues with Ready status.
+Discussion:
++Consider the following program: +
+ ++ +int main() { + shared_ptr<int> p(nullptr); + return 0; +} ++This program will fail to compile because shared_ptr uses the following +template constructor to construct itself from pointers: +
+ ++ +template <class Y> shared_ptr(Y *); ++According +to N2431, +the conversion from nullptr_t to Y * is not +deducible, so the above constructor will not be found. There are similar problems with the +constructors that take a pointer and a deleter or a +pointer, a deleter and an allocator, as well as the +corresponding forms of reset(). Note that N2435 +will solve this problem for constructing from just nullptr, but not for constructors that use +deleters or allocators or for reset(). +
+ ++In the case of the functions that take deleters, there is the additional +question of what argument should be passed to the deleter when it is +eventually called. There are two reasonable possibilities: nullptr or +static_cast<T *>(0), where T is the template argument of the +shared_ptr. It is not immediately clear which of these is better. If +D::operator() is a template function similar to shared_ptr's +constructor, then d(static_cast<T*>(0)) will compile and d(nullptr) +will not. On the other hand, if D::operator()() takes a parameter that +is a pointer to some type other that T (for instance U* where U derives +from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not. +
+ +[ +Bellevue: +]
+ + +++ ++The general idea is right, we need to be able to pass a nullptr to a +shared_ptr, but there are a few borderline editorial issues here. (For +example, the single-argument nullptr_t constructor in the class synopsis +isn't marked explicit, but it is marked explicit in the proposed wording +for 20.6.6.2.1. There is a missing empty parenthesis in the form that +takes a nullptr_t, a deleter, and an allocator.) +
++More seriously: this issue says that a shared_ptr constructed from a +nullptr is empty. Since "empty" is undefined, it's hard to know whether +that's right. This issue is pending on handling that term better. +
++Peter suggests definition of empty should be "does not own anything" +
++Is there an editorial issue that post-conditions should refer to get() = +nullptr, rather than get() = 0? +
++No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. +
++Seems there are no technical merits between NAD and Ready, comes down to +"Do we intentially want to allow/disallow null pointers with these +functions". Staw Poll - support null pointers 5 - No null pointers 0 +
++Move to Ready, modulo editorial comments +
+[ +post Bellevue Peter adds: +]
+ + +++ + + ++The following wording changes are less intrusive: +
+ ++In 20.6.12.2.1 [util.smartptr.shared.const], add: +
+ ++ +shared_ptr(nullptr_t); ++after: +
+ ++ +shared_ptr(); ++(Absence of explicit intentional.) +
+ ++px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so +I'm not convinced of its utility. +
++It's similarly not clear to me whether the deleter constructors need to be +extended to take nullptr, but if they need to: +
++Add +
+ ++ +template<class D> shared_ptr(nullptr_t p, D d); +template<class D, class A> shared_ptr(nullptr_t p, D d, A a); ++after +
+ ++ +template<class Y, class D> shared_ptr(Y* p, D d); +template<class Y, class D, class A> shared_ptr(Y* p, D d, A a); ++Note that this changes the semantics of the new constructors such that they +consistently call d(p) instead of d((T*)0) when p is nullptr. +
++The ability to be able to pass 0/NULL to a function that takes a shared_ptr +has repeatedly been requested by users, but the other additions that the +proposed resolution makes are not supported by real world demand or +motivating examples. +
++It might be useful to split the obvious and non-controversial nullptr_t +constructor into a separate issue. Waiting for "empty" to be clarified is +unnecessary; this is effectively an alias for the default constructor. +
+Proposed resolution:
++Add the following constructors to 20.6.12.2 [util.smartptr.shared]: +
+ ++ +shared_ptr(nullptr_t); +template <class D> shared_ptr(nullptr_t, D d); +template <class D, class A> shared_ptr(nullptr_t, D d, A a); ++Add the following methods to 20.6.12.2 [util.smartptr.shared]: +
+ ++ +void reset(nullptr_t); +template <class D> void reset(nullptr_t, D d); +template <class D, class A> void reset(nullptr_t, D d, A a); ++Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]: +
+ +++ +explicit shared_ptr(nullptr_t); +++++Effects: Constructs an empty shared_ptr object. +
++Postconditions: use_count() == 0 && get() == 0. +
++Throws: nothing. +
+++ +template <class D> shared_ptr(nullptr_t, D d); +template <class D, class A> shared_ptr<nullptr_t, D d, A a); +++++Requires: D shall be CopyConstructible. The copy constructor and +destructor of D shall not throw exceptions. The expression +d(static_cast<T *>(0)) shall be well-formed, shall have well defined behavior, +and shall not throw exceptions. A shall be an allocator (20.1.2 [allocator.requirements]). +The copy constructor and destructor of A shall not throw +exceptions. +
++Effects: Constructs a shared_ptr object that owns a null pointer of type T * +and deleter d. The +second constructor shall use a copy of a to allocate memory for +internal use. +
++Postconditions: use_count() == 1 and get() == 0. +
++Throws: bad_alloc, or an implementation-defined exception when a +resource other than memory could not be obtained. +
++Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called. +
++Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]: +
+ +++ +void reset(nullptr_t); +++++Effects: Equivalent to shared_ptr(nullptr).swap(*this). +
+++ +template <class D> void reset(nullptr_t, const D d) +++++Effects: Equivalent to shared_ptr(nullptr, d).swap(*this). +
+++ + + + + + +template <class D, class A> void reset(nullptr_t, D d, A a); +++++Effects: Equivalent to shared_ptr(nullptr, d, a).swap(*this). +
+
+759. A reference is not an object
+Section: 23.1 [container.requirements] Status: Ready + Submitter: Jens Maurer Date: 2007-11-06
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Ready status.
+Discussion:
++23.1 [container.requirements] says: +
+ ++-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required. ++ ++A reference is not an object, but this sentence appears to claim so. +
+ ++What is probably meant here: +
++An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element of that container; no diagnostic required. ++ + + +Proposed resolution:
++Change 23.1 [container.requirements]: +
+ ++-12-+ + + + + + +Objects passed to member functions of a container as rvalue references shall not be elements+An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element +of that container.;Nno +diagnostic required. +
+760. The emplace issue
+Section: 23.1 [container.requirements] Status: Open + Submitter: Paolo Carlini Date: 2007-11-11
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Open status.
+Discussion:
++In an emplace member function the function parameter pack may be bound +to a priori unlimited number of objects: some or all of them can be +elements of the container itself. Apparently, in order to conform to the +blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for +that possibility. A possible solution can involve extending the +exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the +push_back and push_front member functions are luckily not affected by +this problem, can be efficiently implemented anyway +
+ +[ +Related to 767 +]
+ + +[ +Bellevue: +]
+ + +++ + + ++The proposed addition (13) is partially redundant with the existing +paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why +does it not cover subelements and pointers? +
++Resolution: Alan Talbot to rework language, then set state to Review. +
+Proposed resolution:
++Add after 23.1 [container.requirements]/12: +
+ +++ + + + + + ++-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required. +
++ +-13- Objects bound to the function parameter pack of the emplace member function shall not be elements or +sub-objects of elements of the container. No diagnostic required. + +
+ +
+761. unordered_map needs an at() member function
+Section: 23.4.1.2 [unord.map.elem] Status: Ready + Submitter: Joe Gottman Date: 2007-11-15
+View all issues with Ready status.
+Discussion:
++The new member function at() was recently added to std::map(). It acts +like operator[](), except it throws an exception when the input key is +not found. It is useful when the map is const, the value_type of the +key doesn't have a default constructor, it is an error if the key is +not found, or the user wants to avoid accidentally adding an element to +the map. For exactly these same reasons, at() would be equally useful +in std::unordered_map. +
+ + +Proposed resolution:
++Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]): +
+ ++ +mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; ++Add the following definitions to 23.4.1.2 [unord.map.elem]: +
+ +++ +mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; +++++Returns: A reference to x.second, where x is the (unique) element +whose key is equivalent to k. +
++Throws: An exception object of type out_of_range if no such element +is present. +
+[ +Bellevue: Editorial note: the "(unique)" differs from map. +]
+ + + + + + + +
+762. std::unique_ptr requires complete type?
+Section: 20.6.11 [unique.ptr] Status: Open + Submitter: Daniel Krügler Date: 2007-11-30
+View other active issues in [unique.ptr].
+View all other issues in [unique.ptr].
+View all issues with Open status.
+Discussion:
++In contrast to the proposed std::shared_ptr, std::unique_ptr +does currently not support incomplete types, because it +gives no explicit grant - thus instantiating unique_ptr with +an incomplete pointee type T automatically belongs to +undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last +bullet. This is an unnecessary restriction and prevents +many well-established patterns - like the bridge pattern - +for std::unique_ptr. +
+ +[ +Bellevue: +]
+ + ++Move to open. The LWG is comfortable with the intent of allowing +incomplete types and making unique_ptr more like shared_ptr, but we are +not comfortable with the wording. The specification for unique_ptr +should be more like that of shared_ptr. We need to know, for individual +member functions, which ones require their types to be complete. The +shared_ptr specification is careful to say that for each function, and +we need the same level of care here. We also aren't comfortable with the +"part of the operational semantic" language; it's not used elsewhere in +the standard, and it's not clear what it means. We need a volunteer to +produce new wording. ++ + +Proposed resolution:
++The proposed changes in the following revision refers to the current state of +N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed +according to the current state of 740. +
++The specialization unique_ptr<T[]> has some more restrictive constraints on +type-completeness on T than unique_ptr<T>. The following proposed wordings +try to cope with that. If the committee sees less usefulness on relaxed +constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation +e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1: +"T shall be a complete type, if used as template argument of +unique_ptr<T[], D> +
++This issue has some overlap with 673, but it seems not to cause any +problems with this one, +because 673 adds only optional requirements on D that do not conflict +with the here discussed +ones, provided that D::pointer's operations (including default +construction, copy construction/assignment, +and pointer conversion) are specified not to throw, otherwise this +would have impact on the +current specification of unique_ptr. +
+ ++
+ +- +
+ ++In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para: +
+ ++The unique_ptr provides a semantics of strict ownership. A +unique_ptr owns the object it holds a pointer to. A +unique_ptr is not CopyConstructible, nor +CopyAssignable, however it is MoveConstructible and +MoveAssignable. The template parameter T of +unique_ptr may be an incomplete type. [ Note: The +uses of unique_ptr include providing exception safety for +dynamically allcoated memory, passing ownership of dynamically allocated +memory to a function, and returning dynamically allocated memory from a +function. -- end note ] ++- +
+ ++20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +
+ +++[ +N.B.: We only need the requirement that D is DefaultConstructible. +The current wording says just this. +]
+ +- +
+ ++In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: +
+ ++++Requires:
+The expression D()(p) shall be well formed. The default constructor +of D shall not throw an exception.+Dmustshall not be a reference type. + +D shall be default constructible, and that construction +shall not throw an exception. + +[ +N.B.: There is no need that the expression D()(p) is well-formed at +this point. I assume that the current wording is based on the +corresponding shared_ptr wording. In case of shared_ptr this +requirement is necessary, because the corresponding c'tor *can* fail +and must invoke delete p/d(p) in this case. Unique_ptr is simpler in +this regard. The *only* functions that must insist on well-formedness +and well-definedness of the expression get_deleter()(get()) are (1) +the destructor and (2) reset. The reasoning for the wording change to +explicitly require DefaultConstructible of D is to guarantee that +invocation of +D's default c'tor is both well-formed and well-defined. Note also that +we do *not* need the +requirement that T must be complete, also in contrast to shared_ptr. +Shared_ptr needs this, because it's c'tor is a template c'tor which +potentially requires Convertible<Y*, X*>, which +again requires Completeness of Y, if !SameType<X, Y> +]
+ +- +
+ ++Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence +of 12, but transferring the "requires" to 13: +
+ ++++Requires: If D is not an lvalue-reference type then[..] +
+[ +N.B.: For the same reasons as for (3), there is no need that d(p) is +well-formed/well-defined at this point. The current wording guarantees +all what we need, namely that the initialization of both the T* +pointer and the D deleter are well-formed and well-defined. +]
+ +- +20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. +
+- +
+ +20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.
+ +[ +N.B.: The current wording of 21 already implicitly guarantees that U +is completely defined, because it requires that Convertible<U*, T*> is +true. If the committee wishes this explicit requirement can be added, +e.g. "U shall be a complete type." +]
+ +- +
+ ++20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: +
++++Requires: The expression get_deleter()(get()) shall be well-formed, +shall have well-defined behavior, and shall not throw exceptions. +
+[ +N.B.: This requirement ensures that the whole responsibility on +type-completeness of T is delegated to this expression. +]
+ +- +
+ ++20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the +current editorial issue, that "must shall" has to be changed to +"shall", but this change is not a special part of this resolution. +
+ +[ +N.B. The current wording is sufficient, because we can delegate all +further requirements on the requirements of the effects clause +]
+ +- +
+ ++20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary. +
+[ +N.B.: The current wording of p. 6 already implicitly guarantees that +U is completely defined, because it requires that Convertible<U*, T*> +is true, see (6)+(8). +]
+ +- +
+ ++20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. +
+[ +N.B.: Delegation to requirements of effects clause is sufficient. +]
+ +- +20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary. +
+ +- +20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. +
+ +- +
+ ++20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: +
++Requires: The expression get_deleter()(get()) shall be well-formed, +shall have well-defined behavior, and shall not throw exceptions. ++- +20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. +
+ +- +
+ ++20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just +before the current one: +
+ ++++Requires: T shall be a complete type. +
+[ +N.B.: We need this requirement, because otherwise it is not +guaranteed that the c'tors can fulfill their requirements to reject +any type that is convertible to T*. +]
+ +- +20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says: +
+ ++Requires: i < the size of the array to which the stored pointer +points. T shall be a complete type. ++ +- +
++20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the +paragraph to say: +
+++ ++Requires: T shall be a complete type. Does not accept pointer types +which are convertible to T* (diagnostic required). [ Note: ...] +
+[ +N.B. Similar to (15) we need this requirement such that reset can +reject types which are convertible to T* +]
+ +[ +post Bellevue: Daniel provided revised wording. +]
+ + + + + + + +
+765. more on iterator validity
+Section: 24.1 [iterator.requirements] Status: New + Submitter: Martin Sebor Date: 2007-12-14
+View other active issues in [iterator.requirements].
+View all other issues in [iterator.requirements].
+View all issues with New status.
+Discussion:
++ +Issue 278 +defines the meaning of the term "invalid iterator" as one that may be +singular. + +
++ +Consider the following code: + +
+std::deque<int> x, y; + std::deque<int>::iterator i = x.end(), j = y.end(); + x.swap(y); +++ +Given that
+swap()
is required not to invalidate iterators +and using the definition above, what should be the expected result of +comparingi
andj
tox.end()
+andy.end()
, respectively, after theswap()
? + ++ +I.e., is the expression below required to evaluate +to
+true
? + +i == y.end() && j == x.end() +++ +(There are at least two implementations where the expression +returns
+false
.) + ++ +More generally, is the definition introduced in issue 278 meant to +make any guarantees about whether iterators actually point to the same +elements or be associated with the same containers after a +non-invalidating operation as they did before? + +
++ +Here's a motivating example intended to demonstrate the importance of +the question: + +
+Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 } + Container::iterator i = y.begin() + 1; + Container::iterator j = y.end(); + std::swap(x, y); + std::find(i, j, 3); +++ +
+ +swap()
guarantees thati
andj
+continue to be valid. Unless the spec says that even though they are +valid they may no longer denote a valid range the code above must be +well-defined. Expert opinions on this differ as does the behavior of +popular implementations for some standardContainers
. + +Proposed resolution:
@@ -14599,92 +13507,1326 @@ possibly more concise too.
-754. Ambiguous return clause for std::uninitialized_copy
-Section: 20.6.4.1 [uninitialized.copy] Status: New - Submitter: Daniel Krügler Date: 2007-10-15
-View other active issues in [uninitialized.copy].
-View all other issues in [uninitialized.copy].
-View all issues with New status.
+766. Inconsistent exception guarantees between ordered and unordered associative containers
+Section: 23.1 [container.requirements], 23.1.3.1 [unord.req.except] Status: Ready + Submitter: Ion Gaztańaga Date: 2007-12-22
+View other active issues in [container.requirements].
+View all other issues in [container.requirements].
+View all issues with Ready status.
Discussion:
-14882-2003, [lib.uninitialized.copy] is currently written as follows: +23.1 [container.requirements]p10 states:
-+ +template <class InputIterator, class ForwardIterator> - ForwardIterator uninitialized_copy(InputIterator first, InputIterator last, - ForwardIterator result); -++Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following +additional requirements: +
++ +
+- [...]
+ +- no erase(), pop_back() or pop_front() function throws an exception.
+ ++23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer +additional guarantees for deque/vector insert() and +erase() members. However, 23.1 [container.requirements]p10 +does not mention 23.1.3.1 [unord.req.except] that specifies exception +safety guarantees +for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1 +offers the following guaratee for +erase(): +
+-+No erase() function throws an exception unless that exception +is thrown by the container's Hash or Pred object (if any).--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.6.4.1 [uninitialized.copy]. +Summary:
-It's not clear to me what the return clause is supposed to mean, I see -two -possible interpretations: +According to 23.1 [container.requirements]p10 no +erase() function should throw an exception unless otherwise +specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees +for unordered containers, allowing erase() to throw if +predicate or hash function throws.
-+
+In contrast, associative containers have no exception safety guarantees +section so no erase() function should throw, including +erase(k) that needs to use the predicate function to +perform its work. This means that the predicate of an associative +container is not allowed to throw. +
+ ++So: +
+ ++ +
- -The notion of result is supposed to mean the value given by the -function parameter result [Note to the issue editor: Please use italics for -result]. -This seems somewhat implied by recognizing that both the function -parameter -and the name used in the clause do have the same italic font. +erase(k) for associative containers is not allowed to throw. On +the other hand, erase(k) for unordered associative containers +is allowed to throw.
- -The notion of "result" is supposed to mean the value of result -after the -preceding effects clause. This is in fact what all implementations I -checked -do (and which is probably it's intend, because it matches the -specification of std::copy). +erase(q) for associative containers is not allowed to throw. On +the other hand, erase(q) for unordered associative containers +is allowed to throw if it uses the hash or predicate. +
+- +To fulfill 1), predicates of associative containers are not allowed to throw. +Predicates of unordered associative containers are allowed to throw. +
+- +2) breaks a widely used programming pattern (flyweight pattern) for +unordered containers, where objects are registered in a global map in +their constructors and unregistered in their destructors. If erase(q) is +allowed to throw, the destructor of the object would need to rethrow the +exception or swallow it, leaving the object registered.
Proposed resolution:
-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. +Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception +safety guarantees". +
+ +++ ++1 For associative containers, no clear() function throws an exception. +erase(k) does not throw an exception unless that exception is thrown by +the container's Pred object (if any). +
+ ++2 For associative containers, if an exception is thrown by any operation +from within an insert() function inserting a single element, the +insert() function has no effect. +
+ ++3 For associative containers, no swap function throws an exception +unless that exception is thrown by the copy constructor or copy +assignment operator of the container's Pred object (if any). +
++Change 23.1.3.1 [unord.req.except]p1: +
+ ++For unordered associative containers, no clear() function +throws an exception.+ +Noerase(k) +functiondoes not throwsan exception +unless that exception is thrown by the container's Hash or Pred object +(if any). ++Change 23.1 [container.requirements]p10 to add references to new sections: +
+ ++Unless otherwise specified (see [deque.modifiers], ++ +and[vector.modifiers], [associative.req.except], +[unord.req.except]) all container types defined in this clause meet +the following additional requirements: ++Change 23.1 [container.requirements]p10 referring to swap: +
+ +++ + + + + + ++
+- +no swap() function throws an exception
+unless that exception is thrown +by the copy constructor or assignment operator of the container's +Compare object (if any; see [associative.reqmts]). +
+767. Forwarding and backward compatibility
+Section: 23 [containers] Status: Open + Submitter: Sylvain Pion Date: 2007-12-28
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with Open status.
+Discussion:
++Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile: +
+ ++ +#include <vector> + +int main() +{ + std::vector<char *> v; + v.push_back(0); +} ++now fails with the following error message: +
+ +.../include/c++/4.3.0/ext/new_allocator.h: In member +function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, +_Args&& ...) [with _Args = int, _Tp = char*]': +.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void +std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with +_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' +test.cpp:6: instantiated from here +.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid +conversion from 'int' to 'char*' ++ ++As far as I know, g++ follows the current draft here. +
++Does the committee really intend to break compatibility for such cases? +
+ +[ +Sylvain adds: +]
+ + +++ ++I just noticed that std::pair has the same issue. +The following now fails with GCC's -std=c++0x mode: +
+ ++ +#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} ++I have not made any general audit for such problems elsewhere. +
+[ +Related to 756 +]
+ + +[ +Bellevue: +]
+ + +++ + + ++Motivation is to handle the old-style int-zero-valued NULL pointers. +Problem: this solution requires concepts in some cases, which some users +will be slow to adopt. Some discussion of alternatives involving +prohibiting variadic forms and additional library-implementation +complexity. +
++Discussion of "perfect world" solutions, the only such solution put +forward being to retroactively prohibit use of the integer zero for a +NULL pointer. This approach was deemed unacceptable given the large +bodies of pre-existing code that do use integer zero for a NULL pointer. +
++Another approach is to change the member names. Yet another approach is +to forbid the extension in absence of concepts. +
++Resolution: These issues (756, 767, 760, 763) will be subsumed into a +paper to be produced by Alan Talbot in time for review at the 2008 +meeting in France. Once this paper is produced, these issues will be +moved to NAD. +
+Proposed resolution:
++Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]: +
+ +++ ++
++ + +expression return type assertion/note
pre-/post-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); +
+768. Typos in [atomics]?
+Section: 29.4.3 [atomics.types.generic] Status: Ready + Submitter: Alberto Ganesh Barbati Date: 2007-12-28
+View all issues with Ready status.
+Discussion:
++in the latest publicly available draft, paper +N2641, +in section 29.4.3 [atomics.types.generic], the following specialization of the template +atomic<> is provided for pointers: +
+ ++ +template <class T> struct atomic<T*> : atomic_address { + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; ++First of all, there is a typo in the non-default constructor which +should take a T* rather than a T. +
+ ++As you can see, the specialization redefine and therefore hide a few +methods from the base class atomic_address, namely fetch_add, fetch_sub, +operator=, operator+= and operator-=. That's good, but... what happened +to the other methods, in particular these ones: +
+ ++ +void store(T*, memory_order = memory_order_seq_cst) volatile; +T* load( memory_order = memory_order_seq_cst ) volatile; +T* swap( T*, memory_order = memory_order_seq_cst ) volatile; +bool compare_swap( T*&, T*, memory_order, memory_order ) volatile; +bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile; ++By reading paper +N2427 "C++ Atomic Types and Operations", +I see that the +definition of the specialization atomic<T*> matches the one in the +draft, but in the example implementation the methods load(), swap() +and compare_swap() are indeed present. +
+ ++Strangely, the example implementation does not redefine the method +store(). It's true that a T* is always convertible to void*, but not +hiding the void* signature from the base class makes the class +error-prone to say the least: it lets you assign pointers of any type to +a T*, without any hint from the compiler. +
+ ++Is there a true intent to remove them from the specialization or are +they just missing from the definition because of a mistake? +
+ +[ +Bellevue: +]
+ + +++ + ++The proposed revisions are accepted. +
++Further discussion: why is the ctor labeled "constexpr"? Lawrence said +this permits the object to be statically initialized, and that's +important because otherwise there would be a race condition on +initialization. +
+Proposed resolution:
++Change the synopsis in 29.4.3 [atomics.types.generic]: +
+ ++ + + + + + +template <class T> struct atomic<T*> : atomic_address { + void store(T*, memory_order = memory_order_seq_cst) volatile; + T* load( memory_order = memory_order_seq_cst ) volatile; + T* swap( T*, memory_order = memory_order_seq_cst ) volatile; + bool compare_swap( T*&, T*, memory_order, memory_order ) volatile; + bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile; + + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T*); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; +
+769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"
+Section: 20.5.15.2 [func.wrap.func] Status: New + Submitter: Daniel Krügler Date: 2008-01-10
+View all issues with New status.
+Discussion:
++N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed +(implicit) conversion operator to "unspecified-bool-type" by the new +explicit bool conversion, but the inverse conversion should also +use the new std::nullptr_t type instead of "unspecified-null-pointer- +type". +
+ + +Proposed resolution:
+ ++In 20.5 [function.objects], header <functional> synopsis replace: +
+ ++ +template<class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); +template<class R, class... ArgTypes> + bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); +template<class R, class... ArgTypes> + bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); ++In the class function synopsis of 20.5.15.2 [func.wrap.func] replace +
+ ++ +function(unspecified-null-pointer-typenullptr_t); +... +function& operator=(unspecified-null-pointer-typenullptr_t); ++In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace: +
+ ++ +template <class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); +template <class R, class... ArgTypes> + bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>&,unspecified-null-pointer-typenullptr_t); +template <class R, class... ArgTypes> + bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>&); ++In 20.5.15.2.1 [func.wrap.func.con], replace +
+ ++ +function(unspecified-null-pointer-typenullptr_t); +... +function& operator=(unspecified-null-pointer-typenullptr_t); ++In 20.5.15.2.6 [func.wrap.func.nullptr], replace +
+ ++ +template <class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>& f,unspecified-null-pointer-typenullptr_t); +template <class R, class... ArgTypes> + bool operator==(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>& f); ++and replace +
+ ++ + + + + + +template <class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>& f,unspecified-null-pointer-typenullptr_t); +template <class R, class... ArgTypes> + bool operator!=(unspecified-null-pointer-typenullptr_t , const function<R(ArgTypes...)>& f); +
+770. std::function should use rvalue swap
+Section: 20.5.15 [func.wrap] Status: Ready + Submitter: Daniel Krügler Date: 2008-01-10
+View all issues with Ready status.
+Discussion:
++It is expected that typical implementations of std::function will +use dynamic memory allocations at least under given conditions, +so it seems appropriate to change the current lvalue swappabilty of +this class to rvalue swappability. +
+ + +Proposed resolution:
++In 20.5 [function.objects], header <functional> synopsis, just below of +
+ ++ +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&); ++In 20.5.15.2 [func.wrap.func] class function definition, change +
+ ++ +void swap(function&&); ++In 20.5.15.2 [func.wrap.func], just below of +
+ ++ +template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&); ++In 20.5.15.2.2 [func.wrap.func.mod] change +
+ ++ +void swap(function&& other); ++In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads +
+ ++ + + + + + +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2); +
+771. Impossible throws clause in [string.conversions]
+Section: 21.4 [string.conversions] Status: Review + Submitter: Daniel Krügler Date: 2008-01-13
+View other active issues in [string.conversions].
+View all other issues in [string.conversions].
+View all issues with Review status.
+Discussion:
++The new to_string and to_wstring functions described in 21.4 [string.conversions] +have throws clauses (paragraphs 8 and 16) which say: +
+ ++Throws: nothing ++ ++Since all overloads return either a std::string or a std::wstring by value +this throws clause is impossible to realize in general, since the basic_string +constructors can fail due to out-of-memory conditions. Either these throws +clauses should be removed or should be more detailled like: +
+ ++Throws: Nothing if the string construction throws nothing ++ ++Further there is an editorial issue in p. 14: All three to_wstring +overloads return a string, which should be wstring instead (The +header <string> synopsis of 21.2 [string.classes] is correct in this +regard).
Proposed resolution:
-Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]): +In 21.4 [string.conversions], remove the paragraphs 8 and 16.
++ +string to_string(long long val); +string to_string(unsigned long long val); +string to_string(long double val); ++++Throws: nothing+++ + + + + + +wstring to_wstring(long long val); +wstring to_wstring(unsigned long long val); +wstring to_wstring(long double val); ++++Throws: nothing+
+772. Impossible return clause in [string.conversions]
+Section: 21.4 [string.conversions] Status: New + Submitter: Daniel Krügler Date: 2008-01-13
+View other active issues in [string.conversions].
+View all other issues in [string.conversions].
+View all issues with New status.
+Discussion:
--2- Returns: The value of result after effects have taken place. +The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring +overloads says: +
+ ++Returns: each function returns a wstring object holding the character +representation of the value of its argument that would be generated by +calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld", +or L"%f", respectively. ++ ++Problem is: There does not exist any wsprintf function in C99 (I checked +the 2nd edition of ISO 9899, and the first and the second corrigenda from +2001-09-01 and 2004-11-15). What probably meant here is the function +swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent +declaration: +
+ ++ +int swprintf(wchar_t * restrict s, size_t n, +const wchar_t * restrict format, ...); ++therefore the paragraph needs to mention the size_t parameter n. +
+ + + +Proposed resolution:
++Change the current wording of 21.4 [string.conversions]/p. 15 to: +
+ ++Returns:+ +eEach function returns a +wstring object holding the character representation of the +value of its argument that would be generated by calling +wsswprintf(buf, bufsz, fmt, +val) with a format specifier fmt of L"%lld", +L"%ulld", or L"%f", respectively, where buf +designates an internal character buffer of sufficient size bufsz. ++[Hint to the editor: The resolution also adds to mention the name of +the format specifier "fmt"] +
+ ++I also would like to remark that the current wording of it's equivalent +paragraph 7 should also mention the meaning of buf and fmt. +
+ ++Change the current wording of 21.4 [string.conversions]/p. 7 to: +
+ ++Returns:+ + + + + + +eEach function returns a string object holding the +character representation of the value of its argument that would be +generated by calling sprintf(buf, fmt, val) with a format specifier fmt of +"%lld", "%ulld", or "%f", respectively, where buf designates an internal +character buffer of sufficient size. +
+774. Member swap undefined for most containers
+Section: 23 [containers] Status: Open + Submitter: Alisdair Meredith Date: 2008-01-14
+View other active issues in [containers].
+View all other issues in [containers].
+View all issues with Open status.
+Discussion:
++It appears most containers declare but do not define a member-swap +function. +
+ ++This is unfortunate, as all overload the swap algorithm to call the +member-swap function! +(required for swappable guarantees [Table 37] and Container Requirements +[Table 87]) +
+ ++Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b), +yet for all containers we define swap(a,b) to call a.swap(b) - a circular +definition. +
+ ++A quick survey of clause 23 shows that the following containers provide a +definition for member-swap: +
+ ++ +array +queue +stack +vector ++Whereas the following declare it, but do not define the semantics: +
+ ++ +deque +list +map +multimap +multiset +priority_queue +set +unordered_map +unordered_multi_map +unordered_multi_set +unordered_set ++Suggested resolution: +
++Provide a definition for each of the affected containers... ++ +[ +Bellevue: +]
+ + ++Move to Open and ask Alisdair to provide wording. ++ + +Proposed resolution:
++Wording provided in +N2590. +
+ + + + + +
+775. Tuple indexing should be unsigned?
+Section: 20.3.1.4 [tuple.helper] Status: Ready + Submitter: Alisdair Meredith Date: 2008-01-16
+View all issues with Ready status.
+Discussion:
++The tuple element access API identifies the element in the sequence +using signed integers, and then goes on to enforce the requirement that +I be >= 0. There is a much easier way to do this - declare I as +unsigned. +
++In fact the proposal is to use
+std::size_t
, matching the type used in the tuple_size API. ++A second suggestion is that it is hard to imagine an API that deduces +and index at compile time and returns a reference throwing an exception. +Add a specific Throws: Nothing paragraph to each element +access API. +
++In addition to
+ +tuple
, update the API applies to +pair
andarray
, and should be updated +accordingly. ++A third observation is that the return type of the
+ + +get
+functions forstd::pair
is pseudo-code, but it is not +clearly marked as such. There is actually no need for pseudo-code as +the return type can be specified precisely with a call to +tuple_element
. This is already done for +std::tuple
, andstd::array
does not have a +problem as all elements are of typeT
. +Proposed resolution:
++Update header <utility> synopsis in 20.2 [utility] +
+// 20.2.3, tuple-like access to pair: +template <class T> class tuple_size; +template <+intsize_t I, class T> class tuple_element; + +template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >; + +template<intsize_t I, class T1, class T2> +Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&); +template<intsize_t I, class T1, class T2> + constPtypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&); ++Update 20.2.3 [pairs] Pairs +
+template<+intsize_t I, class T1, class T2> +Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&); +template<intsize_t I, class T1, class T2> + constPtypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&); ++
+24 Return type: If+I == 0
thenP
isT1
, ifI == 1
thenP
isT2
, and otherwise the program is ill-formed.+25 Returns: If
+I == 0
returnsp.first
,otherwiseifI == 1
returnsp.second
, and otherwise the program is ill-formed. ++Throws: Nothing. +
+ + ++Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below: +
+template <+ +intsize_t I, class T> class tuple_element; // undefined +template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >; + +// 20.3.1.4, element access: +template <intsize_t I, class... Types> + typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&); +template <intsize_t I, class ... types> + typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&); ++Update 20.3.1.4 [tuple.helper] Tuple helper classes +
+template <+intsize_t I, class... Types> +class tuple_element<I, tuple<Types...> > { +public: + typedef TI type; +};+1 Requires:
+. The program is ill-formed if
0 <= I andI < sizeof...(Types)I
is out of bounds. ++2 Type:
+TI
is the type of theI
th element ofTypes
, where indexing is zero-based. ++Update 20.3.1.5 [tuple.elem] Element access +
+template <+1 Requires:intsize_t I, class... types > +typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t); +. The program is ill-formed if
0 <= I andI < sizeof...(Types)I
is out of bounds. ++2 Returns: A reference to the
+Throws: Nothing. +I
th element oft
, where indexing is zero-based. +template <+intsize_t I, class... types> +typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t); ++3 Requires:
+. The program is ill-formed if
0 <= I andI < sizeof...(Types)I
is out of bounds. ++4 Returns: A const reference to the
+I
th element oft
, where indexing is zero-based. ++Throws: Nothing. +
+ + ++Update header <array> synopsis in 20.2 [utility] +
+template <class T> class tuple_size; // forward declaration +template <+ +intsize_t I, class T> class tuple_element; // forward declaration +template <class T, size_t N> + struct tuple_size<array<T, N> >; +template <intsize_t I, class T, size_t N> + struct tuple_element<I, array<T, N> >; +template <intsize_t I, class T, size_t N> + T& get(array<T, N>&); +template <intsize_t I, class T, size_t N> + const T& get(const array<T, N>&); ++Update 23.2.1.6 [array.tuple] Tuple interface to class template array +
+tuple_element<size_t I, array<T, N> >::type +++3 Requires:
+The program is ill-formed if
0 <=I < N.I
is out of bounds. ++4 Value: The type
+T
. +template <+intsize_t I, class T, size_t N> T& get(array<T, N>& a); ++5 Requires:
+. The program is ill-formed if
0 <=I < NI
is out of bounds. ++Returns: A reference to the
+I
th element ofa
, where indexing is zero-based. ++Throws: Nothing. +
+template <+intsize_t I, class T, size_t N> const T& get(const array<T, N>& a); ++6 Requires:
+. The program is ill-formed if
0 <=I < NI
is out of bounds. ++7 Returns: A const reference to the
+I
th element ofa
, where indexing is zero-based. ++Throws: Nothing. +
+ + +[ +Bellevue: Note also that the phrase "The program is ill-formed if I is +out of bounds" in the requires clauses are probably unnecessary, and +could be removed at the editor's discretion. Also std:: qualification +for pair is also unnecessary. +]
+ + + + +
+776. Undescribed assign function of std::array
+Section: 23.2.1 [array] Status: Review + Submitter: Daniel Krügler Date: 2008-01-20
+View other active issues in [array].
+View all other issues in [array].
+View all issues with Review status.
+Discussion:
++The class template array synopsis in 23.2.1 [array]/3 declares a member +function +
+ ++ +void assign(const T& u); ++which's semantic is no-where described. Since this signature is +not part of the container requirements, such a semantic cannot +be derived by those. +
+ ++I found only one reference to this function in the issue list, +588 where the question is raised: +
+ ++what's the effect of calling assign(T&) on a zero-sized array? ++ ++which does not answer the basic question of this issue. +
+ ++If this function shall be part of the std::array, it's probable +semantic should correspond to that of boost::array, but of +course such wording must be added. +
+ + +Proposed resolution:
++Just after the section 23.2.1.4 [array.data] add the following new section: +
+ ++23.2.1.5 array::fill [array.fill] +
+ +++ +void fill(const T& u); ++ ++1: Effects: fill_n(begin(), N, u) +
++[N.B: I wonder, why class array does not have a "modifiers" +section. If it had, then assign would naturally belong to it] +
+ ++Change the synopsis in 23.2.1 [array]/3: +
+ ++ + +template <class T, size_t N> +struct array { + ... + voidassignfill(const T& u); + ... +[ +Bellevue: +]
+ + +++ + + + ++Suggest substituting "fill" instead of "assign". +
++Set state to Review given substitution of "fill" for "assign". +
+
+777. Atomics Library Issue
+Section: 29.4.4 [atomics.types.operations] Status: Ready + Submitter: Lawrence Crowl Date: 2008-01-21
+View all issues with Ready status.
+Discussion:
++The load functions are defined as +
+ ++ +C atomic_load(volatile A* object); +C atomic_load_explicit(volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) volatile; ++which prevents their use in const contexts. +
+ +[ +post Bellevue Peter adds: +]
+ + +++ + + ++Issue 777 suggests making atomic_load operate on const objects. There is a +subtle point here. Atomic loads do not generally write to the object, except +potentially for the memory_order_seq_cst constraint. Depending on the +architecture, a dummy write with the same value may be required to be issued +by the atomic load to maintain sequential consistency. This, in turn, may +make the following code: +
+ ++ +const atomic_int x{}; + +int main() +{ + x.load(); +} ++dump core under a straightforward implementation that puts const objects in +a read-only section. +
++There are ways to sidestep the problem, but it needs to be considered. +
++The tradeoff is between making the data member of the atomic types +mutable and requiring the user to explicitly mark atomic members as +mutable, as is already the case with mutexes. +
+Proposed resolution:
++Add the const qualifier to *object and *this. +
+ ++ + + + + + +C atomic_load(const volatile A* object); +C atomic_load_explicit(const volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) const volatile; +
+778. std::bitset does not have any constructor taking a string literal
+Section: 23.3.5.1 [bitset.cons] Status: Ready + Submitter: Thorsten Ottosen Date: 2008-01-24
+View other active issues in [bitset.cons].
+View all other issues in [bitset.cons].
+View all issues with Ready status.
+Duplicate of: 116
+Discussion:
++A small issue with std::bitset: it does not have any constructor +taking a string literal, which is clumsy and looks like an oversigt when +we tried to enable uniform use of string and const char* in the library. +
+ ++Suggestion: Add +
+ ++ +explicit bitset( const char* str ); ++to std::bitset. +
+ + +Proposed resolution:
++Add to synopsis in 23.3.5 [template.bitset] +
+ ++ +explicit bitset( const char* str ); ++Add to synopsis in 23.3.5.1 [bitset.cons] +
+ +@@ -14693,4 +14835,4382 @@ Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]): +explicit bitset( const char* str ); +++Effects: Constructs a bitset as if bitset(string(str)).
+779. Resolution of #283 incomplete
+Section: 25.2.8 [alg.remove] Status: New + Submitter: Daniel Krügler Date: 2008-01-25
+View all other issues in [alg.remove].
+View all issues with New status.
+Discussion:
++The resolution of 283 did not resolve similar necessary changes for algorithm +remove_copy[_if], +which seems to be an oversight. +
+ + +Proposed resolution:
++In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of: +
+ ++Requires:+ +Type T is EqualityComparable (31).The ranges [first,last) +and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be +valid. ++or +
+ ++Requires:+ + + + + + +Type T is EqualityComparable (31).The ranges [first,last) +and [result,result + (last - first)) shall not overlap. +The result of the expression *first shall +be writable to the output iterator. +
+780. std::merge() specification incorrect/insufficient
+Section: 25.3.4 [alg.merge] Status: New + Submitter: Daniel Krügler Date: 2008-01-25
+View all issues with New status.
+Discussion:
++Though issue 283 has fixed many open issues, it seems that some are still open: +
+ ++Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 +have no Requires element and the Effects element contains some requirements, +which is probably editorial. Worse is that: +
+ ++
+ + + +- +no assignment requirements are specified (neither implicit nor explicit). +
+ +- +the effects clause just speaks of "merges", which is badly worded +near to a circular definition. +
+ +- +p. 2 mentions a range [first, last), which is not defined by the +function arguments or otherwise. +
+ +- +p. 2 says "according to the ordering defined by comp" which is both +incomplete (because +this excludes the first variant with <) and redundant (because the +following subordinate +clause mentions comp again) +
+Proposed resolution:
++In 25.3.4 [alg.merge] replace p.1+ 2: +
+ +++ ++Effects:
+ +MergesCopies all the elements of the two sorted ranges [first1,last1) and +[first2,last2) into the range +[result,result + (last1 - first1) + (last2 - first2))+[result, last) (where last is equal to result + (last1 +- first1) + (last2 - first2)), such that resulting range will be +sorted in non-decreasing order; that is, for every iterator i in +[result,last) other than result, the condition *i < *(i - 1) or, +respectively, comp(*i, *(i - 1)) will be false. ++Requires: The resulting range shall not overlap with either of the original ranges.
+The list will be sorted in non-decreasing +order according to the ordering defined by comp; that is, for every iterator i in +[first,last) other than first, the condition *i < *(i - 1) or +comp(*i, *(i - 1)) will be false.The results of the expressions *first1 and *first2 +shall be writable to the output iterator. ++[N.B.: I attempted to reuse the wording style of inplace_merge, +therefore proposing to +insert ", respectively," between both predicate tests. This is no +strictly necessary as +other parts of <algorithm> show, just a matter of consistency] +
+ + + + + + +
+781. std::complex should add missing C99 functions
+Section: 26.3.7 [complex.value.ops] Status: Ready + Submitter: Daniel Krügler Date: 2008-01-26
+View other active issues in [complex.value.ops].
+View all other issues in [complex.value.ops].
+View all issues with Ready status.
+Discussion:
++A comparision of the N2461 header <complex> synopsis ([complex.synopsis]) +with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show +some complex functions that are missing in C++. These are: +
+ ++
+ +- +7.3.9.4: (required elements of the C99 library)
+
+The cproj functions +- +7.26.1: (optional elements of the C99 library)
+
+cerf cerfc cexp2 +cexpm1 clog10 clog1p +clog2 clgamma ctgamma +++I propose that at least the required cproj overloads are provided as equivalent +C++ functions. This addition is easy to do in one sentence (delegation to C99 +function). +
+ ++Please note also that the current entry polar +in 26.3.9 [cmplx.over]/1 +should be removed from the mentioned overload list. It does not make sense to require that a +function already expecting scalar arguments +should cast these arguments into corresponding +complex<T> arguments, which are not accepted by +this function. +
+ + +Proposed resolution:
++In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs: +
+ ++ +template<class T> complex<T> conj(const complex<T>&); +template<class T> complex<T> proj(const complex<T>&); +template<class T> complex<T> fabs(const complex<T>&); ++In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add: +
+ +++ +template<class T> complex<T> proj(const complex<T>& x); +++ +Effects: Behaves the same as C99 function cproj, defined in +subclause 7.3.9.4." +++In 26.3.9 [cmplx.over]/1, add one further entry proj to +the overload list. +
+ +++ + + + + + ++The following function templates shall have additional overloads: +
++arg norm +conjpolarproj +imag real +
+782. Extended seed_seq constructor is useless
+Section: 26.4.7.1 [rand.util.seedseq] Status: Ready + Submitter: Daniel Krügler Date: 2008-01-27
+View other active issues in [rand.util.seedseq].
+View all other issues in [rand.util.seedseq].
+View all issues with Ready status.
+Discussion:
++Part of the resolution of n2423, issue 8 was the proposal to +extend the seed_seq constructor accepting an input range +as follows (which is now part of N2461): +
+ ++ +template<class InputIterator, +size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> +seed_seq(InputIterator begin, InputIterator end); ++First, the expression iterator_traits<InputIterator>::value_type +is invalid due to missing typename keyword, which is easy to +fix. +
+ ++Second (and worse), while the language now supports default +template arguments of function templates, this customization +point via the second size_t template parameter is of no advantage, +because u can never be deduced, and worse - because it is a +constructor function template - it can also never be explicitly +provided (14.8.1 [temp.arg.explicit]/7). +
+ ++The question arises, which advantages result from a compile-time +knowledge of u versus a run time knowledge? If run time knowledge +suffices, this parameter should be provided as normal function +default argument [Resolution marked (A)], if compile-time knowledge +is important, this could be done via a tagging template or more +user-friendly via a standardized helper generator function +(make_seed_seq), which allows this [Resolution marked (B)]. +
+ +[ +Bellevue: +]
+ + +++ ++Fermilab does not have a strong opinion. Would prefer to go with +solution A. Bill agrees that solution A is a lot simpler and does the +job. +
++Proposed Resolution: Accept Solution A. +
++Issue 803 claims to make this issue moot. +
+ + + +Proposed resolution:
++
+ + + + + + +- +
+ ++In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace: +
+ ++ +class seed_seq +{ +public: + ... + template<class InputIterator, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> + seed_seq(InputIterator begin, InputIterator end, + size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits); + ... +}; ++and do a similar replacement in the member description between +p.3 and p.4. +
+- +
++In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the +member description between p.3 and p.4 replace: +
+ ++ +template<class InputIterator, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> + seed_seq(InputIterator begin, InputIterator end); +template<class InputIterator, size_t u> +seed_seq(InputIterator begin, InputIterator end, implementation-defined s); ++In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the +class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately +after the class seed_seq definition add: +
+ ++ +template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); ++In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: +
+ +++ ++The first constructor behaves as if it would provide an +integral constant expression u of type size_t of value +numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits. +
++The second constructor uses an implementation-defined mechanism +to provide an integral constant expression u of type size_t and +is called by the function make_seed_seq. +
++In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: +
+ +++ +template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); +++++where u is used to construct an object s of implementation-defined type. +
++Returns: seed_seq(begin, end, s); +
+
+783. thread::id reuse
+Section: 30.2.1.1 [thread.thread.id] Status: Ready + Submitter: Hans Boehm Date: 2008-02-01
+View all issues with Ready status.
+Discussion:
++The current working paper +(N2497, +integrated just before Bellevue) is +not completely clear whether a given thread::id value may be reused once +a thread has exited and has been joined or detached. Posix allows +thread ids (pthread_t values) to be reused in this case. Although it is +not completely clear whether this originally was the right decision, it +is clearly the established practice, and we believe it was always the +intent of the C++ threads API to follow Posix and allow this. Howard +Hinnant's example implementation implicitly relies on allowing reuse +of ids, since it uses Posix thread ids directly. +
+ ++It is important to be clear on this point, since it the reuse of thread +ids often requires extra care in client code, which would not be +necessary if thread ids were unique across all time. For example, a +hash table indexed by thread id may have to be careful not to associate +data values from an old thread with a new one that happens to reuse the +id. Simply removing the old entry after joining a thread may not be +sufficient, if it creates a visible window between the join and removal +during which a new thread with the same id could have been created and +added to the table. +
+ +[ +post Bellevue Peter adds: +]
+ + +++ + + ++There is a real issue with thread::id reuse, but I urge the LWG to +reconsider fixing this by disallowing reuse, rather than explicitly allowing +it. Dealing with thread id reuse is an incredibly painful exercise that +would just force the world to reimplement a non-conflicting thread::id over +and over. +
++In addition, it would be nice if a thread::id could be manipulated +atomically in a lock-free manner, as motivated by the recursive lock +example: +
+ ++http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html +
+Proposed resolution:
++Add a sentence to 30.2.1.1 [thread.thread.id]/p1: +
+ +++ + + + + ++An object of type
+thread::id
provides +a unique identifier for each thread of execution +and a single distinct value for all thread objects +that do not represent a thread of execution ([thread.threads.class]). +Each thread of execution has athread::id
+that is not equal to thethread::id
+of other threads of execution +and that is not equal to +thethread::id
ofstd::thread
objects +that do not represent threads of execution. +The library may reuse the value of athread::id
of a +terminated thread that can no longer be joined. +
+785. Random Number Requirements in TR1
+Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New + Submitter: John Maddock Date: 2008-01-15
+View all issues with New status.
+Discussion:
++Table 16 of TR1 requires that all Pseudo Random Number generators have a +
+ ++ +seed(integer-type s) ++member function that is equivalent to: +
+ ++ +mygen = Generator(s) ++But the generators xor_combine and discard_block have no such seed member, only the +
+ ++ +template <class Gen> +seed(Gen&); ++member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. +
+ ++So... is this a bug in TR1? +
+ +This is a real issue BTW, since the Boost implementation does adhere +to the requirements of Table 16, while at least one commercial +implementation does not and follows a strict adherence to sections +5.1.4.5 and 5.1.4.6 instead. +
+ +[ +Jens adds: +]
+ + ++Both engines do have the necessary +constructor, therefore the omission of the seed() member +functions appears to be an oversight. ++ + + +Proposed resolution:
++
+ + + + + +
+786. Thread library timed waits, UTC and monotonic clocks
+Section: X [datetime.system] Status: New + Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03
+View all issues with New status.
+Discussion:
++The draft C++0x thread library requires that the time points of type +system_time and returned by get_system_time() represent Coordinated +Universal Time (UTC) (section X [datetime.system]). This can lead to +surprising behavior when a library user performs a duration-based wait, +such as condition_variable::timed_wait(). A complete explanation of the +problem may be found in the +Rationale for the Monotonic Clock +section in POSIX, but in summary: +
+ ++
+ +- +Operations such as condition_variable::timed_wait() (and its POSIX +equivalent, pthread_cond_timedwait()) are specified using absolute times +to address the problem of spurious wakeups. +
+ +- +The typical use of the timed wait operations is to perform a relative +wait. This may be achieved by first calculating an absolute time as the +sum of the current time and the desired duration. In fact, the C++0x +thread library includes duration-based overloads of +condition_variable::timed_wait() that behave as if by calling the +corresponding absolute time overload with a time point value of +get_system_time() + rel_time. +
+ +- +A UTC clock may be affected by changes to the system time, such as +synchronization with an external source, leap seconds, or manual changes +to the clock. +
+ +- +Should the clock change during a timed wait operation, the actual +duration of the wait will not be the expected length. For example, a +user may intend a timed wait of one second duration but, due to an +adjustment of the system clock backwards by a minute, the wait instead +takes 61 seconds. +
++POSIX solves the problem by introducing a new monotonic clock, which is +unaffected by changes to the system time. When a condition variable is +initialized, the user may specify whether the monotonic clock is to be +used. (It is worth noting that on POSIX systems it is not possible to +use condition_variable::native_handle() to access this facility, since +the desired clock type must be specified during construction of the +condition variable object.) +
+ ++In the context of the C++0x thread library, there are added dimensions +to the problem due to the need to support platforms other than POSIX: +
+ ++
+ +- +Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. +
+ +- +Some environments do not have a monotonic clock, but do have a UTC clock. +
+ +- +The Microsoft Windows API's synchronization functions use relative +timeouts based on an implied monotonic clock. A program that switches +from the Windows API to the C++0x thread library will now find itself +susceptible to clock changes. +
++One possible minimal solution: +
+ ++
+ + + +- +Strike normative references to UTC and an epoch based on 1970-01-01. +
+ +- +Make the semantics of system_time and get_system_time() +implementation-defined (i.e standard library implementors may choose the +appropriate underlying clock based on the capabilities of the target +platform). +
+ +- +Add a non-normative note encouraging use of a monotonic clock. +
+ +- +Remove system_time::seconds_since_epoch(). +
+ +- +Change the constructor explicit system_time(time_t secs, nanoseconds ns += 0) to explicit system_time(nanoseconds ns). +
+Proposed resolution:
++
+ + + + + +
+787. complexity of binary_search
+Section: 25.3.3.4 [binary.search] Status: New + Submitter: Daniel Krügler Date: 2007-09-08
+View all issues with New status.
+Discussion:
++In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as +
+ ++At most log(last - first) + 2 comparisons. ++ ++This should be precised and brought in line with the nomenclature used for +lower_bound, upper_bound, and equal_range. +
+ ++All existing libraries I'm aware of, delegate to +lower_bound (+ one further comparison). Since +issue 384 +has now WP status, the resolution of #787 should +be brought in-line with 384 by changing the + 2 +to + O(1). +
+ + +Proposed resolution:
++Change 25.3.3.4 [binary.search]/3 +
+ ++Complexity: At most log2(last - first) ++ + + + + +2O(1) comparisons. +
+788. ambiguity in [istream.iterator]
+Section: 24.5.1 [istream.iterator] Status: New + Submitter: Martin Sebor Date: 2008-02-06
+View other active issues in [istream.iterator].
+View all other issues in [istream.iterator].
+View all issues with New status.
+Discussion:
++The description of how an istream_iterator object becomes an +end-of-stream iterator is a) ambiguous and b) out of date WRT +issue 468: +
+ ++istream_iterator reads (using operator>>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time ++ is used, the iterator reads and stores a value of T. If +the end of stream is reached (operator void*() on the stream returns +false), the iterator becomes equal to the end-of-stream iterator value. +The constructor with no arguments istream_iterator() always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of operator* on an +end of stream is not defined. For any other iterator value a const T& is +returned. The result of operator-> on an end of stream is not defined. +For any other iterator value a const T* is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that ++ operators are not equality preserving, +that is, i == j does not guarantee at all that ++i == ++j. Every time ++ +is used a new value is read. ++ ++istream::operator void*() returns null if istream::fail() is true, +otherwise non-null. istream::fail() returns true if failbit or +badbit is set in rdstate(). Reaching the end of stream doesn't +necessarily imply that failbit or badbit is set (e.g., after +extracting an int from stringstream("123") the stream object will +have reached the end of stream but fail() is false and operator +void*() will return a non-null value). +
+ ++Also I would prefer to be explicit about calling fail() here +(there is no operator void*() anymore.) +
+ + +Proposed resolution:
++Change 24.5.1 [istream.iterator]/1: +
+ ++istream_iterator reads (using operator>>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time ++ is used, the iterator reads and stores a value of T. If ++ + + + + +the end of stream is reachedthe iterator fails to read and store a value of T +(operator void*()fail() on the stream returns +falsetrue), the iterator becomes equal to the end-of-stream iterator value. +The constructor with no arguments istream_iterator() always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of operator* on an +end of stream is not defined. For any other iterator value a const T& is +returned. The result of operator-> on an end of stream is not defined. +For any other iterator value a const T* is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that ++ operators are not equality preserving, +that is, i == j does not guarantee at all that ++i == ++j. Every time ++ +is used a new value is read. +
+789. xor_combine_engine(result_type) should be explicit
+Section: 26.4.4.4 [rand.adapt.xor] Status: Ready + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.adapt.xor].
+View all issues with Ready status.
+Discussion:
++xor_combine_engine(result_type) should be explicit. (Obvious oversight.) +
+ +[ +Bellevue: +]
+ + ++Non-controversial. Bill is right, but Fermilab believes that this is +easy to use badly and hard to use right, and so it should be removed +entirely. Got into TR1 by well defined route, do we have permission to +remove stuff? Should probably check with Jens, as it is believed he is +the originator. Broad consensus that this is not a robust engine +adapter. ++ + +Proposed resolution:
++Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. +
++Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine. +
+ + + + + +
+792. piecewise_constant_distribution is undefined for a range with just one endpoint
+Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Ready + Submitter: P.J. Plauger Date: 2008-02-09
+View other active issues in [rand.dist.samp.pconst].
+View all other issues in [rand.dist.samp.pconst].
+View all issues with Ready status.
+Discussion:
++piecewise_constant_distribution is undefined for a range with just one +endpoint. (Probably should be the same as an empty range.) +
+ + +Proposed resolution:
++Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +
+ ++b) If firstB == lastB or the sequence w has the length zero, ++ + + + + +
+793. discrete_distribution missing constructor
+Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open + Submitter: P.J. Plauger Date: 2008-02-09
+View all other issues in [rand.dist.samp.discrete].
+View all issues with Open status.
+Discussion:
++discrete_distribution should have a constructor like: +
+ ++ +template<class _Fn> + discrete_distribution(result_type _Count, double _Low, double _High, + _Fn& _Func); ++(Makes it easier to fill a histogram with function vaues over a range.) +
+ +[ +Bellevue: +]
+ + ++How do you specify the function so that it does not return negative +values? If you do it is a bad construction. This requirement is already +there. Where in each bin does one evaluate the function? In the middle. +Need to revisit tomorrow. ++ + +Proposed resolution:
+ + + + + +
+794. piecewise_constant_distribution missing constructor
+Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New + Submitter: P.J. Plauger Date: 2008-02-09
+View other active issues in [rand.dist.samp.pconst].
+View all other issues in [rand.dist.samp.pconst].
+View all issues with New status.
+Discussion:
++piecewise_constant_distribution should have a constructor like: +
+ ++ +template<class _Fn> + piecewise_constant_distribution(size_t _Count, + _Ty _Low, _Ty _High, _Fn& _Func); ++(Makes it easier to fill a histogram with function vaues over a range. +The two (reference 793) make a sensible replacement for +general_pdf_distribution.) +
+ + +Proposed resolution:
+ + + + + +
+798. Refactoring of binders lead to interface breakage
+Section: D.8 [depr.lib.binders] Status: Ready + Submitter: Daniel Krügler Date: 2008-02-14
+View all other issues in [depr.lib.binders].
+View all issues with Ready status.
+Discussion:
++N2521 +and its earlier predecessors have moved the old binders from +[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming +of the template parameter names (Operation -> Fn). During this +renaming process the protected data member op was also renamed to +fn, which seems as an unnecessary interface breakage to me - even if +this user access point is probably rarely used. +
+ + +Proposed resolution:
++Change D.8.1 [depr.lib.binder.1st]: +
+ +++ +template <class Fn> +class binder1st + : public unary_function<typename Fn::second_argument_type, + typename Fn::result_type> { +protected: + Fn+ +fnop; + typename Fn::first_argument_type value; +public: + binder1st(const Fn& x, + const typename Fn::first_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::second_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::second_argument_type& x) const; +}; ++++-1- The constructor initializes
+fnop with x and value with y. ++-2- operator() returns
+fnop(value,x). ++Change D.8.3 [depr.lib.binder.2nd]: +
+ +++ + + + + + +template <class Fn> +class binder2nd + : public unary_function<typename Fn::first_argument_type, + typename Fn::result_type> { +protected: + Fn+ +fnop; + typename Fn::second_argument_type value; +public: + binder2nd(const Fn& x, + const typename Fn::second_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::first_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::first_argument_type& x) const; +}; ++++-1- The constructor initializes
+fnop with x and value with y. ++-2- operator() returns
+fnop(value,x). +
+800. Issues in 26.4.7.1 [rand.util.seedseq](6)
+Section: 26.4.7.1 [rand.util.seedseq] Status: Open + Submitter: Stephan Tolksdorf Date: 2008-02-18
+View other active issues in [rand.util.seedseq].
+View all other issues in [rand.util.seedseq].
+View all issues with Open status.
+Discussion:
++The for-loop in the algorithm specification has n iterations, where n is +defined to be end - begin, i.e. the number of supplied w-bit quantities. +Previous versions of this algorithm and the general logic behind it +suggest that this is an oversight and that in the context of the +for-loop n should be the number of full 32-bit quantities in b (rounded +upwards). If w is 64, the current algorithm throws away half of all bits +in b. If w is 16, the current algorithm sets half of all elements in v +to 0. +
+ ++There are two more minor issues: +
+ ++
+ +- +Strictly speaking end - begin is not defined since +InputIterator is not required to be a random access iterator. +
+- +Currently all integral types are allowed as input to the seed_seq +constructor, including bool. IMHO allowing bools unnecessarily +complicates the implementation without any real benefit to the user. +I'd suggest to exclude bools as input. +
+[ +Bellevue: +]
+ + ++Move to OPEN Bill will try to propose a resolution by the next meeting. ++ +[ +post Bellevue: Bill provided wording. +]
+ + ++This issue is made moot if 803 is accepted. +
+ + + +Proposed resolution:
++Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: +
+ +++ + + + + ++Effects: Constructs a seed_seq object by effectively concatenating the +low-order u bits of each of the elements of the supplied sequence [begin, +end) +in ascending order of significance to make a (possibly very large) unsigned +binary number b having a total of n bits, and then carrying out the +following +algorithm: +
+ ++for( v.clear(); n > 0; n -= 32 ) + v.push_back(b mod 232), b /= 232; +
+801. tuple and pair trivial members
+Section: 20.3 [tuple] Status: Open + Submitter: Lawrence Crowl Date: 2008-02-18
+View other active issues in [tuple].
+View all other issues in [tuple].
+View all issues with Open status.
+Discussion:
++Classes with trivial special member functions are inherently more +efficient than classes without such functions. This efficiency is +particularly pronounced on modern ABIs that can pass small classes +in registers. Examples include value classes such as complex numbers +and floating-point intervals. Perhaps more important, though, are +classes that are simple collections, like pair and tuple. When the +parameter types of these classes are trivial, the pairs and tuples +themselves can be trivial, leading to substantial performance wins. +
++The current working draft make specification of trivial functions +(where possible) much easer through defaulted and deleted functions. +As long as the semantics of defaulted and deleted functions match +the intended semantics, specification of defaulted and deleted +functions will yield more efficient programs. +
++There are at least two cases where specification of an explicitly +defaulted function may be desirable. +
++First, the std::pair template has a non-trivial default constructor, +which prevents static initialization of the pair even when the +types are statically initializable. Changing the definition to +
+ ++ +pair() = default; ++would enable such initialization. Unfortunately, the change is +not semantically neutral in that the current definition effectively +forces value initialization whereas the change would not value +initialize in some contexts. +
+ ++** Does the committee confirm that forced value initialization +was the intent? If not, does the committee wish to change the +behavior of std::pair in C++0x? +
++Second, the same default constructor issue applies to std::tuple. +Furthermore, the tuple copy constructor is current non-trivial, +which effectively prevents passing it in registers. To enable +passing tuples in registers, the copy constructor should be +make explicitly defaulted. The new declarations are: +
+ ++ +tuple() = default; +tuple(const tuple&) = default; ++This changes is not implementation neutral. In particular, it +prevents implementations based on pointers to the parameter +types. It does however, permit implementations using the +parameter types as bases. +
++** How does the committee wish to trade implementation +efficiency versus implementation flexibility? +
+ +[ +Bellevue: +]
+ + +++ + ++General agreement; the first half of the issue is NAD. +
++Before voting on the second half, it was agreed that a "Strongly Favor" +vote meant support for trivial tuples (assuming usual requirements met), +even at the expense of other desired qualities. A "Weakly Favor" vote +meant support only if not at the expense of other desired qualities. +
++Concensus: Go forward, but not at expense of other desired qualities. +
++It was agreed to Alisdair should fold this work in with his other +pair/tuple action items, above, and that issue 801 should be "open", but +tabled until Alisdair's proposals are disposed of. +
+Proposed resolution:
++
+ + + + + +
+803. Simplification of seed_seq::seq_seq
+Section: 26.4.7.1 [rand.util.seedseq] Status: Open + Submitter: Charles Karney Date: 2008-02-22
+View other active issues in [rand.util.seedseq].
+View all other issues in [rand.util.seedseq].
+View all issues with Open status.
+Discussion:
++seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq +object repacking the bits of supplied sequence [begin, end) into a +32-bit vector. +
++This repacking triggers several problems: +
++
+- +Distinctness of the output of seed_seq::generate required the +introduction of the initial "if (w < 32) v.push_back(n);" (Otherwise +the unsigned short vectors [1, 0] and [1] generate the same sequence.) +
+- +Portability demanded the introduction of the template parameter u. +(Otherwise some sequences could not be obtained on computers where no +integer types are exactly 32-bits wide.) +
+- +The description and algorithm have become unduly complicated. +
++I propose simplifying this seed_seq constructor to be "32-bit only". +Despite it's being simpler, there is NO loss of functionality (see +below). +
++Here's how the description would read +
+++ ++26.4.7.1 [rand.util.seedseq] Class seed_seq +
+ +++template<class InputIterator> + seed_seq(InputIterator begin, InputIterator end); +++++5 Requires: NO CHANGE +
++6 Effects: Constructs a seed_seq object by +
+++for (InputIterator s = begin; s != end; ++s) + v.push_back((*s) mod 2^32); +++Discussion: +
++The chief virtues here are simplicity, portability, and generality. +
++
+- +Simplicity -- compare the above specification with the +n2461 proposal. +
+- +Portability -- with iterator_traits<InputIterator>::value_type = +uint_least32_t the user is guaranteed to get the same behavior across +platforms. +
+- +Generality -- any behavior that the +n2461 +proposal can achieve can be +obtained with this simpler proposal (albeit with a shuffling of bits +in the input sequence). +
++Arguments (and counter-arguments) against making this change (and +retaining the +n2461 +behavior) are: +
++
+ +- +
++The user can pass an array of unsigned char and seed_seq will nicely + repack it. +
++ Response: So what? Consider the seed string "ABC". The + n2461 + proposal results in +
++v = { 0x3, 0x434241 }; ++while the simplified proposal yields +
++v = { 0x41, 0x42, 0x43 }; ++The results produced by seed_seq::generate with the two inputs are +different but nevertheless equivalently "mixed up" and this remains +true even if the seed string is long. +
+- +
++With long strings (e.g., with bit-length comparable to the number of + bits in the state), v is longer (by a factor of 4) with the simplified + proposal and seed_seq::generate will be slower. +
++Response: It's unlikely that the efficiency of seed_seq::generate will + be a big issue. If it is, the user is free to repack the seed vector + before constructing seed_seq. +
+- +
++A user can pass an array of 64-bit integers and all the bits will be + used. +
++ Response: Indeed. However, there are many instances in the + n2461 + where integers are silently coerced to a narrower width and this + should just be a case of the user needing to read the documentation. + The user can of course get equivalent behavior by repacking his seed + into 32-bit pieces. Furthermore, the unportability of the + n2461 + proposal with +
++unsigned long s[] = {1, 2, 3, 4}; +seed_seq q(s, s+4); ++ which typically results in v = {1, 2, 3, 4} on 32-bit machines and in +v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for + unsuspecting users. +
++Note: this proposal renders moot issues 782 and 800. +
+ +[ +Bellevue: +]
+ + ++Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. ++ + +Proposed resolution:
++Change 26.4.7.1 [rand.util.seedseq]: +
+ +++ + + + + +template<class InputIterator+, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> + seed_seq(InputIterator begin, InputIterator end); ++++-5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1) +such that iterator_traits<InputIterator>::value_type shall denote an integral type. +
++-6- Constructs a seed_seq object by
+rearranging some or all of the bits of the supplied sequence +[begin,end) of w-bit quantities into 32-bit units, as if by the following:++
+First extract the rightmost u bits from each of the n = end +- begin elements of the supplied sequence and concatenate all the +extracted bits to initialize a single (possibly very large) unsigned +binary number, b = ∑n-1i=0 (begin[i] +mod 2u) ˇ 2wˇi (in which the bits of each begin[i] +are treated as denoting an unsigned quantity). Then carry out +the following algorithm:+++v.clear(); +if ($w$ < 32) + v.push_back($n$); +for( ; $n$ > 0; --$n$) + v.push_back(b mod 232), b /= 232; ++++for (InputIterator s = begin; s != end; ++s) + v.push_back((*s) mod 232); ++
+804. Some problems with classes error_code/error_condition
+Section: 19.4 [syserr] Status: New + Submitter: Daniel Krügler Date: 2008-02-24
+View other active issues in [syserr].
+View all other issues in [syserr].
+View all issues with New status.
+Discussion:
++
+ + +- +
+ ++19.4.2.1 [syserr.errcode.overview]/1, class error_code and +19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses +declare an expository data member cat_: +
++const error_category& cat_; // exposition only ++which is used to define the semantics of several members. The decision +to use a member of reference type lead to several problems: +
++
+- +The classes are not (Copy)Assignable, which is probably not the intent. +
+- +The post conditions of all modifiers from +19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., +cannot be fulfilled. +
++The simple fix would be to replace the reference by a pointer member. +
+- +I would like to give the editorial remark that in both classes the +constrained operator= +overload (template with ErrorCodeEnum argument) makes in invalid +usage of std::enable_if: By using the default value for the second enable_if +parameter the return type would be defined to be void& even in otherwise +valid circumstances - this return type must be explicitly provided (In +error_condition the first declaration uses an explicit value, but of wrong +type). +
+ +- +The member function message throws clauses ( +19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and +19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", +although +they return a std::string by value, which might throw in out-of-memory +conditions (see related issue 771). +
+Proposed resolution:
++In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. +
+ +++ +virtual string message(int ev) const = 0; ++ ++++Returns: A string that describes the error condition denoted by ev. +
++
+Throws: Nothing.++In 19.4.2.1 [syserr.errcode.overview]/1, class error_code synopsis, modifiers section, +replace the current operator= overload by the following: +
+ +++ +template <class ErrorCodeEnum> + typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& + operator=(ErrorCodeEnum e); +++In the private section of the same class replace the current +data member cat_ definition by: +
+ ++const error_category+ +&* cat_; // exposition only ++In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read: +
+ +++ +error_code(); +++++
...
+ ++Postconditions: val_ == 0 and cat_ == &system_category. +
++Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read: +
+ +++ +error_code(int val, const error_category& cat); ++++...
++Postconditions: val_ == val and cat_ == &cat. +
++In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read: +
+ +++ +void assign(int val, const error_category& cat); +++++
...
+ ++Postconditions: val_ == val and cat_ == &cat. +
++In 19.4.2.3 [syserr.errcode.modifiers], change the operator= signature to read: +
+ +++ +template <class ErrorCodeEnum> + typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& + operator=(ErrorCodeEnum e); +++In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read: +
+ +++ +const error_category& category() const; +++++
...
+ ++Returns: *cat_. +
++In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +
+ +++ +string message() const; +++++
...
+ ++
+Throws: Nothing.++In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition +synopsis, constructors section, replace the template constructor +overload declaration by one with an added "::value" +
+ +++ +template <class ErrorConditionEnum> + error_condition(ErrorConditionEnum e, + typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type* = 0); +++In 19.4.3.1 [syserr.errcondition.overview]/1, class error_condition synopsis, +modifiers section, +replace the operator= overload declaration by: +
+ +++ +template<typename ErrorConditionEnum> + typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value,+error_codeerror_condition>::type & + operator=( ErrorConditionEnum e ); ++In the private section of the same class replace the current +data member cat_ definition by: +
+ ++ +const error_category&* cat_; // exposition only ++In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read: +
+ +++ +error_condition(); +++++
...
+ ++Postconditions: val_ == 0 and cat_ == &posix_category. +
++In the same section, change p. 5 to read: +
+ +++ +error_condition(int val, const error_category& cat); +++++
...
+ ++Postconditions: val_ == val and cat_ == &cat. +
++In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read: +
+ +++ +void assign(int val, const error_category& cat); +++++Postconditions: val_ == val and cat_ == &cat. +
++In the same section replace the current operator= overload declaration by: +
+ +++ +template <class ErrorConditionEnum> + typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type& + operator=(ErrorConditionEnum e); ++In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read: +
+ +++ +const error_category& category() const; +++++Returns: *cat_. +
++In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. +
+ +++ + + + + + + +string message() const; +++++
...
+ ++
+Throws: Nothing.+
+805. posix_error::posix_errno concerns
+Section: 19.4 [syserr] Status: New + Submitter: Jens Maurer Date: 2008-02-24
+View other active issues in [syserr].
+View all other issues in [syserr].
+View all issues with New status.
+Discussion:
++19.4 [syserr] +
+ ++ +namespace posix_error { + enum posix_errno { + address_family_not_supported, // EAFNOSUPPORT + ... ++should rather use the new scoped-enum facility (7.2 [dcl.enum]), +which would avoid the necessity for a new posix_error +namespace, if I understand correctly. +
+ +[ +Further discussion: +]
+ + +++ + ++See N2347, +Strongly Typed Enums, since renamed Scoped Enums. +
++Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. +
++Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed. +
++The wording for the Proposed resolution was provided by Beman Dawes. +
+Proposed resolution:
++Change System error support 19.4 [syserr] as indicated: +
+ ++ +namespace posix_error {+ enumposix_errnoclass errc { + address_family_not_supported, // EAFNOSUPPORT + ... + wrong_protocol_type, // EPROTOTYPE + }; +} // namespace posix_error+ +template <> struct is_error_condition_enum<posix_error::posix_errnoerrc> + : public true_type {} + +namespace posix_error {+ error_code make_error_code(posix_errnoerrc e); + error_condition make_error_condition(posix_errnoerrc e); +} // namespace posix_error++Change System error support 19.4 [syserr] : +
+ +++ +The is_error_code_enum and is_error_condition_enum templates may be +specialized for user-defined types to indicate that such a type is +eligible for class error_code and class error_condition automatic +conversions, respectively.++Change System error support 19.4 [syserr] and its subsections: +
+ +++ ++
+- +remove all occurrences of posix_error:: +
+- +change all instances of posix_errno to errc +
+- +change all instances of posix_category to generic_category +
+- +change all instances of get_posix_category to get_generic_category +
++Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: +
+ ++Remarks: The object's default_error_condition and equivalent virtual +functions shall behave as specified for the class error_category. The +object's name virtual function shall return a pointer to the string ++ +"POSIX""GENERIC". ++Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated: +
+ +++ +error_code make_error_code(+ +posix_errnoerrc e); ++Returns: error_code(static_cast<int>(e),+posixgeneric_category). ++Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated: +
+ +++ + + +error_condition make_error_condition(+ +posix_errnoerrc e); ++Returns: error_condition(static_cast<int>(e),+posixgeneric_category). +Rationale:
++
+ + + + + ++ + +Names Considered ++ + +portable ++Too non-specific. Did not wish to reserve such a common word in +namespace std. Not quite the right meaning, either. + ++ + +portable_error ++Too long. Explicit qualification is always required for scoped enums, so +a short name is desirable. Not quite the right meaning, either. May be +misleading because *_error in the std lib is usually an exception class +name. + ++ + +std_error ++Fairly short, yet explicit. But in fully qualified names like +std::std_error::not_enough_memory, the std_ would be unfortunate. Not +quite the right meaning, either. May be misleading because *_error in +the std lib is usually an exception class name. + ++ + +generic ++Short enough. The category could be generic_category. Fully qualified +names like std::generic::not_enough_memory read well. Reserving in +namespace std seems dicey. + ++ + +generic_error ++Longish. The category could be generic_category. Fully qualified names +like std::generic_error::not_enough_memory read well. Misleading because +*_error in the std lib is usually an exception class name. + ++ + +generic_err ++A bit less longish. The category could be generic_category. Fully +qualified names like std::generic_err::not_enough_memory read well. + ++ + +gen_err ++Shorter still. The category could be generic_category. Fully qualified +names like std::gen_err::not_enough_memory read well. + ++ + +generr ++Shorter still. The category could be generic_category. Fully qualified +names like std::generr::not_enough_memory read well. + ++ + +error ++Shorter still. The category could be generic_category. Fully qualified +names like std::error::not_enough_memory read well. Do we want to use +this general a name? + ++ + +err ++Shorter still. The category could be generic_category. Fully qualified +names like std::err::not_enough_memory read well. Although alone it +looks odd as a name, given the existing errno and namespace std names, +it seems fairly intuitive. +Problem: err is used throughout the standard library as an argument name +and in examples as a variable name; it seems too confusing to add yet +another use of the name. + ++ +errc ++Short enough. The "c" stands for "constant". The category could be +generic_category. Fully qualified names like +std::errc::not_enough_memory read well. Although alone it looks odd as a +name, given the existing errno and namespace std names, it seems fairly +intuitive. There are no uses of errc in the current C++ standard. + +
+806. unique_ptr::reset effects incorrect, too permissive
+Section: 20.6.11.2.5 [unique.ptr.single.modifiers] Status: New + Submitter: Peter Dimov Date: 2008-03-13
+View all issues with New status.
+Discussion:
++void unique_ptr::reset(T* p = 0) is currently specified as: +
+ ++Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). ++ ++There are two problems with this. One, if get() == 0 and p != 0, the +deleter is called with a NULL pointer, and this is probably not what's +intended (the destructor avoids calling the deleter with 0.) +
+ ++Two, the special check for get() == p is generally not needed and such a +situation usually indicates an error in the client code, which is being +masked. As a data point, boost::shared_ptr was changed to assert on such +self-resets in 2001 and there were no complaints. +
+ ++One might think that self-resets are necessary for operator= to work; it's specified to perform +
+ ++ +reset( u.release() ); ++and the self-assignment +
+ ++ +p = move(p); ++might appear to result in a self-reset. But it doesn't; the release() is +performed first, zeroing the stored pointer. In other words, p.reset( +q.release() ) works even when p and q are the same unique_ptr, and there +is no need to special-case p.reset( q.get() ) to work in a similar +scenario, as it definitely doesn't when p and q are separate. +
+ + + +Proposed resolution:
+ ++Change 20.6.11.2.5 [unique.ptr.single.modifiers]: +
+ +++ +void reset(T* p = 0); +++-4- Effects: If+p ==get() == 0 there are no effects. Otherwise get_deleter()(get()). ++Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: +
+ +++ + + + + + +void reset(T* p = 0); ++++...
++-2- Effects: If
+p ==get() == 0 there are no effects. Otherwise get_deleter()(get()). +
+807. tuple construction should not fail unless its element's construction fails
+Section: 20.3.1.2 [tuple.cnstr] Status: New + Submitter: Howard Hinnant Date: 2008-03-13
+View all issues with New status.
+Discussion:
++527 Added a throws clause to bind constructors. I believe the same throws clause +should be added to tuple except it ought to take into account move constructors as well. +
+ + +Proposed resolution:
++Add to 20.3.1.2 [tuple.cnstr]: +
+ +++ + + + + ++For each tuple constructor and assignment operator, an exception is thrown only if the construction +or assignment of one of the types in Types throws an exception. +
+
+808. [forward] incorrect redundant specification
+Section: 20.2.2 [forward] Status: New + Submitter: Jens Maurer Date: 2008-03-13
+View other active issues in [forward].
+View all other issues in [forward].
+View all issues with New status.
+Discussion:
++p4 (forward) says: +
++Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. ++ ++First of all, lvalue-ness and rvalue-ness are properties of an expression, +not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. +Second, the phrase says exactly what the core language wording says for +folding references in 14.3.1 [temp.arg.type]/p4 and for function return values +in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should +at most be a note with cross-references to those sections.) +
++The prose after the example talks about "forwarding as an int& (an lvalue)" etc. +In my opinion, this is a category error: "int&" is a type, "lvalue" is a +property of an expression, orthogonal to its type. (Btw, expressions cannot +have reference type, ever.) +
++Similar with move: +
++Return type: an rvalue. +++is just wrong and also redundant. +
+ + +Proposed resolution:
++Change 20.2.2 [forward] as indicated: +
+ +++ + + + + + +template <class T> T&& forward(typename identity<T>::type&& t); ++ +++ +...
++
+Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue.+...
++-7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor +as
+an int&& (an rvalue). In the second call to factory, A1 is deduced +as int&, so i is forwarded to A's constructor asan int& (an lvalue). +In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as +double&& (an rvalue). +template <class T> typename remove_reference<T>::type&& move(T&& t); ++ +++ +...
++
+Return type: an rvalue.+
+809. std::swap should be overloaded for array types
+Section: 25.2.3 [alg.swap] Status: New + Submitter: Niels Dekker Date: 2008-02-28
+View all other issues in [alg.swap].
+View all issues with New status.
+Discussion:
++For the sake of generic programming, the header
<algorithm>
should provide an +overload ofstd::swap
for array types: +template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); ++ + ++It became apparent to me that this overload is missing, when I considered how to write a swap +function for a generic wrapper class template. +(Actually I was thinking of Boost's value_initialized.) +Please look at the following template,
W
, and suppose that is intended to be a very +generic wrapper: +template<class T> class W { +public: + T data; +}; ++ClearlyW<T>
is CopyConstructible and CopyAssignable, and therefore +Swappable, wheneverT
is CopyConstructible and CopyAssignable. +Moreover,W<T>
is also Swappable whenT
is an array type +whose element type is CopyConstructible and CopyAssignable. +Still it is recommended to add a custom swap function template to such a class template, +for the sake of efficiency and exception safety. +(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing +swap.) +This function template is typically written as follows: +template<class T> void swap(W<T>& x, W<T>& y) { + using std::swap; + swap(x.data, y.data); +} ++Unfortunately, this will introduce an undesirable inconsistency, whenT
is an array. +For instance,W<std::string[8]>
is Swappable, but the current Standard does not +allow calling the custom swap function that was especially written forW
! +W<std::string[8]> w1, w2; // Two objects of a Swappable type. +std::swap(w1, w2); // Well-defined, but inefficient. +using std::swap; +swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!! ++ +W
'sswap
function would try to callstd::swap
for an array, +std::string[8]
, which is not supported by the Standard Library. +This issue is easily solved by providing an overload ofstd::swap
for array types. +This swap function should be implemented in terms of swapping the elements of the arrays, so that +it would be non-throwing for arrays whose element types have a non-throwing swap. + + ++Note that such an overload of
+ +std::swap
should also support multi-dimensional +arrays. Fortunately that isn't really an issue, because it would do so automatically, by +means of recursion. ++For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard +Library] Shouldn't std::swap be overloaded for C-style arrays? +
+ + +Proposed resolution:
++Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: +
++- T is Swappable if T is an array type whose element type is Swappable. +++Add the following to 25.2.3 [alg.swap]: +
+++ + + + + +template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); +++Requires: Type+T
shall be Swappable. ++Effects:+swap_ranges(a, a + N, b);
+
+810. Missing traits dependencies in operational semantics of extended manipulators
+Section: 27.6.4 [ext.manip] Status: New + Submitter: Daniel Krügler Date: 2008-03-01
+View other active issues in [ext.manip].
+View all other issues in [ext.manip].
+View all issues with New status.
+Discussion:
++The recent draft (as well as the original proposal n2072) uses an +operational semantic +for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses +
+ ++ +istreambuf_iterator<charT> ++and +
+ ++ +ostreambuf_iterator<charT> ++resp, instead of the iterator instances, with explicitly provided +traits argument (The operational semantic defined by f is also traits +dependent). This is an obvious oversight because both *stream_buf +c'tors expect a basic_streambuf<charT,traits> as argument. +
++The same problem occurs within the get_time and put_time semantic (p. +7 and p. 9) +of n2071 incorporated in N2521, where additional to the problem we +have an editorial issue in get_time (streambuf_iterator instead of +istreambuf_iterator). +
+ + +Proposed resolution:
++In 27.6.4 [ext.manip]/3 within function f replace the first line +
+ ++ +template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { + typedef istreambuf_iterator<charT, traits> Iter; + ... ++In 27.6.4 [ext.manip]/4 remove the first template charT parameter: +
+ ++ +template <class charT,class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); ++In 27.6.4 [ext.manip]/5 within function f replace the first line +
+ ++ +template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { + typedef ostreambuf_iterator<charT, traits> Iter; + ... ++In 27.6.4 [ext.manip]/7 within function f replace the first line +
+ ++ +template <class charT, class traits> +void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { + typedef istreambuf_iterator<charT, traits> Iter; + ... ++In 27.6.4 [ext.manip]/8 add const: +
+ ++ +template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); ++In 27.6.4 [ext.manip]/9 within function f replace the first line +
+ ++ +template <class charT, class traits> +void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { + typedef ostreambuf_iterator<charT, traits> Iter; + ... ++Add to the <iomanip> synopsis in 27.6 [iostream.format] +
+ ++ + + + + + +template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false); +template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); +template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt); +template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); +
+811. pair of pointers no longer works with literal 0
+Section: 20.2.3 [pairs] Status: New + Submitter: Doug Gregor Date: 2008-03-14
+View all other issues in [pairs].
+View all issues with New status.
+Discussion:
++ +#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} ++I just got a bug report about that, because it's valid C++03, but not +C++0x. The important realization, for me, is that the emplace +proposal---which made push_back variadic, causing the push_back(0) +issue---didn't cause this break in backward compatibility. The break +actually happened when we added this pair constructor as part of adding +rvalue references into the language, long before variadic templates or +emplace came along: +
+ ++ +template<class U, class V> pair(U&& x, V&& y); ++Now, concepts will address this issue by constraining that pair +constructor to only U's and V's that can properly construct "first" and +"second", e.g. (from +N2322): +
+ ++ + + +template<class U , class V > +requires Constructible<T1, U&&> && Constructible<T2, V&&> +pair(U&& x , V&& y ); +Proposed resolution:
++
+ + + + + +
+812. unsolicited multithreading considered harmful?
+Section: 25.3.1 [alg.sort] Status: New + Submitter: Paul McKenney Date: 2008-02-27
+View all issues with New status.
+Discussion:
++Multi-threading is a good thing, but unsolicited multi-threading can +potentially be harmful. For example, sort() performance might be +greatly increased via a multithreaded implementation. However, such +a multithreaded implementation could result in concurrent invocations +of the user-supplied comparator. This would in turn result in problems +given a caching comparator that might be written for complex sort keys. +Please note that this is not a theoretical issue, as multithreaded +implementations of sort() already exist. +
++Having a multithreaded sort() available is good, but it should not +be the default for programs that are not explicitly multithreaded. +Users should not be forced to deal with concurrency unless they have +asked for it. +
+ +[ +This may be covered by +N2410 +Thread-Safety in the Standard Library (Rev 1). +]
+ + + +Proposed resolution:
++
+ + + + + +
+813. "empty" undefined for shared_ptr
+Section: 20.6.12.2 [util.smartptr.shared] Status: New + Submitter: Matt Austern Date: 2008-02-26
+View other active issues in [util.smartptr.shared].
+View all other issues in [util.smartptr.shared].
+View all issues with New status.
+Discussion:
++Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr. +However, that term is nowhere defined. The closest thing we have to a +definition is that the default constructor creates an empty shared_ptr +and that a copy of a default-constructed shared_ptr is empty. Are any +other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What +are the properties of an empty shared_ptr? We should either clarify this +term or stop using it. +
+
+One reason it's not good enough to leave this term up to the reader's +intuition is that, in light of +N2351 +and issue 711, most readers' +intuitive understanding is likely to be wrong. Intuitively one might +expect that an empty shared_ptr is one that doesn't store a pointer, +but, whatever the definition is, that isn't it. + + +[ +Peter adds: +]
+ + +++ + ++Or, what is an "empty" shared_ptr? +
+ ++
+ +- +
+ ++Are any other shared_ptrs empty? +
++Yes. Whether a given shared_ptr instance is empty or not is (*) +completely specified by the last mutating operation on that instance. +Give me an example and I'll tell you whether the shared_ptr is empty or +not. +
++(*) If it isn't, this is a legitimate defect. ++- +
+ ++For example, is shared_ptr((T*) 0) empty? +
++No. If it were empty, it would have a use_count() of 0, whereas it is +specified to have an use_count() of 1. +
+- +
+ ++What are the properties of an empty shared_ptr? +
++The properties of an empty shared_ptr can be derived from the +specification. One example is that its destructor is a no-op. Another is +that its use_count() returns 0. I can enumerate the full list if you +really like. +
+- +
+ ++We should either clarify this term or stop using it. +
++I don't agree with the imperative tone +
++A clarification would be either a no-op - if it doesn't contradict the +existing wording - or a big mistake if it does. +
++I agree that a clarification that is formally a no-op may add value. +
+- +
++However, that term is nowhere defined. +
++Terms can be useful without a definition. Consider the following +simplistic example. We have a type X with the following operations +defined: +
++X x; +X x2(x); +X f(X x); +X g(X x1, X x2); ++A default-constructed value is green.
+ +
+A copy has the same color as the original.
+f(x) returns a red value if the argument is green, a green value otherwise.
+g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise. ++Given these definitions, you can determine the color of every instance +of type X, even if you have absolutely no idea what green and red mean. +
+ ++Green and red are "nowhere defined" and completely defined at the same time. +
++Alisdair's wording is fine. +
+Proposed resolution:
++Append the following sentance to 20.6.12.2 [util.smartptr.shared] +
++The+ + + + + +shared_ptr
class template stores a pointer, usually obtained +vianew
.shared_ptr
implements semantics of +shared ownership; the last remaining owner of the pointer is responsible for +destroying the object, or otherwise releasing the resources associated with +the stored pointer. Ashared_ptr
object that does not own +a pointer is said to be empty. +
+814. vector<bool>::swap(reference, reference) not defined
+Section: 23.2.7 [vector.bool] Status: New + Submitter: Alisdair Meredith Date: 2008-03-17
+View other active issues in [vector.bool].
+View all other issues in [vector.bool].
+View all issues with New status.
+Discussion:
++vector<bool>::swap(reference, reference) has no definition. +
+ + +Proposed resolution:
++
+ + + + + +
+815. std::function and reference_closure do not use perfect forwarding
+Section: 20.5.15.2.4 [func.wrap.func.inv] Status: New + Submitter: Alisdair Meredith Date: 2008-03-16
+View all issues with New status.
+Discussion:
++std::function and reference_closure should use "perfect forwarding" as +described in the rvalue core proposal. +
+ + +Proposed resolution:
++
+ + + + + +
+816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?
+Section: 20.5.11.1.3 [func.bind.bind] Status: New + Submitter: Stephan T. Lavavej Date: 2008-02-08
+View other active issues in [func.bind.bind].
+View all other issues in [func.bind.bind].
+View all issues with New status.
+Discussion:
++Library Issue 527 notes that bind(f, t1, ..., tN) +should be nofail when f, t1, ..., tN have nofail copy ctors. +
++However, no guarantees are provided for the copy ctor of the functor +returned by bind(). (It's guaranteed to have a copy ctor, which can +throw implementation-defined exceptions: bind() returns a forwarding +call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, +TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. +Everything without an exception-specification may throw +implementation-defined exceptions unless otherwise specified, C++03 +17.4.4.8/3.) +
++Should the nofail guarantee requested by Library Issue 527 be extended +to cover both calling bind() and copying the returned functor? +
+ +[ +Howard adds: +]
+ + ++tuple construction should probably have a similar guarantee. ++ + + +Proposed resolution:
++
+ + + + + +
+817. bind needs to be moved
+Section: 20.5.11.1.3 [func.bind.bind] Status: New + Submitter: Howard Hinnant Date: 2008-03-17
+View other active issues in [func.bind.bind].
+View all other issues in [func.bind.bind].
+View all issues with New status.
+Discussion:
++The functor retureed by bind() should have a move constructor that +requires only move construction of its contained functor and bound arguments. +That way move-only functors can be passed to objects such as thread. +
++This issue is related to issue 816. +
+ + +Proposed resolution:
++
+ + + + + +
+818. wording for memory ordering
+Section: 29.1 [atomics.order] Status: New + Submitter: Jens Maurer Date: 2008-03-22
+View all issues with New status.
+Discussion:
++29.1 [atomics.order] p1 says in the table that +
+ +++ ++
++ +Element Meaning ++ +memory_order_acq_rel +the operation has both acquire and release semantics ++To my naked eye, that seems to imply that even an atomic read has both +acquire and release semantics. +
+ ++Then, p1 says in the table: +
+ +++ ++
++ +Element Meaning ++ +memory_order_seq_cst +the operation has both acquire and release semantics, + and, in addition, has sequentially-consistent operation ordering ++So that seems to be "the same thing" as memory_order_acq_rel, with additional +constraints. +
+ ++I'm then reading p2, where it says: +
+ ++The memory_order_seq_cst operations that load a value are acquire operations +on the affected locations. The memory_order_seq_cst operations that store a value +are release operations on the affected locations. ++ ++That seems to imply that atomic reads only have acquire semantics. If that +is intended, does this also apply to memory_order_acq_rel and the individual +load/store operations as well? +
+ ++Also, the table in p1 contains phrases with "thus" that seem to indicate +consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in +normative text, for the fear of redundant or inconsistent specification with +the other normative text. +
+ ++Double-check 29.4.4 [atomics.types.operations] that each +operation clearly says whether it's a load or a store operation, or +both. (It could be clearer, IMO. Solution not in current proposed resolution.) +
+ ++29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in +1.10 [intro.multithread], it's just used in notes there. +
+ ++And why does 29.4.4 [atomics.types.operations] p9 for "load" say: +
+ + ++Requires: The order argument shall not be memory_order_acquire +nor memory_order_acq_rel. ++ ++(Since this is exactly the same restriction as for "store", it seems to be a typo.) +
+ ++And then: 29.4.4 [atomics.types.operations] p12: +
+ ++These operations are read-modify-write operations in the sense of the +"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the +evaluation that produced the input value synchronize with any evaluation +that reads the updated value. ++ ++This is redundant with 1.10 [intro.multithread], see above for the reasoning. +
+ + +Proposed resolution:
++Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of +1.7 [intro.memory]. +Rephrase the table in as follows (maybe don't use a table): +
+ +++ ++For memory_order_relaxed, no operation orders memory. +
+ ++For memory_order_release, memory_order_acq_rel, and memory_order_seq_cst, +a store operation performs a release operation on the affected memory location. +
+ ++For memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst, +a load operation performs an acquire operation on the affected memory location. +
++Rephrase 29.1 [atomics.order] p2: +
+ +++ +The memory_order_seq_cst operations that load a value are +acquire operations on the affected locations. The +memory_order_seq_cst operations that store a value are release +operations on the affected locations.+In addition, in a consistent +execution, tTheremust beis a single +total order S on all +memory_order_seq_cst operations, consistent with the happens before +order and modification orders for all affected locations, such that each +memory_order_seq_cst operation observes either the last preceding +modification according to this order S, or the result of an operation +that is not memory_order_seq_cst. [Note: Although it is not explicitly +required that S include locks, it can always be extended to an order +that does include lock and unlock operations, since the ordering between +those is already included in the happens before ordering. -- end note] ++Rephrase 29.4.4 [atomics.types.operations] p12 as: +
+ ++Effects: Atomically replaces the value pointed to by object or by +this with desired. Memory is affected according to the value of order. +These operations are read-modify-write operations+ +in the sense of the +"synchronizes with" definition(1.10 [intro.multithread]), so both such an operation and the +evaluation that produced the input value synchronize with any evaluation +that reads the updated value. ++Same in p15, p20, p22. +
+ + + + + + +
+819. rethrow_if_nested
+Section: 18.7.6 [except.nested] Status: New + Submitter: Alisdair Meredith Date: 2008-03-25
+View all issues with New status.
+Discussion:
++Looking at the wording I submitted for rethrow_if_nested, I don't think I +got it quite right. +
+ ++The current wording says: +
+ +++ +template <class E> void rethrow_if_nested(const E& e); +++++Effects: Calls e.rethrow_nested() only if e +is publicly derived from nested_exception. +
++This is trying to be a bit subtle, by requiring e (not E) to be publicly +derived from nested_exception the idea is that a dynamic_cast would be +required to be sure. Unfortunately, if e is dynamically but not statically +derived from nested_exception, e.rethrow_nested() is ill-formed. +
+ + +Proposed resolution:
+ + + + + +
+820. current_exception()'s interaction with throwing copy ctors
+Section: 18.7.5 [propagation] Status: New + Submitter: Stephan T. Lavavej Date: 2008-03-26
+View other active issues in [propagation].
+View all other issues in [propagation].
+View all issues with New status.
+Discussion:
++As of N2521, the Working Paper appears to be silent about what +current_exception() should do if it tries to copy the currently handled +exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the +function needs to allocate memory and the attempt fails, it returns an +exception_ptr object that refers to an instance of bad_alloc.", but +doesn't say anything about what should happen if memory allocation +succeeds but the actual copying fails. +
+ ++I see three alternatives: (1) return an exception_ptr object that refers +to an instance of some fixed exception type, (2) return an exception_ptr +object that refers to an instance of the copy ctor's thrown exception +(but if that has a throwing copy ctor, an infinite loop can occur), or +(3) call terminate(). +
+ ++I believe that terminate() is the most reasonable course of action, but +before we go implement that, I wanted to raise this issue. +
+ +[ +Peter's summary: +]
+ + +++ + ++The current practice is to not have throwing copy constructors in +exception classes, because this can lead to terminate() as described in +15.5.1 [except.terminate]. Thus calling terminate() in this situation seems +consistent and does not introduce any new problems. +
+ ++However, the resolution of core issue 475 may relax this requirement: +
+ ++The CWG agreed with the position that std::uncaught_exception() should +return false during the copy to the exception object and that std::terminate() +should not be called if that constructor exits with an exception. ++ ++Since throwing copy constructors will no longer call terminate(), option +(3) doesn't seem reasonable as it is deemed too drastic a response in a +recoverable situation. +
+ ++Option (2) cannot be adopted by itself, because a potential infinite +recursion will need to be terminated by one of the other options. +
+ +Proposed resolution:
++Add the following paragraph after 18.7.5 [propagation]/7: +
+ +++ + + + + + ++Returns (continued): If the attempt to copy the current exception +object throws an exception, the function returns an exception_ptr that +refers to the thrown exception or, if this is not possible, to an +instance of bad_exception. +
++[Note: The copy constructor of the thrown exception may also fail, so +the implementation is allowed to substitute a bad_exception to avoid +infinite recursion. -- end note.] +
+
+821. Minor cleanup : unique_ptr
+Section: 20.6.11.3.3 [unique.ptr.runtime.modifiers] Status: New + Submitter: Alisdair Meredith Date: 2008-03-30
+View all issues with New status.
+Discussion:
++Reading resolution of LWG issue 673 I noticed the following: +
+ +++ +void reset(+ +T*pointer p =0pointer()); ++-1- Requires: Does not accept pointer types which are convertible +to
+T*pointer (diagnostic +required). [Note: One implementation technique is to create a private +templated overload. -- end note] ++This could be cleaned up by mandating the overload as a public deleted +function. In addition, we should probably overload reset on nullptr_t +to be a stronger match than the deleted overload. Words... +
+ + +Proposed resolution:
++Add to class template definition in 20.6.11.3 [unique.ptr.runtime] +
+ +++ +// modifiers +T* release(); +void reset(T* p = 0); +void reset( nullptr_t ); +template< typename T > void reset( T ) = delete; +void swap(unique_ptr&& u); +++Update 20.6.11.3.3 [unique.ptr.runtime.modifiers] +
+ +++ +void reset(pointer p = pointer()); +void reset(nullptr_t); ++ ++
+-1- Requires: Does not accept pointer types which are convertible +to pointer (diagnostic +required). [Note: One implementation technique is to create a private +templated overload. -- end note]++Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). +
+...
+[ +Note this wording incorporates resolutions for 806 (New) and 673 (Ready). +]
+ + + + + + +
+822. Object with explicit copy constructor no longer CopyConstructible
+Section: 20.1.1 [utility.arg.requirements] Status: New + Submitter: James Kanze Date: 2008-04-01
+View other active issues in [utility.arg.requirements].
+View all other issues in [utility.arg.requirements].
+View all issues with New status.
+Discussion:
++I just noticed that the following program is legal in C++03, but +is forbidden in the current draft: +
+ ++ +#include <vector> +#include <iostream> + +class Toto +{ +public: + Toto() {} + explicit Toto( Toto const& ) {} +} ; + +int +main() +{ + std::vector< Toto > v( 10 ) ; + return 0 ; +} ++Is this change intentional? (And if so, what is the +justification? I wouldn't call such code good, but I don't see +any reason to break it unless we get something else in return.) +
+ + + +Proposed resolution:
++In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: +
+ +++ ++
++ +expression post-condition ++ +T t(rv) = rvt is equivalent to the value of rv before the construction ++ +... ++In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: +
+ +++ + + + + ++
++ +expression post-condition ++ +T t(u) = uthe value of u is unchanged and is equivalent to t ++ +... +
+823. identity<void> seems broken
+Section: 20.2.2 [forward] Status: New + Submitter: Walter Brown Date: 2008-04-09
+View other active issues in [forward].
+View all other issues in [forward].
+View all issues with New status.
+Discussion:
++N2588 seems to have added an operator() member function to the +identity<> helper in 20.2.2 [forward]. I believe this change makes it no +longer possible to instantiate identity<void>, as it would require +forming a reference-to-void type as this operator()'s parameter type. +
+ ++Suggested resolution: Specialize identity<void> so as not to require +the member function's presence. +
+ + +Proposed resolution:
++
+ + + + + +
+824. rvalue ref issue with basic_string inserter
+Section: 21.3.8.9 [string.io] Status: New + Submitter: Alisdair Meredith Date: 2008-04-10
+View all other issues in [string.io].
+View all issues with New status.
+Discussion:
++In the current working paper, the <string> header synopsis at the end of +21.2 [string.classes] lists a single operator<< overload +for basic_string. +
+ ++ +template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&& os, + const basic_string<charT,traits,Allocator>& str); ++The definition in 21.3.8.9 [string.io] lists two: +
+ ++ +template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>& os, + const basic_string<charT,traits,Allocator>& str); + +template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&& os, + const basic_string<charT,traits,Allocator>& str); ++I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two +signatures in 21.3.8.9 [string.io] should be deleted. +
+ + +Proposed resolution:
++
+ + + + + +
+825. Missing rvalues reference stream insert/extract operators?
+Section: 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8 +[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 +[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 +[re.submatch] Status: New + Submitter: Alisdair Meredith Date: 2008-04-10
+View all issues with New status.
+Discussion:
++Should the following use rvalues references to stream in insert/extract +operators? +
+ ++
+ + +- 19.4.2.1 [syserr.errcode.overview]
+- 20.6.12.2.8 [util.smartptr.shared.io]
+- 22.2.8 [facets.examples]
+- 23.3.5.3 [bitset.operators]
+- 26.3.6 [complex.ops]
+- Doubled signatures in 27.5 [stream.buffers] for character inserters +(ref 27.6.2.6.4 [ostream.inserters.character]) ++ definition 27.6.2.6.4 [ostream.inserters.character]
+- 28.9 [re.submatch]
+Proposed resolution:
++
+ + + + + +
+826. Equivalent of %'d, or rather, lack thereof?
+Section: 22.2.2.2 [locale.nm.put] Status: New + Submitter: Peter Dimov Date: 2008-04-07
+View all issues with New status.
+Discussion:
++In the spirit of printf vs iostream... +
+ ++POSIX printf says that %'d should insert grouping characters (and the +implication is that in the absence of ' no grouping characters are +inserted). The num_put facet, on the other hand, seems to always insert +grouping characters. Can this be considered a defect worth fixing for +C++0x? Maybe ios_base needs an additional flag? +
+ +[ +Pablo Halpern: +]
+ + ++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). ++ + +Proposed resolution:
++
+ + + + + +
+827. constexpr shared_ptr::shared_ptr()?
+Section: 20.6.12.2.1 [util.smartptr.shared.const] Status: New + Submitter: Peter Dimov Date: 2008-04-11
+View all other issues in [util.smartptr.shared.const].
+View all issues with New status.
+Discussion:
++Would anyone object to making the default constructor of shared_ptr (and +weak_ptr and enable_shared_from_this) constexpr? This would enable +static initialization for shared_ptr variables, eliminating another +unfair advantage of raw pointers. +
+ + +Proposed resolution:
++
+ + + + + +
+828. Static initialization for std::mutex?
+Section: 30.3.1.1 [thread.mutex.class] Status: New + Submitter: Peter Dimov Date: 2008-04-18
+View all issues with New status.
+Discussion:
++[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] +
++Currently std::mutex doesn't support static initialization. This is a +regression with respect to pthread_mutex_t, which does. I believe that +we should strive to eliminate such regressions in expressive power where +possible, both to ease migration and to not provide incentives to (or +force) people to forego the C++ primitives in favor of pthreads. +
+ + +Proposed resolution:
++
+ + + + + +
+829. current_exception wording unclear about exception type
+Section: 18.7.5 [propagation] Status: New + Submitter: Beman Dawes Date: 2008-04-20
+View other active issues in [propagation].
+View all other issues in [propagation].
+View all issues with New status.
+Discussion:
+Consider this code:
+ +++ +exception_ptr xp;+try {do_something(); } + +catch (const runtime_error& ) {xp = current_exception();} + +... + +rethrow_exception(xp);++Say
+ +do_something()
throws an exception object of type+range_error
. What is the type of the exception object thrown by+rethrow_exception(xp)
above? It must have a type ofrange_error
; +if it were of typeruntime_error
it still isn't possible to +propagate an exception and the exception_ptr/current_exception/rethrow_exception +machinery serves no useful purpose. ++Unfortunately, the current wording does not explicitly say that. Different +people read the current wording and come to different conclusions. While it may +be possible to deduce the correct type from the current wording, it would be +much clearer to come right out and explicitly say what the type of the referred +to exception is. +
+ +[ +Peter adds: +]
+ + +++ + + ++I don't like the proposed resolution of 829. The normative text is +unambiguous that the exception_ptr refers to the currently handled +exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the +exception that throw; would rethrow, see 15.1 [except.throw]/7. +
++A better way to address this is to simply add the non-normative example +in question as a clarification. The term currently handled exception +should be italicized and cross-referenced. A [Note: the currently +handled exception is the exception that a throw expression without an +operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option. +
+Proposed resolution:
+ ++After 18.7.5 [propagation] , paragraph 7, add the indicated text: +
+ +++ + + + + + +exception_ptr current_exception();+ ++++Returns:
+ +exception_ptr
object that refers +to the currently handled exception or a copy of the currently handled +exception, or a nullexception_ptr
object if no exception is being handled. If +the function needs to allocate memory and the attempt fails, it returns an +exception_ptr
object that refers to an instance ofbad_alloc
. +It is unspecified whether the return values of two successive calls to +current_exception
refer to the same exception object. +[Note: that is, it +is unspecified whethercurrent_exception
+creates a new copy each time it is called. +-- end note] ++Remarks: The type of the exception object +referred to by the returned
+ +exception_ptr
is the most-derived +type of the currently handled exception. ++Throws: nothing. +
+ +
+830. Incomplete list of char_traits specializations
+Section: 21.1 [char.traits] Status: New + Submitter: Dietmar Kühl Date: 2008-04-23
+View other active issues in [char.traits].
+View all other issues in [char.traits].
+View all issues with New status.
+Discussion:
++ Paragraph 4 of 21.1 [char.traits] mentions that this + section specifies two specializations (
+ +char_traits<char>
+ and (char_traits<wchar_t>
). However, there are actually + four specializations provided, i.e. in addition to the two above also +char_traits<char16_t>
andchar_traits<char32_t>
). + I guess this was just an oversight and there is nothing wrong with just + fixing this. +[ +Alisdair adds: +]
+ ++char_traits< char16/32_t > +should also be added to <ios_fwd> in 27.2 [iostream.forward], and all the specializations +taking a char_traits parameter in that header. ++ + +Proposed resolution:
++ Replace paragraph 4 of 21.1 [char.traits] by: +
+++ + + + + ++ This subclause specifies a struct template,
+char_traits<charT>
, + and four explicit specializations of it,char_traits<char>
, +char_traits<char16_t>
,char_traits<char32_t>
, and +char_traits<wchar_t>
, all of which appear in the header + <string> and satisfy the requirements below. +
+831. wrong type for not_eof()
+Section: 21.1.3 [char.traits.specializations] Status: New + Submitter: Dietmar Kühl Date: 2008-04-23
+View all other issues in [char.traits.specializations].
+View all issues with New status.
+Discussion:
++ In Table 56 (Traits requirements) the not_eof() member function + is using an argument of type e which denotes an object of + type
+X::int_type
. However, the specializations in + 21.1.3 [char.traits.specializations] all usechar_type
. + This would effectively mean that the argument type actually can't + represent EOF in the first place. I'm pretty sure that the type used + to beint_type
which is quite obviously the only sensible + argument. ++ This issue is close to being editorial. I suspect that the proposal + changing this section to include the specializations for
+ + +char16_t
+ andchar32_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
toint_type
. +
+832. Applying constexpr to System error support
+Section: 19.4 [syserr] Status: New + Submitter: Beman Dawes Date: 2008-05-14
+View other active issues in [syserr].
+View all other issues in [syserr].
+View all issues with New status.
+Discussion:
++Initialization of objects of class error_code +(19.4.2 [syserr.errcode]) and class +error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of +the new constexpr feature +[N2349] +of C++0x. Less code will need to be +generated for both library implementations and user programs when +manipulating constant objects of these types. +
+ ++This was not proposed originally because the constant expressions +proposal was moving into the standard at about the same time as the +Diagnostics Enhancements proposal +[N2241], +and it wasn't desirable to +make the later depend on the former. There were also technical concerns +as to how constexpr would apply to references. Those concerns are now +resolved; constexpr can't be used for references, and that fact is +reflected in the proposed resolution. +
+ ++Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements. +
+ ++LWG issue 804 is related in that it raises the question of whether the +exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class +error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. +While in the context of 804 that is arguably an editorial question, +presenting it as a pointer becomes more or less required with this +proposal, given constexpr does not play well with references. The +proposed resolution thus changes the private member to a pointer, which +also brings it in sync with real implementations. +
+ + +Proposed resolution:
++The proposed wording assumes the LWG 805 proposed wording has been +applied to the WP, resulting in the former posix_category being renamed +generic_category. If 805 has not been applied, the names in this +proposal must be adjusted accordingly. +
+ ++Change 19.4.1.1 [syserr.errcat.overview] Class +error_category overview error_category synopsis as +indicated: +
+ ++ +const error_category& get_generic_category();+const error_category& get_system_category();+ +staticextern const error_category&* const generic_category= get_generic_category(); +staticextern const error_category&* constnative_categorysystem_category= get_system_category(); ++Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +
+ +++ +extern const error_category+&* constget_generic_category(); ++
+ +Returns: A referencegeneric_category shall point +toana statically initialized object of a type derived from +class error_category. ++
+ +Remarks:The object's default_error_condition and equivalent virtual +functions shall behave as specified for the class error_category. The +object's name virtual function shall return a pointer to the string +"GENERIC". +extern const error_category+ +&* constget_system_category(); ++
+ +Returns: A referencesystem_category shall point +toana statically +initialized object of a type derived from class error_category. ++
+ +Remarks:The object's equivalent virtual functions shall behave as +specified for class error_category. The object's name virtual function +shall return a pointer to the string "system". The object's +default_error_condition virtual function shall behave as follows: ++If the argument ev corresponds to a POSIX errno value posv, the function +shall return error_condition(posv, generic_category). Otherwise, the +function shall return error_condition(ev, system_category). What +constitutes correspondence for any given operating system is +unspecified. [Note: The number of potential system error codes is large +and unbounded, and some may not correspond to any POSIX errno value. +Thus implementations are given latitude in determining correspondence. +-- end note] +
++Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: +
+ ++ +class error_code { +public: + ...; + constexpr error_code(int val, const error_category&* cat); + ... + void assign(int val, const error_category&* cat); + ... + const error_category&* category() const; + ... +private: + int val_; // exposition only + const error_category&* cat_; // exposition only ++Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: +
+ +++ +constexpr error_code(int val, const error_category+&* cat); ++Effects: Constructs an object of type error_code. +
++Postconditions: val_ == val and cat_ == cat. +
++Throws: Nothing. +
++Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: +
+ +++ +void assign(int val, const error_category+&* cat); ++Postconditions: val_ == val and cat_ == cat. +
++Throws: Nothing. +
++Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: +
+ +++ +const error_category+ +&* category() const; ++Returns: cat_. +
++Throws: Nothing. +
++Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview as indicated: +
+ +++ +class error_condition { +public: + ...; + constexpr error_condition(int val, const error_category+&* cat); + ... + void assign(int val, const error_category&* cat); + ... + const error_category&* category() const; + ... +private: + int val_; // exposition only + const error_category&* cat_; // exposition only ++Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: +
+ +++ +constexpr error_condition(int val, const error_category+&* cat); ++Effects: Constructs an object of type error_condition. +
++Postconditions: val_ == val and cat_ == cat. +
++Throws: Nothing. +
++Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: +
+ +++ +void assign(int val, const error_category+&* cat); ++Postconditions: val_ == val and cat_ == cat. +
++Throws: Nothing. +
++Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +
+ +++ +const error_category+&* category() const; ++Returns: cat_. +
++Throws: Nothing. +
++Throughout 19.4 [syserr] System error support, change "category()." to "category()->". +Appears approximately six times. +
+ ++[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, +paragraphs 2 and 4, change "category.equivalent(" to +"category()->equivalent(". +
+ + + + + +
+833. Freestanding implementations header list needs review for C++0x
+Section: 17.4.1.3 [compliance] Status: New + Submitter: Beman Dawes Date: 2008-05-14
+View all issues with New status.
+Discussion:
++Once the C++0x standard library is feature complete, the LWG needs to +review 17.4.1.3 [compliance] Freestanding implementations header list to +ensure it reflects LWG consensus. +
+ + +Proposed resolution:
+ + + + + +
+834. Unique_ptr::pointer requirements underspecified
+Section: 20.6.11.2 [unique.ptr.single] Status: New + Submitter: Daniel Krügler Date: 2008-05-14
+View all issues with New status.
+Discussion:
++Issue 673 (including recent updates by 821) proposes a useful +extension point for unique_ptr by granting support for an optional +deleter_type::pointer to act as pointer-like replacement for element_type* +(In the following: pointer). +
++Unfortunately no requirements are specified for the type pointer which has +impact on at least two key features of unique_ptr: +
+ ++
+ +- Operational fail-safety.
+- (Well-)Definedness of expressions.
++Unique_ptr specification makes great efforts to require that essentially *all* +operations cannot throw and therefore adds proper wording to the affected +operations of the deleter as well. If user-provided pointer-emulating types +("smart pointers") will be allowed, either *all* throw-nothing clauses have to +be replaced by weaker "An exception is thrown only if pointer's {op} throws +an exception"-clauses or it has to be said explicitly that all used +operations of +pointer are required *not* to throw. I understand the main focus of unique_ptr +to be as near as possible to the advantages of native pointers which cannot +fail and thus strongly favor the second choice. Also, the alternative position +would make it much harder to write safe and simple template code for +unique_ptr. Additionally, I assume that a general statement need to be given +that all of the expressions of pointer used to define semantics are required to +be well-formed and well-defined (also as back-end for 762). +
+ + +Proposed resolution:
++Add the following sentence just at the end of the newly proposed +20.6.11.2 [unique.ptr.single]/p. 3: +
+ ++unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well +defined behavior, and shall not throw exceptions. ++ + + + + +
+835. tying two streams together (correction to DR 581)
+Section: 27.4.4.2 [basic.ios.members] Status: New + Submitter: Martin Sebor Date: 2008-05-17
+View other active issues in [basic.ios.members].
+View all other issues in [basic.ios.members].
+View all issues with New status.
+Discussion:
++ +The fix for +issue 581, +now integrated into the working paper, overlooks a couple of minor +problems. + +
++ +First, being an unformatted function once again,
+flush()
+is required to create a sentry object whose constructor must, among +other things, flush the tied stream. When two streams are tied +together, either directly or through another intermediate stream +object, flushing one will also cause a call toflush()
on +the other tied stream(s) and vice versa, ad infinitum. The program +below demonstrates the problem. + ++ +Second, as Bo Persson notes in his +comp.lang.c++.moderated post, +for streams with the
+unitbuf
flag set such +asstd::stderr
, the destructor of the sentry object will +again callflush()
. This seems to create an infinite +recursion forstd::cerr << std::flush;
+ +++ +#include <iostream> + +int main () +{ + std::cout.tie (&std::cerr); + std::cerr.tie (&std::cout); + std::cout << "cout\n"; + std::cerr << "cerr\n"; +} ++Proposed resolution:
++ +I think an easy way to plug the first hole is to add a requires clause +to
+ostream::tie(ostream *tiestr)
requiring the this +pointer not be equal to any pointer on the list starting +withtiestr->tie()
+throughtiestr()->tie()->tie()
and so on. I am not +proposing that we require implementations to traverse this list, +although I think we could since the list is unlikely to be very long. + ++ +Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following +text: + +
++ +Requires: If+(tiestr != 0)
is +true,tiestr
must not be reachable by traversing the +linked list of tied stream objects starting +fromtiestr->tie()
. + ++ +In addition, to prevent the infinite recursion that Bo writes about in +his comp.lang.c++.moderated post, I propose to change +27.6.2.4 [ostream::sentry], p2 like so: + +
++ +If+ + + + +((os.flags() & ios_base::unitbuf) && +!uncaught_exception())
is true, +callsos.flush()os.rdbuf()->pubsync()
. + +
+836. + effects of
+money_base::space
and +money_base::none
onmoney_get
+Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New + Submitter: Martin Sebor Date: 2008-05-17
+View other active issues in [locale.money.get.virtuals].
+View all other issues in [locale.money.get.virtuals].
+View all issues with New status.
+Discussion:
++ +In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: + +
++ +Where+space
ornone
appears in the format +pattern, except at the end, optional white space (as recognized +byct.is
) is consumed after any required space. + ++ +This requirement can be (and has been) interpreted two mutually +exclusive ways by different readers. One possible interpretation +is that: + +
++++
+- + +where
+money_base::space
appears in the format, at least +one space is required, and + +- + +where
+money_base::none
appears in the format, space is +allowed but not required. + ++ +The other is that: + +
++ +where either+ + +money_base::space
ormoney_base::none
appears in the format, white space is optional. + +Proposed resolution:
++ +I propose to change the text to make it clear that the first +interpretation is intended, that is, to make following change to +22.2.6.1.2 [locale.money.get.virtuals], p2: + +
+ ++ +When+ + + + +money_base::space
+ormoney_base::none
appears as the last +element in the format pattern,except at the end, optional +white space (as recognized byno white space is consumed. Otherwise, +wherect.is
) is consumed after +any required space.money_base::space
appears in any of the initial +elements of the format pattern, at least one white space character is +required. Wheremoney_base::none
appears in any of the +initial elements of the format pattern, white space is allowed but not +required. In either case, any required followed by all optional white +space (as recognized byct.is()
) is consumed. +If(str.flags() & str.showbase)
isfalse
, ... + +
+837. +
+basic_ios::copyfmt()
overly loosely specified +Section: 27.4.4.2 [basic.ios.members] Status: New + Submitter: Martin Sebor Date: 2008-05-17
+View other active issues in [basic.ios.members].
+View all other issues in [basic.ios.members].
+View all issues with New status.
+Discussion:
++ +The
+basic_ios::copyfmt()
member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: + ++ +Effects: If+(this == &rhs)
does +nothing. Otherwise assigns to the member objects of*this
+the corresponding member objects ofrhs
, except that + ++
+- + +
+rdstate()
andrdbuf()
are left unchanged; + +- + +
+exceptions()
is altered last by +callingexceptions(rhs.except)
+ +- + +the contents of arrays pointed at by
+pword
+andiword
are copied not the pointers themselves + ++ +Since the rest of the text doesn't specify what the member objects +of
+ + +basic_ios
are this seems a little too loose. + +Proposed resolution:
++ +I propose to tighten things up by adding a Postcondition clause +to the function like so: + +
++ Postconditions: + +++ +
++ ++ copyfmt()
postconditions+ + + +Element +Value ++ ++ rdbuf()
unchanged ++ ++ tie()
+ rhs.tie()
+ ++ rdstate()
unchanged ++ ++ exceptions()
+ rhs.exceptions()
+ ++ flags()
+ rhs.flags()
+ ++ width()
+ rhs.width()
+ ++ precision()
+ rhs.precision()
+ ++ fill()
+ rhs.fill()
+ + ++ getloc()
+ rhs.getloc()
+ +The format of the table follows Table 117 (as +of N2588):
+basic_ios::init()
+effects. + ++ +The intent of the new table is not to impose any new requirements or +change existing ones, just to be more explicit about what I believe is +already there. + +
+ + + + +
+838. + can an end-of-stream iterator become a non-end-of-stream one? +
+Section: 24.5.1 [istream.iterator] Status: New + Submitter: Martin Sebor Date: 2008-05-17
+View other active issues in [istream.iterator].
+View all other issues in [istream.iterator].
+View all issues with New status.
+Discussion:
++ +From message c++std-lib-20003... + +
++ +The description of
+istream_iterator
in +24.5.1 [istream.iterator], p1 specifies that objects of the +class become the end-of-stream (EOS) iterators under the +following condition (see also issue 836 another problem +with this paragraph): + ++ +If the end of stream is reached (+operator void*()
on the +stream returnsfalse
), the iterator becomes equal to +the end-of-stream iterator value. + ++ +One possible implementation approach that has been used in practice is +for the iterator to set its
+in_stream
pointer to 0 when +it reaches the end of the stream, just like the default ctor does on +initialization. The problem with this approach is that +the Effects clause foroperator++()
says the +iterator unconditionally extracts the next value from the stream by +evaluating*in_stream >> value
, without checking +for(in_stream == 0)
. + ++ +Conformance to the requirement outlined in the Effects clause +can easily be verified in programs by setting
+eofbit
+orfailbit
inexceptions()
of the associated +stream and attempting to iterate past the end of the stream: each +past-the-end access should trigger an exception. This suggests that +some other, more elaborate technique might be intended. + ++ +Another approach, one that allows
+operator++()
to attempt +to extract the value even for EOS iterators (just as long +asin_stream
is non-0) is for the iterator to maintain a +flag indicating whether it has reached the end of the stream. This +technique would satisfy the presumed requirement implied by +the Effects clause mentioned above, but it isn't supported by +the exposition-only members of the class (no such flag is shown). This +approach is also found in existing practice. + ++ +The inconsistency between existing implementations raises the question +of whether the intent of the specification is that a non-EOS iterator +that has reached the EOS become a non-EOS one again after the +stream's
+eofbit
flag has been cleared? That is, are the +assertions in the program below expected to pass? + +++sstream strm ("1 "); + istream_iterator eos; + istream_iterator it (strm); + int i; + i = *it++ + assert (it == eos); + strm.clear (); + strm << "2 3 "; + assert (it != eos); + i = *++it; + assert (3 == i); +++ +Or is it intended that once an iterator becomes EOS it stays EOS until +the end of its lifetime? + +
+ + +Proposed resolution:
++ +The discussion of this issue on the reflector suggests that the intent +of the standard is for an
+istreambuf_iterator
that has +reached the EOS to remain in the EOS state until the end of its +lifetime. Implementations that permit EOS iterators to return to a +non-EOS state may only do so as an extension, and only as a result of +callingistream_iterator
member functions on EOS +iterators whose behavior is in this case undefined. + ++ +To this end we propose to change 24.5.1 [istream.iterator], p1, +as follows: + +
++ +The result of operator-> on an end-of-stream +is not defined. For any other iterator value a+const T*
+is returned. Invokingoperator++()
on +an end-of-stream iterator is undefined. It is impossible +to store things into istream iterators... + ++ +Add pre/postconditions to the member function descriptions of
+istream_iterator
like so: + ++ ++ + + + +istream_iterator();+ +Effects: Constructs the end-of-stream iterator.
+Postcondition:in_stream == 0
. + +istream_iterator(istream_type &s);+ +Effects: Initializesin_stream
with &s. value +may be initialized during construction or the first time it is +referenced.
+Postcondition:in_stream == &s
. + +istream_iterator(const istream_iterator &x);+ +Effects: Constructs a copy ofx
.
+Postcondition:in_stream == x.in_stream
. + +istream_iterator& operator++();+ +Requires:in_stream != 0
.
+Effects:*in_stream >> value
. + +istream_iterator& operator++(int);+ +Requires:in_stream != 0
.
+Effects: ++istream_iterator tmp (*this); +*in_stream >> value; +return tmp; ++