From 449c480110f6c57085db9c005127052731a97395 Mon Sep 17 00:00:00 2001
From: Paolo Carlini Reference ISO/IEC IS 14882:1998(E) Also see:linear_congruential
engine and seed with it.
-
Doc. no.
-N2091=06-0161
+N2130=06-0200
Date:
-2006-09-08
+2006-11-03
Project:
@@ -23,7 +23,7 @@ del {background-color:#FFFFA0}
Howard Hinnant <howard.hinnant@gmail.com>
C++ Standard Library Active Issues List (Revision R44)
+C++ Standard Library Active Issues List (Revision R45)
@@ -91,6 +91,16 @@ del {background-color:#FFFFA0}
directory as the issues list files.
+[Pre-Portland] A relevant newsgroup post: +
+ ++The current proposed resolution of issue #309 +(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is +unacceptable. I write commerical software and coding around this +makes my code ugly, non-intuitive, and requires comments referring +people to this very issue. Following is the full explanation of my +experience. +
++In the course of writing software for commercial use, I constructed +std::ifstream's based on user-supplied pathnames on typical POSIX +systems. +
++It was expected that some files that opened successfully might not read +successfully -- such as a pathname which actually refered to a +directory. Intuitively, I expected the streambuffer underflow() code +to throw an exception in this situation, and recent implementations of +libstdc++'s basic_filebuf do just that (as well as many of my own +custom streambufs). +
++I also intuitively expected that the istream code would convert these +exceptions to the "badbit' set on the stream object, because I had not +requested exceptions. I refer to 27.6.1.1. P4. +
++However, this was not the case on at least two implementations -- if +the first thing I did with an istream was call operator>>( T& ) for T +among the basic arithmetic types and std::string. Looking further I +found that the sentry's constructor was invoking the exception when it +pre-scanned for whitespace, and the extractor function (operator>>()) +was not catching exceptions in this situation. +
++So, I was in a situation where setting 'noskipws' would change the +istream's behavior even though no characters (whitespace or not) could +ever be successfully read. +
++Also, calling .peek() on the istream before calling the extractor() +changed the behavior (.peek() had the effect of setting the badbit +ahead of time). +
++I found this all to be so inconsistent and inconvenient for me and my +code design, that I filed a bugzilla entry for libstdc++. I was then +told that the bug cannot be fixed until issue #309 is resolved by the +committee. +
+Proposed resolution:
Rationale:
The LWG agrees there is minor variation between implementations, @@ -1530,7 +1595,7 @@ In case of failure, the function calls setstate(failbit) or badbit is set, so using !fail(), rather than good(), satisfies this goal.
Section: 22.2.1.5 [lib.locale.codecvt.byname] Status: Open Submitter: Martin Sebor Date: 30 Aug 2002
+Section: 22.2.1.5 [lib.locale.codecvt.byname] Status: Open Submitter: Martin Sebor Date: 30 Aug 2002
It seems that the descriptions of codecvt do_in() and do_out() leave sufficient room for interpretation so that two implementations of @@ -4182,122 +4247,6 @@ facet, but several also need to use a codecvt facet and we don't say so. Berlin: Bill to provide wording. ]
Section: TR1 5.1.1 [tr.rand.req] Status: Ready Submitter: Walter Brown Date: 3 Jul 2005
--In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, -g is an ... object returning values of unsigned integral type ..." -
-Proposed resolution:
--In 5.1.1 [tr.rand.req], Paragraph 2 replace -
- --... s is a value of integral type, g is an lvalue of a type other than X that -defines a zero-argument function object returning values of- -unsigned integraltype -unsigned long int, -... -
-In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) -
- --creates an engine with the initial internal state -determined by static_cast<unsigned long>(s) -- -
[ -Mont Tremblant: Both s and g should be unsigned long. -This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. -]
- -[ -Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved -to Ready. -]
- -Rationale:
--Jens: Just requiring X(unsigned long) still makes it possible -for an evil library writer to also supply a X(int) that does something -unexpected. The wording above requires that X(s) always performs -as if X(unsigned long) would have been called. I believe that is -sufficient and implements our intentions from Mont Tremblant. I -see no additional use in actually requiring a X(unsigned long) -signature. u.seed(s) is covered by its reference to X(s), same -arguments. -
-Section: TR1 5.1.4.4 [tr.rand.eng.sub1] Status: Ready Submitter: Walter Brown Date: 3 Jul 2005
--Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine -is to be seeded given a single unsigned long. This algorithm is seriously -flawed in the case where the engine parameter w (also known as word_size) -exceeds 31 [bits]. The key part of the paragraph reads: -
--sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 --
-and so forth. -
--Since the specified linear congruential engine, lcg, delivers numbers with -a maximum of 2147483563 (just a shade under 31 bits), then when w is, for -example, 48, each of the x(i) will be less than 2**-17. The consequence -is that roughly the first 400 numbers delivered will be conspicuously -close to either zero or one. -
--Unfortunately, this is not an innocuous flaw: One of the predefined engines -in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit -this poor behavior, while the original N1378 proposal states that these -pre-defined engines are intended to be of "known good properties." -
-Proposed resolution:
--In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for -void seed(unsigned long value = 19780503) by -
- --Effects: If value == 0, sets value to 19780503. In any -case,- -with a linear congruential generator lcg(i) having parameters -mlcg = 2147483563, alcg = 40014, -clcg = 0, and lcg(0) = value,-sets carry(-1) and x(-r) … x(-1) -as if executing - -- --linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value); -seed(lcg); -to (lcg(1) · 2-w) mod 1 -… (lcg(r) · 2-w) mod 1, -respectively. If x(-1) == 0, sets carry(-1) = 2-w, -else sets carry(-1) = 0.-
[ -Jens provided revised wording post Mont Tremblant. -]
- -[ -Berlin: N1932 adopts the originally-proposed resolution of the issue. -Jens's supplied wording is a clearer description of what is -intended. Moved to Ready. -]
- -Rationale:
--Jens: I'm using an explicit type here, because fixing the -prose would probably not qualify for the (with issue 504 even -stricter) requirements we have for seed(Gen&). -
-Section: TR1 5.1.2 [tr.rand.synopsis] Status: Open Submitter: Walter Brown Date: 3 Jul 2005
To accompany the concept of a pseudo-random number engine as defined in Table 17, @@ -4354,125 +4303,19 @@ feature. ]
Section: TR1 5.1.4.4 [tr.rand.eng.sub1] Status: Ready Submitter: Walter Brown Date: 3 Jul 2005
--Paragraph 6 says: -
--... obtained by successive invocations of g, ... --
-We recommend instead: -
--... obtained by taking successive invocations of g mod 2**32, ... --
-as the context seems to require only 32-bit quantities be used here. -
-Proposed resolution:
--Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. -
-Section: TR1 6.3 [tr.hash] Status: Review Submitter: Matt Austern Date: 3 Jul 2005
+Section: TR1 6.3 [tr.hash] Status: Open Submitter: Matt Austern Date: 3 Jul 2005
Issue 371 deals with stability of multiset/multimap under insert and erase (i.e. do they preserve the relative order in ranges of equal elements). The same issue applies to unordered_multiset and unordered_multimap.
Proposed resolution:
--
-Section: TR1 3.6 [tr.func.bind] Status: Tentatively Ready Submitter: Pete Becker Date: 3 Jul 2005
--In the original proposal for binders, the return type of bind() when -called with a pointer to member data as it's callable object was -defined to be mem_fn(ptr); when Peter Dimov and I unified the -descriptions of the TR1 function objects we hoisted the descriptions -of return types into the INVOKE pseudo-function and into result_of. -Unfortunately, we left pointer to member data out of result_of, so -bind doesn't have any specified behavior when called with a pointer -to member data. -
-Proposed resolution:
-[ -Pete and Peter will provide wording. -]
- --In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2: -
-[ -Peter provided wording. +Moved to open (from review): There is no resolution. ]
-Section: TR1 2.1.2 [tr.util.refwrp.refwrp] Status: Ready Submitter: Pete Becker Date: 3 Jul 2005
--2.1.2/3, second bullet item currently says that reference_wrapper<T> is -derived from unary_function<T, R> if T is: -
--a pointer to member function type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return type of the pointer to member function; --
-The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member -function. It should be a pointer to the class that T is a pointer to member of. -Like this: -
--a pointer to a member function R T0::f() cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* --
-Similarly, bullet item 2 in 2.1.2/4 should be: -
--a pointer to a member function R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* --
Proposed resolution:
- --Change bullet item 2 in 2.1.2/3: -
- ---
-- -a pointer to member function
-type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return -type of the pointer to member functionR T0::f() cv -(where cv represents the member function's cv-qualifiers); -the type T1 is cv T0* -
-Change bullet item 2 in 2.1.2/4:
- ----
-- -a pointer to member function
-with cv-qualifier cv and taking one argument -of type T2; the type T1 is cv T* and -R is the return type of the pointer to member function-R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -
Section: TR1 6.1 [tr.tuple] Status: Open Submitter: Andy Koenig Date: 3 Jul 2005
@@ -4484,7 +4327,7 @@ Berlin: Doug to provide wording.
Proposed resolution:
Section: TR1 7 [tr.re] Status: New Submitter: Eric Niebler Date: 1 Jul 2005
+Section: TR1 7 [tr.re] Status: Open Submitter: Eric Niebler Date: 1 Jul 2005
A problem with TR1 regex is currently being discussed on the Boost developers list. It involves the handling of case-insensitive matching @@ -4596,9 +4439,14 @@ whether the next character pair is a valid digraph in the current locale. Hoping this doesn't make this even more complex that it was already,
+[ +Portland: Alisdair: Detect as invalid, throw an exception. +Pete: Possible general problem with case insensitive ranges. +]
+Proposed resolution:
Section: TR1 7 [tr.re] Status: New Submitter: Eric Niebler Date: 1 Jul 2005
+Section: TR1 7 [tr.re] Status: Open Submitter: Eric Niebler Date: 1 Jul 2005
This defect is also being discussed on the Boost developers list. The full discussion can be found here: @@ -4942,37 +4790,7 @@ Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. ]
Section: 21.3 [lib.basic.string] Status: Ready Submitter: Matt Austern Date: 15 Nov 2005
-Issue 69, which was incorporated into C++03, mandated - that the elements of a vector must be stored in contiguous memory. - Should the same also apply to basic_string?
- -We almost require contiguity already. Clause 23.3.4 [lib.multiset] - defines operator[] as data()[pos]. What's missing - is a similar guarantee if we access the string's elements via the - iterator interface.
- -Given the existence of data(), and the definition of - operator[] and at in terms of data, - I don't believe it's possible to write a useful and standard- - conforming basic_string that isn't contiguous. I'm not - aware of any non-contiguous implementation. We should just require - it. -
-Proposed resolution:
-Add the following text to the end of 21.3 [lib.basic.string], -paragraph 2.
- ---The characters in a string are stored contiguously, meaning that if - s is a basic_string<charT, Allocator>, then - it obeys the identity - &*(s.begin() + n) == &*s.begin() + n - for all 0 <= n < s.size(). -
-
Section: 27.6.1.3 [lib.istream.unformatted] Status: Ready Submitter: Martin Sebor Date: 23 Nov 2005
+Section: 27.6.1.3 [lib.istream.unformatted] Status: Review Submitter: Martin Sebor Date: 23 Nov 2005
The array forms of unformatted input functions don't seem to have well-defined semantics for zero-element arrays in a couple of cases. The affected ones @@ -4993,6 +4811,17 @@ I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read:
+Change 27.6.1.3, p9: +
+ ++If the function stores no characters, it calls setstate(failbit) (which +may throw ios_base::failure (27.4.4.3)). In any case, if (n +> 0) is true it then stores a null character into the next +successive location of the array. ++
and similarly p17 (istream::getline()), bullet 3 to: @@ -5023,6 +4852,12 @@ In any case, provided (n > 0) is true, it then stores a null charact
+ +[ +post-Redmond: Pete noticed that the current resolution for get requires +writing to out of bounds memory when n == 0. Martin provided fix. +]
+Section: TR1 6.1.3.5 [tr.tuple.rel] Status: Open Submitter: David Abrahams Date: 29 Nov 2005
@@ -5201,41 +5036,6 @@ a[n] Berlin: Has support. Alisdair provided wording. ]
Section: 21.3.5.8 [lib.string::swap] Status: Ready Submitter: Beman Dawes Date: 14 Dec 2005
--std::string::swap currently says for effects and postcondition: -
- --- --Effects: Swaps the contents of the two strings. -
- --Postcondition: *this contains the characters that were in s, -s contains the characters that were in *this. -
-
-Specifying both Effects and Postcondition seems redundant, and the postcondition -needs to be made stronger. Users would be unhappy if the characters were not in -the same order after the swap. -
-Proposed resolution:
----
- -Effects: Swaps the contents of the two strings.--Postcondition: *this contains the same sequence of -characters that
-werewas in s, -s contains the same sequence of characters that -werewas in *this. -
Section: 23.1 [lib.container.requirements] Status: Open Submitter: Joaquín M López Muñoz Date: 17 Dec 2005
The iterator constructor X(i,j) for containers as defined in 23.1.1 and @@ -5293,94 +5093,6 @@ int main() Berlin: Some support, not universal, for respecting the explicit qualifier. ]
Section: 27.6.1.3 [lib.istream.unformatted] Status: Ready Submitter: Paolo Carlini Date: 12 Feb 2006
--In the most recent working draft, I'm still seeing: -
- -- -seekg(off_type& off, ios_base::seekdir dir) -
-and -
- -- -seekp(pos_type& pos) - -seekp(off_type& off, ios_base::seekdir dir) -
-that is, by reference off and pos arguments. -
-Proposed resolution:
--After 27.6.1.3p42 change: -
- -- -basic_istream<charT,traits>& seekg(off_type&off, ios_base::seekdir dir); -
-After 27.6.2.4p1 change: -
- -- -basic_ostream<charT,traits>& seekp(pos_type&pos); -
-After 27.6.2.4p3 change: -
- --basic_ostream<charT,traits>& seekp(off_type&off, ios_base::seekdir dir); -
Section: 25.2.8 [lib.alg.unique] Status: Ready Submitter: Howard Hinnant Date: 9 Feb 2006
--I believe I botched the resolution of - -241 "Does unique_copy() require CopyConstructible and Assignable?" which now -has WP status. -
- --This talks about unique_copy requirements and currently reads: -
- ---5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the value type of InputIterator -must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required. -- -
-The problem (which Paolo discovered) is that when the iterators are at their -most restrictive (InputIterator, OutputIterator), then we want -InputIterator::value_type to be both CopyConstructible and -CopyAssignable (for the most efficient implementation). However this -proposed resolution only makes it clear that it is CopyConstructible, -and that one can assign from *first to *result. -This latter requirement does not necessarily imply that you can: -
- --*first = *first; -
Proposed resolution:
---5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first -shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the-value type-value_type of InputIterator -must be CopyConstructible (20.1.3) and Assignable. -Otherwise CopyConstructible is not required. -
Section: 26.4 [lib.rand] Status: Open Submitter: Marc Schoolderman Date: 6 Feb 2006
There are some problems in the definition of partial_sum and @@ -5528,157 +5240,43 @@ Berlin: Giving output iterator's value_types very controversial. Suggestion of adding signatures to allow user to specify "accumulator". ]
Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: Ready Submitter: Martin Sebor Date: 15 Oct 2005
+Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: Open Submitter: Martin Sebor Date: 18 Oct 2005
-I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 -that talks about the operator*() member function of shared_ptr: +Peter Dimov wrote: +To: C++ libraries mailing list +Message c++std-lib-15614 +[...] +The intent is for both use_count() and unique() to work in a threaded environment. +They are intrinsically prone to race conditions, but they never return garbage.
-- Notes: When T is void, attempting to instantiate this member function - renders the program ill-formed. [Note: Instantiating shared_ptr<void> - does not necessarily result in instantiating this member function. - --end note] --
-with the requirement in temp.inst, p1: +This is a crucial piece of information that I really wish were +captured in the text. Having this in a non-normative note would +have made everything crystal clear to me and probably stopped +me from ever starting this discussion :) Instead, the sentence +in p12 "use only for debugging and testing purposes, not for +production code" very strongly suggests that implementations +can and even are encouraged to return garbage (when threads +are involved) for performance reasons. +
++How about adding an informative note along these lines:
-- The implicit instantiation of a class template specialization causes - the implicit instantiation of the declarations, but not of the - definitions... + Note: Implementations are encouraged to provide well-defined + behavior for use_count() and unique() even in the presence of + multiple threads.-
-I assume that what the note is really trying to say is that -"instantiating shared_ptr<void> *must not* result in instantiating -this member function." That is, that this function must not be -declared a member of shared_ptr<void>. Is my interpretation -correct? +I don't necessarily insist on the exact wording, just that we +capture the intent.
Proposed resolution:
-Change 2.2.3.5p6
- ---6--Notes:When T is void,attempting to instantiate -this member function renders the program ill-formed. [Note: -Instantiating shared_ptr<void> does not necessarily result in -instantiating this member function. --end note]it is -unspecified whether this member function is declared or not, and if so, what its -return type is, except that the declaration (although not necessarily the -definition) of the function shall be well-formed. -
Section: TR1 2.2.3 [tr.util.smartptr.shared] Status: Tentatively Ready Submitter: Martin Sebor Date: 16 Oct 2005
--Is the void specialization of the template assignment operator taking -a shared_ptr<void> as an argument supposed be well-formed? -
--I.e., is this snippet well-formed: -
-- -shared_ptr<void> p; -p.operator=<void>(p); -
-Gcc complains about auto_ptr<void>::operator*() returning a reference -to void. I suspect it's because shared_ptr has two template assignment -operators, one of which takes auto_ptr, and the auto_ptr template gets -implicitly instantiated in the process of overload resolution. -
- --The only way I see around it is to do the same trick with auto_ptr<void> -operator*() as with the same operator in shared_ptr<void>. -
- --PS Strangely enough, the EDG front end doesn't mind the code, even -though in a small test case (below) I can reproduce the error with -it as well. -
- --template <class T> -struct A { T& operator*() { return *(T*)0; } }; - -template <class T> -struct B { - void operator= (const B&) { } - template <class U> - void operator= (const B<U>&) { } - template <class U> - void operator= (const A<U>&) { } -}; - -int main () -{ - B<void> b; - b.operator=<void>(b); -} -
Proposed resolution:
--In [lib.memory] change: -
-- -template<class X> class auto_ptr; -template<> class auto_ptr<void>; -
-In [lib.auto.ptr]/2 add the following before the last closing brace: -
- -- -template<> class auto_ptr<void> -{ -public: - typedef void element_type; -}; -
Section: TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: New Submitter: Martin Sebor Date: 18 Oct 2005
--Peter Dimov wrote: -To: C++ libraries mailing list -Message c++std-lib-15614 -[...] -The intent is for both use_count() and unique() to work in a threaded environment. -They are intrinsically prone to race conditions, but they never return garbage. -
- --This is a crucial piece of information that I really wish were -captured in the text. Having this in a non-normative note would -have made everything crystal clear to me and probably stopped -me from ever starting this discussion :) Instead, the sentence -in p12 "use only for debugging and testing purposes, not for -production code" very strongly suggests that implementations -can and even are encouraged to return garbage (when threads -are involved) for performance reasons. -
--How about adding an informative note along these lines: -
-- Note: Implementations are encouraged to provide well-defined - behavior for use_count() and unique() even in the presence of - multiple threads. --
-I don't necessarily insist on the exact wording, just that we -capture the intent. -
-Proposed resolution:
--
-Section: 26.3.4 [lib.complex.members] Status: New Submitter: Howard Hinnant Date: 3 Nov 2005
+Section: 26.3.4 [lib.complex.members] Status: Ready Submitter: Howard Hinnant Date: 3 Nov 2005
If one explicitly constructs a slice or glice with the default constructor, does the standard require this slice to have any usable @@ -5716,36 +5314,31 @@ There is a similar question and wording for gslice at 26.3.6.1p1.
Proposed resolution:
+Change 26.5.4.1 [cons.slice]:
-Section: C.2 [diff.library] Status: Tentatively Ready Submitter: Martin Sebor Date: 25 Nov 2005
--According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, -<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, -or <cwchar>." This is consistent with the C standard. -
--However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. -
--In addition, C.2, p2 claims that "The C++ Standard library provides -54 standard macros from the C library, as shown in Table 95." While -table 95 does have 54 entries, since a couple of them (including the -NULL macro) are listed more than once, the actual number of macros -defined by the C++ Standard Library may not be 54. -
-Proposed resolution:
+ ++1 -+The default constructor for slice creates a slice +which specifies no elements.The default constructor is equivalent to +slice(0, 0, 0). A default constructor is provided only to permit +the declaration of arrays of slices. The constructor with arguments for a slice +takes a start, length, and stride parameter. +
-I propose we add <clocale> and <cstdlib> to Table 96 and remove the -number of macros from C.2, p2 and reword the sentence as follows: +Change 26.3.6.1 [gslice.cons]:
+-The C++ Standard library+provides 54 standard macros from-defines a number macros corresponding to those defined by the C -Standard library, as shown in Table 96. +1 -The default constructor creates a gslice which specifies no +elements.The default constructor is equivalent to gslice(0, +valarray<size_t>(), valarray<size_t>()). The constructor +with arguments builds a gslice based on a specification of start, +lengths, and strides, as explained in the previous section.
Section: TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: New Submitter: Matt Austern Date: 10 Jan 2006
+Section: TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: Ready Submitter: Matt Austern Date: 10 Jan 2006
The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if any, is destroyed. In principle there are two possibilities: it is destroyed @@ -5826,18 +5419,6 @@ may block?
Section: TR1 5.1.7.5 [tr.rand.dist.bin] Status: Ready Submitter: Matt Austern Date: 10 Jan 2006
--Paragraph 1 says that "A binomial distributon random distribution produces -integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and -p are the parameters of the distribution. OK, that tells us what t, p, and i -are. What's n? -
-Proposed resolution:
--Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. -
-Section: 26.5 [lib.numarray] Status: New Submitter: Howard Hinnant Date: 12 Jan 2006
Assuming we adopt the @@ -5890,7 +5471,7 @@ Fortran, C and TR1 and make the return type of pow(float,int) be
Section: TR1 8.2 [tr.c99.ccmplx] Status: New Submitter: Howard Hinnant Date: 23 Jan 2006
+Section: TR1 8.2 [tr.c99.ccmplx] Status: Review Submitter: Howard Hinnant Date: 23 Jan 2006
Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: @@ -5924,9 +5505,21 @@ The ? can't refer to the C API. TR1 currently says:
Proposed resolution:
-Strike 8.2 and 8.3 (and any other references to <ccomplex> and -<complex.h>). +Change 26.3.11 [cmplxh]: +
+ ++++The header behaves as if it includes the header +<ccomplex>.
+, and provides sufficient using +declarations to declare in the global namespace all function and type names +declared or defined in the neader <complex>.+[Note: <complex.h> does not promote any interface +into the global namespace as there is no C interface to promote. --end +note]
Section: 25.2.11 [lib.alg.random.shuffle] Status: New Submitter: Martin Sebor Date: 25 Jan 2006
@@ -5956,69 +5549,7 @@ probably should, consistently with C99, 7.18.1.4.
Section: 18.2.1.5 [lib.numeric.special] Status: New Submitter: Howard Hinnant Date: 29 Jan 2006
--I believe we have a bug in the resolution of: -lwg 184 -(WP status). -
- --The resolution spells out each member of numeric_limits<bool>. -The part I'm having a little trouble with is: -
-- -static const bool traps = false; -
-Should this not be implementation defined? Given: -
- -- -int main() -{ - bool b1 = true; - bool b2 = false; - bool b3 = b1/b2; -} -
-If this causes a trap, shouldn't numeric_limits<bool>::traps be -true? -
-Proposed resolution:
--Change 18.2.1.5p3: -
- ---3- The specialization for bool shall be provided as follows: -- --namespace std { - template <> class numeric_limits<bool> { - ... - static const bool traps =falseimplementation-defined; - ... - }; -} -
Section: TR1 8.21 [tr.c99.boolh] Status: New Submitter: Paolo Carlini Date: 2 Feb 2006
--This one, if nobody noticed it yet, seems really editorial: -s/cstbool/cstdbool/ -
-Proposed resolution:
--Change 8.21p1: -
---1- The header behaves as if it defines the additional macro defined in -<cstdbool> by including the header <cstdbool>. --
Section: 25.3 [lib.alg.sorting] Status: New Submitter: Martin Sebor Date: 5 Feb 2006
+Section: 25.3 [lib.alg.sorting] Status: Open Submitter: Martin Sebor Date: 5 Feb 2006
In 25, p8 we allow BinaryPredicates to return a type that's convertible to bool but need not actually be bool. That allows predicates to return @@ -6061,7 +5592,7 @@ algorithms assuming an ordering relation. It is assumed that comp
Section: TR1 8.11.1 [tr.c99.cinttypes.syn] Status: New Submitter: Paolo Carlini Date: 6 Feb 2006
+Section: TR1 8.11.1 [tr.c99.cinttypes.syn] Status: Open Submitter: Paolo Carlini Date: 6 Feb 2006
I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
long long we end up, essentially, with the same arguments and different
@@ -6091,38 +5622,13 @@ imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
imaxdiv_t div(intmax_t numer, intmax_t denom);
...
+
+
[ +Portland: no consensus. +]
+Section: 24.1.1 [lib.input.iterators] Status: New Submitter: David Abrahams Date: 9 Feb 2006
---- 24.1.1 Input iterators [lib.input.iterators] -
-- 1 A class or a built-in type X satisfies the requirements of an - input iterator for the value type T if the following expressions are - valid, where U is the type of any specified member of type T, as - shown in Table 73. -
-
-There is no capital U used in table 73. There is a lowercase u, but -that is clearly not meant to denote a member of type T. Also, there's -no description in 24.1.1 of what lowercase a means. IMO the above -should have been...Hah, a and b are already covered in 24.1/11, so maybe it -should have just been: -
-Proposed resolution:
--Change 24.1.1p1: -
---1- A class or a built-in type X satisfies the requirements of an -input iterator for the value type T if the following expressions -are valid-, where U is the type of any specified member of type -T,as shown in Table 73. -
Section: 18.2 [lib.support.limits] Status: New Submitter: Martin Sebor Date: 19 Feb 2006
+Section: 18.2 [lib.support.limits] Status: Open Submitter: Martin Sebor Date: 19 Feb 2006
18.2.1, p2 requires implementations to provide specializations of the
@@ -6177,6 +5683,12 @@ specialization on a cv-qualified T is equal to the value of the same
member of numeric_limits<T>
.
[ +Portland: Martin will clarify that user-defined types get cv-specializations +automatically. +]
+Section: 20.1.5 [lib.default.con.req] Status: New Submitter: Sergey P. Derevyago Date: 17 Feb 2006
Section: 27.4.4.3 [lib.iostate.flags] Status: Tentatively Ready Submitter: Seungbeom Kim Date: 10 Mar 2006
--Section: 27.4.4.3 [lib.iostate.flags] -
--Paragraph 4 says: -
--- --void clear(iostate state = goodbit); --Postcondition: If rdbuf()!=0 then state == rdstate(); -otherwise rdstate()==state|ios_base::badbit. -
-
-The postcondition "rdstate()==state|ios_base::badbit" is parsed as -"(rdstate()==state)|ios_base::badbit", which is probably what the -committee meant. -
-Proposed resolution:
-Rationale:
--This is a duplicate of issue 272. -
-Section: 21.1 [lib.char.traits] Status: New Submitter: Jack Reeves Date: 6 Apr 2006
Currently, the Standard Library specifies only a declaration for template class @@ -6841,6 +6326,10 @@ this issue WP status (mistakenly).
Strike the proposed resolution of issue 507.
+[ +post-Portland: Howard recommends NAD. The proposed resolution of 507 no longer +exists in the current WD. +]
Section: 27.4.3 [lib.fpos] Status: New Submitter: Beman Dawes Date: 12 Apr 2006
@@ -7165,7 +6654,7 @@ functions.
flush()
not unformatted functionSection: 27.6.2.6 [lib.ostream.unformatted] Status: New Submitter: Martin Sebor Date: 14 June 2006
+flush()
not unformatted functionSection: 27.6.2.6 [lib.ostream.unformatted] Status: New Submitter: Martin Sebor Date: 14 June 2006
The resolution of issue 60 changed basic_ostream::flush()
@@ -7359,7 +6848,7 @@ T power( T x, int n );
// requires: n >=0
Section: 22.2 [lib.locale.categories] Status: New Submitter: Martin Sebor, Paolo Carlini Date: 22 June 2006
+Section: 22.2 [lib.locale.categories] Status: New Submitter: Martin Sebor, Paolo Carlini Date: 22 June 2006
Section 22.2, paragraph 2 requires facet get()
members
@@ -7842,5 +7331,957 @@ calls setstate(failbit) (which may throw ios_base::failure
(27.4.4.3)).
+
Section: 18.3 [lib.cstdint] Status: New Submitter: Walter Brown Date: 28 Aug 2006
++Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers +<cstdint> and <stdint.h>. These are of course based on the C99 header +<stdint.h>, and were part of TR1. +
+ ++Per 18.3.1/1, these headers define a number of macros and function macros. +While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99 +footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The +header defines all ... macros the same as C99 subclause 7.18." +
+ ++Therefore, if I wish to have the above-referenced macros and function macros +defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or +does the C++ header define these macros/function macros unconditionally? +
+Proposed resolution:
++To put this issue to rest for C++0X, I propose the following addition to +18.3.1/2 of the Working Paper N2009: +
+ ++[Note: The macros defined by <cstdint> are provided unconditionally: in +particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS +(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note] ++
Section: 20.1.4 [lib.swappable] Status: New Submitter: Niels Dekker Date: 2 Nov 2006
++It seems undesirable to define the Swappable requirement in terms of +CopyConstructible and Assignable requirements. And likewise, once the +MoveConstructible and MoveAssignable requirements (N1860) have made it +into the Working Draft, it seems undesirable to define the Swappable +requirement in terms of those requirements. Instead, it appears +preferable to have the Swappable requirement defined exclusively in +terms of the existence of an appropriate swap function. +
++Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) +says: +
+The Swappable requirement is met by satisfying one or more of the +following conditions: ++I can think of three disadvantages of this definition: ++
+- +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +
+- +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. +
+
+A client might want to stop T from satisfying the Swappable +requirement, because swapping by means of copy construction and +assignment might throw an exception, and she might find a throwing +swap unacceptable for her type. On the other hand, she might not feel +the need to fully implement her own swap function for this type. In +this case she would want to be able to simply prevent algorithms that +would swap objects of type T from being used, e.g., by declaring a +swap function for T, and leaving this function purposely undefined. +This would trigger a link error, if an attempt would be made to use +such an algorithm for this type. For most standard library +implementations, this practice would indeed have the effect of +stopping T from satisfying the Swappable requirement. +
++While I'm aware about the fact that people have mixed feelings about +providing a specialization of std::swap, it is well-defined to do so. +It sounds rather counter-intuitive to say that T is not Swappable, if +it has a valid and semantically correct specialization of std::swap. +Also in practice, providing such a specialization will have the same +effect as satisfying the Swappable requirement. +
++I'm aware that the intention of the Draft is to prefer calling the +swap function of T over doing copy construction and assignments. Still +in my opinion, it would be better to make this clear in the wording of +the definition of Swappable. +
++I would like to have the Swappable requirement defined in such a way +that the following code fragment will correctly swap two objects of a +type T, if and only if T is Swappable: +
using std::swap; + swap(t, u); // t and u are of type T. ++This is also the way Scott Meyers recommends calling a swap function, +in Effective C++, Third Edition, item 25. + +
+Most aspects of this issue have been dealt with in a discussion on +comp.std.c++ about the Swappable requirement, from 13 September to 4 +October 2006, including valuable input by David Abrahams, Pete Becker, +Greg Herlihy, Howard Hinnant and others. +
+Proposed resolution:
++Change section 20.1.4 [lib.swappable] as follows: +
++The Swappable requirement is met by satisfying ++one or more of the following conditions:+the following condition: ++
+++- +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +
+- +
++T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. ++T is Swappable if an unqualified function call swap(t,u) is valid +within the namespace std, and has the semantics described in Table 33. +
Section: 26.3 [lib.complex.numbers] Status: New Submitter: Stefan Große Pawig Date: 24 Sep 2006
++TR1 introduced, in the C compatibility chapter, the function +fabs(complex<T>): +
++ +----- SNIP ----- +8.1.1 Synopsis [tr.c99.cmplx.syn] + + namespace std { + namespace tr1 { +[...] + template<class T> complex<T> fabs(const complex<T>& x); + } // namespace tr1 + } // namespace std + +[...] + +8.1.8 Function fabs [tr.c99.cmplx.fabs] + +1 Effects: Behaves the same as C99 function cabs, defined in + subclause 7.3.8.1. +----- SNIP ----- +
+The current C++0X draft document (n2009.pdf) adopted this +definition in chapter 26.3.1 (under the comment // 26.3.7 values) +and 26.3.7/7. +
++But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document +n1124), the referenced subclause reads +
+ ++ +----- SNIP ----- +7.3.8.1 The cabs functions + + Synopsis + +1 #include <complex.h> + double cabs(double complex z); + float cabsf(float complex z); + long double cabsl(long double z); + + Description + +2 The cabs functions compute the complex absolute value (also called + norm, modulus, or magnitude) of z. + + Returns + +3 The cabs functions return the complex absolute value. +----- SNIP ----- +
+Note that the return type of the cabs*() functions is not a complex +type. Thus, they are equivalent to the already well established + template<class T> T abs(const complex<T>& x); +(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft +document n2009.pdf). +
++So either the return value of fabs() is specified wrongly, or fabs() +does not behave the same as C99's cabs*(). +
+Proposed resolution:
++This depends on the intention behind the introduction of fabs(). +
++If the intention was to provide a /complex/ valued function that +calculates the magnitude of its argument, this should be +explicitly specified. In TR1, the categorization under "C +compatibility" is definitely wrong, since C99 does not provide +such a complex valued function. +
++Also, it remains questionable if such a complex valued function +is really needed, since complex<T> supports construction and +assignment from real valued arguments. There is no difference +in observable behaviour between +
++complex<double> x, y; + y = fabs(x); + complex<double> z(fabs(x)); +
+and +
++complex<double> x, y; + y = abs(x); + complex<double> z(abs(x)); +
+If on the other hand the intention was to provide the intended +functionality of C99, fabs() should be either declared deprecated +or (for C++0X) removed from the standard, since the functionality +is already provided by the corresponding overloads of abs(). +
+Section: 27.8.1.3 [lib.filebuf.members] Status: New Submitter: Thomas Plum Date: 26 Sep 2006
++In testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke +
++ostr.open("somename", ios_base::out | ios_base::in | ios_base::app) +
+and we expect the open to fail, because out|in|app is not listed in +Table 92, and just before the table we see very specific words: +
++ If mode is not some combination of flags shown in the table + then the open fails. ++
+But the corresponding table in the C standard, 7.19.5.3, provides two +modes "a+" and "a+b", to which the C++ modes out|in|app and +out|in|app|binary would presumably apply. +
+Proposed resolution:
++We would like to argue that the intent of Table 112 was to match the +semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was +unintentional. (Otherwise there would be valid and useful behaviors +available in C file I/O which are unavailable using C++, for no +valid functional reason.) +
++We further request that the missing modes be explicitly restored to +the WP, for inclusion in C++0x. +
+Section: Decimal 3.2 Status: Open Submitter: Daveed Vandevoorde Date: 5 April 2006
++In a private email, Daveed writes: +
++++I am not familiar with the C TR, but my guess is that the +class type approach still won't match a built-in type +approach because the notion of "promotion" cannot be +emulated by user-defined types. +
++Here is an example: +
+
+ struct S { + S(_Decimal32 const&); // Converting constructor + }; + void f(S); + + void f(_Decimal64); + + void g(_Decimal32 d) { + f(d); + } ++ +
+++If _Decimal32 is a built-in type, the call f(d) will likely +resolve to f(_Decimal64) because that requires only a +promotion, whereas f(S) requires a user-defined conversion. +
++If _Decimal32 is a class type, I think the call f(d) will be +ambiguous because both the conversion to _Decimal64 and the +conversion to S will be user-defined conversions with neither +better than the other. +
+
+Robert comments: +
+In general, a library of arithmetic types cannot exactly emulate the +behavior of the intrinsic numeric types. There are several ways to tell +whether an implementation of the decimal types uses compiler +intrinisics or a library. For example: +
+_Decimal32 d1; + d1.operator+=(5); // If d1 is a builtin type, this won't compile. ++
+In preparing the decimal TR, we have three options: +
++We decided as a group to pursue option #3, but that approach implies +that implementations may not agree on the semantics of certain use +cases (first example, above), or on whether certain other cases are +well-formed (second example). Another potentially important problem is +that, under the present definition of POD, the decimal classes are not +POD types, but builtins will be. +
+Note that neither example above implies any problems with respect to +C-to-C++ compatibility, since neither example can be expressed in C. +
+Proposed resolution:
+Section: Decimal 3.2 Status: Ready Submitter: Daniel Krugler Date: 28 May 2006
+ ++In a private email, Daniel writes: +
++++I would like to +ask, what where the reason for the decision to +define the semantics of the integral conversion of the decimal types, namely +
+"operator long long() const; + + Returns: Returns the result of the +conversion of *this to the type long long, as if +performed by the expression llrounddXX(*this)." +++where XX stands for either 32, 64, or 128, +corresponding to the proper decimal type. The +exact meaning of llrounddXX is not given in that +paper, so I compared it to the corresponding +definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2: +
++"The lround and llround functions round their +argument to the nearest integer value, +rounding halfway cases away from zero, regardless +of the current rounding direction. [..]" +
++Now considering the fact that integral conversion +of the usual floating-point types ("4.9 +Floating-integral conversions") has truncation +semantic I wonder why this conversion behaviour +has not been transferred for the decimal types. +
+
+Robert comments: +
+
+Also, there is a further error in the Returns: clause for converting decimal::decimal128
to long long
. It currently calls llroundd64
, not llroundd128
.
+
Proposed resolution:
++Change the Returns: clause in 3.2.2.4 to: +
++Returns: Returns the result of the conversion of+*this
to the typelong long
, as if performed by the expressionllroundd32(*this)
while the decimal rounding direction mode [3.5.2]FE_DEC_TOWARD_ZERO
is in effect. +
+Change the Returns: clause in 3.2.3.4 to: +
++Returns: Returns the result of the conversion of+*this
to the typelong long
, as if performed by the expressionllroundd64(*this)
while the decimal rounding direction mode [3.5.2]FE_DEC_TOWARD_ZERO
is in effect. +
+Change the Returns: clause in 3.2.4.4 to: +
++Returns: Returns the result of the conversion of+ +*this
to the typelong long
, as if performed by the expressionllroundd64(*this)
llroundd128(*this)
while the decimal rounding direction mode [3.5.2]FE_DEC_TOWARD_ZERO
is in effect. +
Section: Decimal 3.1 Status: Ready Submitter: Daniel Krugler Date: 28 May 2006
++Daniel writes in a private email: +
+ ++++- 3.1 'Decimal type encodings' says in its note: +
++"this implies that +sizeof(std::decimal::decimal32) == 4, +sizeof(std::decimal::decimal64) == 8, and +sizeof(std::decimal::decimal128) == 16." +
+
+This is a wrong assertion, because the definition +of 'byte' in 1.7 'The C+ + memory model' of ISO +14882 (2nd edition) does not specify that a byte +must be necessarily 8 bits large, which would be +necessary to compare with the specified bit sizes +of the types decimal32, decimal64, and decimal128. + +
Proposed resolution:
++Change 3.1 as follows: +
++++The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows: +
++
+- +decimal32 is a decimal32 number, which is encoded in four consecutive
+bytesoctets (32 bits) +- +decimal64 is a decimal64 number, which is encoded in eight consecutive
+bytesoctets (64 bits) + +- +decimal128 is a decimal128 number, which is encoded in 16 consecutive
+bytesoctets (128 bits) ++
+[Note: this implies that+sizeof(std::decimal::decimal32) == 4
,sizeof(std::decimal::decimal64) == 8
, andsizeof(std::decimal::decimal128) == 16
. --end note]
Section: Decimal 3.9 Status: Ready Submitter: Daniel Krugler Date: 28 May 2006
++Daniel writes: +
++- 3.9.1 'Additions to <cwchar>' provides wrong +signatures to the wcstod32, wcstod64, and +wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t). ++
Proposed resolution:
+
+Change "3.9.1 Additions to <cwchar>
synopsis" to:
+
namespace std { + namespace decimal { + // 3.9.2 wcstod functions: + decimal32 wcstod32 (const+charwchar_t * nptr,charwchar_t ** endptr); + decimal64 wcstod64 (constcharwchar_t * nptr,charwchar_t ** endptr); + decimal128 wcstod128 (constcharwchar_t * nptr,charwchar_t ** endptr); + } + } +
Section: Decimal 3.3 Status: Ready Submitter: Daniel Krugler Date: 28 May 2006
++Daniel writes in a private email: +
+ ++++- 3.3 'Additions to header <limits>' contains two +errors in the specialisation of numeric_limits<decimal::decimal128>: +
++
+- The static member max() returns DEC128_MIN, this should be DEC128_MAX.
+- The static member digits is assigned to 384, +this should be 34 (Probably mixed up with the +max. exponent for decimal::decimal64).
+
Proposed resolution:
+
+In "3.3 Additions to header <limits>
" change numeric_limits<decimal::decimal128> as follows:
+
template<> class numeric_limits<decimal::decimal128> { + public: + static const bool is_specialized = true; + + static decimal::decimal128 min() throw() { return DEC128_MIN; } + static decimal::decimal128 max() throw() { return+DEC128_MIN;DEC128_MAX; } + + static const int digits =38434; + /* ... */ +
Section: Decimal 3 Status: Ready Submitter: Daniel Krugler Date: 28 May 2006
++The document uses the term "generic floating types," but defines it nowhere. +
+Proposed resolution:
++Change the first paragraph of "3 Decimal floating-point types" as follows: +
++This Technical Report introduces three decimal floating-point types, named +decimal32, decimal64, and decimal128. The set of values of type decimal32 is a +subset of the set of values of type decimal64; the set of values of the type +decimal64 is a subset of the set of values of the type decimal128. Support for +decimal128 is optional. These types supplement the Standard C++ types ++float
,double
, andlong double
, which are +collectively described as the basic floating types. +
Section: Decimal 3 Status: Ready Submitter: Martin Sebor Date: 28 May 2006
+In c++std-lib-17198, Martin writes:
+ ++Each of the three classes proposed in the paper (decimal32, decimal64, +and decimal128) explicitly declares and specifies the semantics of its +copy constructor, copy assignment operator, and destructor. Since the +semantics of all three functions are identical to the trivial versions +implicitly generated by the compiler in the absence of any declarations +it is safe to drop them from the spec. This change would make the +proposed classes consistent with other similar classes already in the +standard (e.g., std::complex). ++
Proposed resolution:
+
+Change "3.2.2 Class decimal32
" as follows:
+
namespace std { + namespace decimal { + class decimal32 { + public: + // 3.2.2.1 construct/copy/destroy: + decimal32(); ++decimal32(const decimal32 & d32);+decimal32 & operator=(const decimal32 & d32);+~decimal32();+ /* ... */ +
+Change "3.2.2.1 construct/copy/destroy" as follows: +
+decimal32(); + + Effects: Constructs an object of type decimal32 with the value 0; + ++decimal32(const decimal32 & d32);+decimal32 & operator=(const decimal32 & d32);+ +Effects: Copies an object of type decimal32.+ +~decimal32();+ +Effects: Destroys an object of type decimal32.+ +
+Change "3.2.3 Class decimal64
" as follows:
+
namespace std { + namespace decimal { + class decimal64 { + public: + // 3.2.3.1 construct/copy/destroy: + decimal64(); ++decimal64(const decimal64 & d64);+decimal64 & operator=(const decimal64 & d64);+~decimal64();+ /* ... */ +
+Change "3.2.3.1 construct/copy/destroy" as follows: +
+decimal64(); + + Effects: Constructs an object of type decimal64 with the value 0; + ++decimal64(const decimal64 & d64);+decimal64 & operator=(const decimal64 & d64);+ +Effects: Copies an object of type decimal64.+ +~decimal64();+ +Effects: Destroys an object of type decimal64.+ +
+Change "3.2.4 Class decimal128
" as follows:
+
namespace std { + namespace decimal { + class decimal128 { + public: + // 3.2.4.1 construct/copy/destroy: + decimal128(); ++decimal128(const decimal128 & d128);+decimal128 & operator=(const decimal128 & d128);+~decimal128();+ /* ... */ +
+Change "3.2.4.1 construct/copy/destroy" as follows: +
+decimal128(); + + Effects: Constructs an object of type decimal128 with the value 0; + ++decimal128(const decimal128 & d128);+decimal128 & operator=(const decimal128 & d128);+ +Effects: Copies an object of type decimal128.+ +~decimal128();+ +Effects: Destroys an object of type decimal128.+ +
Section: Decimal 3 Status: Review Submitter: Martin Sebor Date: 28 May 2006
++In c++std-lib-17197, Martin writes: +
++The extended_num_get and extended_num_put facets are designed +to store a reference to a num_get or num_put facet which the +extended facets delegate the parsing and formatting of types +other than decimal. One form of the extended facet's ctor (the +default ctor and the size_t overload) obtains the reference +from the global C++ locale while the other form takes this +reference as an argument. ++
+The problem with storing a reference to a facet in another +object (as opposed to storing the locale object in which the +facet is installed) is that doing so bypasses the reference +counting mechanism designed to prevent a facet that is still +being referenced (i.e., one that is still installed in some +locale) from being destroyed when another locale that contains +it is destroyed. Separating a facet reference from the locale +it comes from van make it cumbersome (and in some cases might +even make it impossible) for programs to prevent invalidating +the reference. (The danger of this design is highlighted in +the paper.) ++
+This problem could be easily avoided by having the extended +facets store a copy of the locale from which they would extract +the base facet either at construction time or when needed. To +make it possible, the forms of ctors of the extended facets that +take a reference to the base facet would need to be changed to +take a locale argument instead. ++
Proposed resolution:
+
+1. Change the extended_num_get
synopsis in 3.10.2 as follows:
+
extended_num_get(const+std::num_get<charT, InputIterator>std::locale & b, size_t refs = 0); + + /* ... */ + +// const std::num_get<charT, InputIterator> & base; exposition only+ // std::locale baseloc; exposition only +
+2. Change the description of the above constructor in 3.10.2.1: +
+extended_num_get(const+std::num_get<charT, InputIterator>std::locale & b, size_t refs = 0); + +
+++Effects: Constructs an
+extended_num_get
facet as if by: +extended_num_get(const+std::num_get<charT, InputIterator>std::locale & b, size_t refs = 0) + : facet(refs), baseloc(b) + { /* ... */ } + ++
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting+extended_num_get
facet.
+3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const
, et al to
+
+Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val)
.
+
+
+4. Change the extended_num_put
synopsis in 3.10.3 as follows:
+
extended_num_put(const+std::num_put<charT, OutputIterator>std::locale & b, size_t refs = 0); + + /* ... */ + +// const std::num_put<charT, OutputIterator> & base; exposition only+ // std::locale baseloc; exposition only +
+5. Change the description of the above constructor in 3.10.3.1: +
+extended_num_put(const+std::num_put<charT, OutputIterator>std::locale & b, size_t refs = 0); +
+++Effects: Constructs an
+extended_num_put
facet as if by: +extended_num_put(const+std::num_put<charT, OutputIterator>std::locale & b, size_t refs = 0) + : facet(refs), baseloc(b) + { /* ... */ } + ++
+Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting+extended_num_put
facet.
+6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const
, et al to
+
+Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val)
.
+
+
+[ +Redmond: We would prefer to rename "extended" to "decimal". +]
+ +Section: Decimal 3.4 Status: Ready Submitter: Robert Klarer Date: 17 October 2006
+In Berlin, WG14 decided to drop the <decfloat.h> header. The +contents of that header have been moved into <float.h>. For the +sake of C compatibility, we should make corresponding changes. +
+Proposed resolution:
+
+1. Change the heading of subclause 3.4, "Headers <cdecfloat>
and <decfloat.h>
" to "Additions to headers <cfloat>
and <float.h>
."
+
+2. Change the text of subclause 3.4 as follows: +
++++
+The standard C++ headers+<cfloat>
and<float.h>
define characteristics of the floating-point typesfloat
,double
, andlong double
. Their contents remain unchanged by this Technical Report.+
+Headers+<cdecfloat>
and<decfloat.h>
define characteristics of the decimal floating-point typesdecimal32
,decimal64
, anddecimal128
. As well,<decfloat.h>
defines the convenience typedefs_Decimal32
,_Decimal64
, and_Decimal128
, for compatibilty with the C programming language.+The header
+<cfloat>
is described in [tr.c99.cfloat]. The header<float.h>
+is described in [tr.c99.floath]. These headers are extended by this +Technical Report to define characteristics of the decimal +floating-point typesdecimal32
,decimal64
, anddecimal128
. As well,<float.h>
is extended to define the convenience typedefs_Decimal32
,_Decimal64
, and_Decimal128
for compatibility with the C programming language. +
+3. Change the heading of subclause 3.4.1, "Header <cdecfloat>
synopsis" to "Additions to header <cfloat>
synopsis."
+
+4. Change the heading of subclause 3.4.2, "Header <decfloat.h>
synopsis" to "Additions to header <float.h>
synopsis."
+
+5. Change the contents of 3.4.2 as follows: +
++ +#include <cdecfloat>+ + // C-compatibility convenience typedefs: + + typedef std::decimal::decimal32 _Decimal32; + typedef std::decimal::decimal64 _Decimal64; + typedef std::decimal::decimal128 _Decimal128; +
Section: Decimal 3.2 Status: Open Submitter: Martin Sebor Date: 15 June 2006
++In c++std-lib-17205, Martin writes: +
++...was it a deliberate design choice to make narrowing assignments +ill-formed while permitting narrowing compound assignments? For +instance: ++
decimal32 d32; + decimal64 d64; + + d32 = 64; // error + d32 += 64; // okay ++
+In c++std-lib-17229, Robert responds: +
+It is a vestige of an old idea that I forgot to remove from +the paper. Narrowing assignments should be permitted. The bug is that +the converting constructors that cause narrowing should not be +explicit. Thanks for pointing this out. ++
Proposed resolution:
+
+1. In "3.2.2 Class decimal32
" synopsis, remove the explicit
specifier from the narrowing conversions:
+
// 3.2.2.2 conversion from floating-point type: ++explicitdecimal32(decimal64 d64); +explicitdecimal32(decimal128 d128); +
+2. Do the same thing in "3.2.2.2. Conversion from floating-point type." +
+
+3. In "3.2.3 Class decimal64
" synopsis, remove the explicit
specifier from the narrowing conversion:
+
// 3.2.3.2 conversion from floating-point type: ++explicitdecimal64(decimal128 d128); +
+4. Do the same thing in "3.2.3.2. Conversion from floating-point type." +
+ +[ +Redmond: We prefer explicit conversions for narrowing and implicit for widening. +]
+ +Section: 26.4.7.1 [lib.rand.dist.iunif] Status: New Submitter: Charles Karney Date: 26 Oct 2006
++Short seed vectors of 32-bit quantities all result in different states. However +this is not true of seed vectors of 16-bit (or smaller) quantities. For example +these two seeds +
+ ++ +unsigned short seed = {1, 2, 3}; +unsigned short seed = {1, 2, 3, 0}; +
+both pack to +
+ ++ +unsigned seed = {0x20001, 0x3}; +
+yielding the same state. +
+Proposed resolution:
++In 26.4.7.1[rand.util.seedseq]/8a, replace +
+ +++ ++Set begin[0] to 5489 +
+sN. ++where N is the bit length of the sequence used to construct the +seed_seq in 26.4.7.1/6 [rand.util.seedseq]. (This quantity is called n +in 26.4.7.1/6 [rand.util.seedseq], but n has a different meaning in +26.4.7.1/8 [rand.util.seedseq]. We have 32^(s-1) < N <= 32^s.) Now +
+ ++ +unsigned short seed = {1, 2, 3, 0}; +unsigned seed = {0x20001, 0x3}; ++are equivalent (N = 64), but +
+ ++ +unsigned short seed = {1, 2, 3}; ++gives a distinct state (N = 48). +
+
Section: 26.4.7.1 [lib.rand.dist.iunif] Status: New Submitter: Charles Karney Date: 26 Oct 2006
++In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the +treatment of signed quantities is unclear. Better to spell it out. +
+Proposed resolution:
++ +b = sum( unsigned(begin[i]) 2^(w i), 0 <= i < end-begin ) +
+where w is the bit-width of the InputIterator. +
+Section: 26.4.4.2 [lib.rand.eng.mers] Status: New Submitter: Walter E. Brown Date: 2 Nov 2006
++In preparing N2111, an error on my part resulted in the omission of the +following line from the template synopsis in the cited section: +
+ ++ +static const size_t word_size = w; +
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].) +
+Proposed resolution:
++Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4: +
+ ++ +// engine characteristics +static const size_t word_size = w; +
+and accept my apologies for the oversight. +
----- End of document -----