JTC1/SC22/WG21
N1723
Document number: N1723=04-0163
Date: 20 Oct 2004
Reply to: Matt Austern
austern@apple.com
PROPOSED RESOLUTIONS TO LIBRARY TR ISSUES
1.4 Meaning of "impure extension"
Remove paragraph [tr.intro.ext]/2 ("The first three categories are
collectively ...")
Change [tr.tuple.pairs]/1 from:
This is an impure extension (as defined in section 1.2) to the
standard library class template std::pair.
to:
These templates are extensions to the standard library class
template std::pair.
2.5 May smart pointers point to incomplete types?
Accept proposed resolution from TR issues list, N1688
2.10 Missing converting constructor requirements
Accept proposed resolution from TR issues list, N1688
3.12 Conversion of traits to integral_constant
3.14 Type_traits specifications could be simpler
3.15 Inconsistent non-normative note for has_virtual_destructor
Accept proposed resolution from N1713=04-0153
3.16 aligned_storage underspecified?
Replace [tr.meta.trans.other] paragraph 1 with:
Preconditions: Len shall be nonzero. Align shall be equal to
alignment_of<T>::value for some type T.
type: an unspecified POD type suitable for use as uninitialized
storage for any object whose size is at most Len and whose
alignment is a divisor of Align.
[Note: a typical implementation would define type as:
union type
{
unsigned char __data[Len];
/Aligner/ __align;
};
where /Aligner/ is the smallest POD type for which
alignment_of</Aligner/>::value is Align.
-- end note.]
3.17 type_traits Compromise Requirements
Change [tr.meta.req]/3 from:
If there is no means by which the implementation can
differentiate between class and union types, then the class
templates is_class and is_union need not be provided.
to:
If there is no means by which the implementation can
differentiate between class and union types, then the class
templates is_class and is_union shall be defined as follows:
template <class T> struct is_class {};
template <class T> struct is_union {};
Change [tr.meta.req]/4 from:
If there is no means by which the implementation can detect
polymorphic types, then the class template is_polymorphic need
not be provided.
to:
If there is no means by which the implementation can detect
polymorphic types, then the class template is_polymorphic
shall be defined as follows:
template <class T> struct is_polymorphic {};
Change [tr.meta.req]/5 from:
If there is no means by which the implementation can detect
abstract types, then the class template is_abstract need not
be provided.
to:
If there is no means by which the implementation can detect
abstract types, then the class template is_abstract shall be
defined as follows:
template <class T> struct is_abstract {};
3.19 Incorrect normative description of type properties
Accept proposed resolution from TR issues list, N1688
4.38 Seeding of random number generators
Modify section 5.1.1 as follows:
* In paragraph 2, add after "v is an lvalue of X"
..., s is a nonnegative value of integral type, ...
* Add in table 9 before X(g):
expression: X(s)
return type: none
pre/post-condition: creates an engine with the initial
internal state determined by s
complexity: O(size of state)
* Add in table 9 before seed(g):
expression: u.seed(s)
return type: void
pre/post-condition: post: sets the internal state of
u so that u == X(s).
complexity: same as X(s)
* Merge paragraph 5 with paragraph 4 and remove the
words at the beginning of paragraph 5: "For every pseudo-random
number engine defined in this clause" so that the requirements in
paragraph 5 become general "additional requirements".
In section 5.1.4.1 "linear_congruential", replace the declarations in
both the synopsis and the detailed description:
explicit linear_congruential(UIntType x0 = 1);
...
void seed(UIntType x0 = 1);
by
explicit linear_congruential(unsigned long x0 = 1);
...
void seed(unsigned long x0 = 1);
In section 5.1.4.5 "discard_block", add (also to the synopsis)
explicit discard_block(unsigned long s)
Effects: Constructs a discard_block engine. To construct the subobject
b, invokes the b(s) constructor. Sets n = 0.
In section 5.1.4.6 "xor_combine", add (also to the synopsis)
explicit xor_combine(unsigned long s)
Effects: Constructs a xor_combine engine. To construct the subobject
b1, invokes the b1(s) constructor. Then, to construct the subobject
b2, invokes the b2(s+1) constructor. [Note: If both b1 and b2 are of
the same type, both engines should not be initialized with the same
seed.]
5.2 Assoc_legendre incorrectly requires a domain error
5.3 Assoc_legendre should require domain error when |x| > 1
5.4 Beta should have domain error if x <= 0 or y <= 0
5.5 Legendre should always have domain error if |x| > 1
5.6 Bessel should require domain error for x < 0
Accept the proposed resolution from N1665.
5.7 Order parameter in Bessel functions should be restricted
Accept the proposed resolution from N1697.
6.15 Hash functions and const containers
In table 14, unordered associative container requirements, replace the
assertion column for X::hasher with: "Hash is a unary function object
type such that the expression hf(k) has type std::size_t".
6.16 Swap() missing from header synopses
Accept proposed resolution from TR issues list, N1688
6.17 Hashing strings, revisited
Accept option 1 of proposed resolution from TR issues list, N1688
7.28 What is an invalid/empty regular expression?
In [tr.re.regex.construct], change paragraph 1 from:
Effects: Constructs an object of class basic_regex. The
postconditions of this function are indicated in Table 19.
to:
Effects: Constructs an object of class basic_regex that does
not match any character sequence.
Remove Table 19.
In the declaration of basic_regex in [tr.re.regex], change:
// capacity
bool empty() const;
unsigned mark_count() const;
to:
// capacity
unsigned mark_count() const;
Remove the entry for empty() in the following tables:
Table 20 [basic_regex(const charT* p, flag_type f) effects]
Table 21 [basic_regex(const charT* p1, size_type len, flag_type f) effects]
Table 22 [basic_regex(const basic_regex& e) effects]
Table 23 [basic_regex(const basic_string&) effects]
Table 24 [basic_regex(ForwardIterator first, ForwardIterator last,
flag_type f, const Allocator&) effects]
Table 25 [basic_regex& assign(const basic_string<charT, string_traits, A>& s,
flag_type f) effects]
[Also, the title of Table 24 still mentions an Allocator argument, which should
have been removed in a previous edit]
Change the last sentence of [tr.re.regex.locale]/1 from:
Calls to imbue invalidate any currently contained regular
expression.
to:
After a call to imbue the basic_regex object does not match
any character sequence.
Remove [tr.re.regex.locale]/2, which reads:
Postcondition: empty() == true.
7.34 Meaning of the match_partial flag
Remove match_partial.
7.54 Format_no_copy specified incorrectly
Accept proposed resolution from TR issues list, N1688
7.55 typo in regex_token_iterator::operator++
Accept proposed resolution from TR issues list, N1688
7.56 match_results stream inserter not specified
Add the specification of nonmember swap as proposed in the TR
issues list, N1688, but remove the stream inserter.
7.57 imprecise specification of match_results::size()
In [tr.re.results.size] (7.10.2), change the Returns clause for
the size member function from "Returns: One plus the number of
marked sub-expressions in the regular expression that was
matched." to "Returns: One plus the number of marked
sub-expressions in the regular expression that was matched if
*this represents the result of a successful match. Otherwise
returns 0. [Note: The state of a match_results object can be
modified only by passing that object to regex_match or
regex_search. Sections tr.re.alg.match and tr.re.alg.search
specify the effects of those algorithms on their match_results
arguments.]"
In tr.re.alg.match (7.11.2) paragraph 3, change "the effect on
parameter m is unspecified" to "the effect on parameter m is
unspecified except that m.size() returns 0 and m.empty() returns true"
In tr.re.alg.search (7.11.3) paragraph 3, change "the effect on
parameter m is unspecified" to "the effect on parameter m is
unspecified except that m.size() returns 0 and m.empty() returns true"
7.58 Does match_results<>::begin() point to element 0
In the description of match_results<>::begin() and
match_results<>::end in 7.10.3, change "enumerates over all the marked
sub-expression matches stored in *this" to "enumerates over all the
sub-expressions stored in *this".
7.59 "Implementation defined" in regex traits requirements
Accept proposed resolution from TR issues list, N1688
7.60 Requirements for v.isctype in regular expression traits
In [tr.re.req] (7.3) paragraph 4, add "cl is an object of type
X::char_class_type". In table 15, change the expression "v.isctype(c,
v.lookup_classname(F1, F2))" to "v.isctype(c, cl)" and change the
note to "Returns true if character c is a member of one of the
character classes designated by cl, false otherwise".
7.61 Definition of match_results::position
In 7.10.3 change the definition of position from
Returns: std::distance(prefix().first, (*this)[sub].first).
to
Returns: The distance from the start of the target sequence
to (*this)[sub].first.
7.62 Is regex_traits::size_type necessary?
Remove size_type from the regex trait requirements table (table 15)
and from class template regex_traits (tr.re.traits, 7.7). In
both places, change the return type of length() to std::size_t.
7.63 effects clause of regex algorithms and match_partial
In the description of regex_match, change "Determines whether
there is an exact match" to "Determines whether there is a
match".
7.64 exception safety of assign(basic_string<>)
In the description of basic_regex::assign(string), add a note
saying that if assign throws then *this is unchanged.
7.65 We still have str() in basic_regex::assign
In 7.8.2/13 change "returns the result of assign(e.str(), e.flags())"
to "returns the result of assign(e)".
In 7.8.4/1, change "Returns assign(that.str(), that.flags())" to
"Copies that into *this and returns *this." Create a table to
reflect the result of that operation, modeled on the copy
constructor table.
10.4 Argument passing for reference_wrapper::operator()
Accept proposed resolution from TR issues list, N1688
10.8 Class template function should have null pointer assignment/
comparison operations
Accept proposed resolution from TR issues list, N1688
[Note to editor: remove the spurious allocator argument.]
10.10 result_of should be based on rvalues, not lvalue
Accept proposed resolution from TR issues list, N1688
10.19 Underspecification of reference wrapper assignment
In the reference_wrapper summary 2.1.2 [tr.util.refwrp.refwrp], replace:
// construct/copy/destruct
explicit reference_wrapper(T&);
With the following:
// constructors
explicit reference_wrapper(T&);
reference_wrapper(const reference_wrapper<T>& x);
// assignment
reference_wrapper& operator=(const reference_wrapper<T>& x);
In 2.1.2.1 [tr.util.refwrp.const], after paragraph 2, add:
reference_wrapper(const reference_wrapper<T>& x);
3 Postconditions: *this references the object that x references.
4 Throws: Does not throw.
Add a new section 2.1.2.2 [tr.util.refwrp.assign] after section
2.1.2.1 [tr.util.refwrp.const], containing:
reference_wrapper& operator=(const reference_wrapper<T>& x);
1 Postconditions: *this references the object that x references.
2 Throws: Does not throw.
10.24 Mem_fn result_type for pointer to data member
Remove result_type for pointer-to-data-member.
10.26 Wrong arguments to unary_function and binary_function
Accept proposed resolution from TR issues list, N1688
10.27 Reference_wrapper should be in <functional>
Accept proposed resolution from TR issues list, N1688
10.29 reference_wrapper<reference_wrapper<T> >
Accept proposed resolution from TR issues list, N1688,
but only the parts changing the behavior of ref and
cref, not the parts that make nested reference_wrapper
ill formed.
10.30 function comparison operators unreliable
Accept proposed resolution from TR issues list, N1688
10.32 function(reference_wrapper f) targets f.get
Accept proposed resolution from TR issues list, N1688
10.34 is reference_wrapper<void()> supposed to be legal?
In the proposed resolution in N1673, replace the first bullet in the
definition of *simple call wrapper* from:
- if T is a pointer to function, result_type shall be a synonym for
the return type of T;
to the following:
- if T is a function, reference to function, or pointer to function
type, result_type shall be a synonym for the return type of T;
10.35 result_of and Standard Library Function Objects
Change the beginning of the first sentence of [tr.func.ret]/3 from:
If the implementation cannot determine the type of the expression
f(t1, t2, ..., tN), or if the expression is ill-formed, the
implementation shall use the following process to determine the
member type type:
to:
If F is not a function object defined by the standard library, and
if either the implementation cannot determine the type of the
expression f(t1, t2, ..., tN) or else if the expression is ill-formed,
the implementation shall use the following process to determine the
member type type:
Remove bullet item 3 from [tr.func.ret]/3.
10.37 TR1Function Objects and Backward Compatibility
In the revised version of [tr.func.memfn], add the following after the
"Returns:" paragraph:
The simple call wrapper shall be derived from
std::unary_function<cv T*, R> when pm is a pointer to member
function with cv-qualifier cv and taking no arguments.
The simple call wrapper shall be derived from
std::binary_function<cv T*, T1, R> when pm is a pointer to
member function with cv-qualifier cv and taking one argument
of type T1.
Change the first line of the declaration of reference_wrapper in
[tr.util.refwrp.refwrp] from:
template <class T> class reference_wrapper {
to:
template <class T> class reference_wrapper
: public unary_function<T1, R> // see below
: public binary_function<T1, T2, R> // see below
{
Add the following text immediately before [tr.util.refwrp.const]:
The template instantiation reference_wrapper<T> shall be derived
from unary_function<T1, R> only if the type T is any of the
following:
-- a function type or a pointer to function type taking
one argument of type T1 and returning R
-- 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
-- a class type that is derived from unary_function<T1, R>
The template instantiation reference_wrapper<T> shall be
derived from binary_function<T1, T2, R> only if the type T
is any of the following:
-- a function type or a pointer to function type taking
two arguments of types T1 and T2 and returning R
-- 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
-- a class type that is derived from
binary_function<T1, T2, R>
10.38 Accessing the target of a TR1 function object
Accept the proposed resolution from N1667, but renaming type to
target_type, and returning the type_info by const reference instead
of by value.
11.4 "ignore" unspecified
Accept proposed resolution from TR issues list, N1688
11.5 Tuple inequality tests badly specified
In sections 6.1.2.5, 6.1.2.6, and 6.1.2.7, rewrite the
descriptions of operator!=, operator>, operator<=, and operator>=
in terms of operator== and operator<.
11.7 Tuple interface to pair and array: which header?
Accept proposed resolution from TR issues list, N1688
11.2/11.3/11.6
Remove tuple I/O from tr1.