JTC1/SC22/WG21
N0789
Doc. No.: WG21/N0789=X3J16/95-0189
Date: 26 Sep 1995
Project: C++ Standard Library
Reply to: Nathan Myers
<myersn@roguewave.com>
Clause 20 (Utilities Library) Issues (Revision 2)
** Revision History:
Revision 0 - 22 May 1995 [was Version 1]
Revision 1 - 09 Jul 1995 [was Version 2] (edits before Monterey)
Revision 2 - 26 Sep 1995 (pre-Tokyo)
** Introduction
This document is a summary of issues identified for the Clause 20,
identifying resolutions as they are voted on, and offering recommendations
for unsolved problems in the Draft where possible.
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-014
** Title: allocator could be a template again
** Sections: [lib.allocator.requirements], [lib.default.allocator]
** Status: active
** Description:
Plauger says:
> A general cleanup of class allocator can easily be achieved by
> making it a template class once again:
template <class T> class allocator { ... };
> The default allocator object for a container of type T would then
> be allocator<T>(). All of the capabilities added with the Nov. '94
> changes would still be possible, and users could write replacement
> allocators with a much cleaner interface.
** Discussion:
In many containers, what one allocates is not objects of type T, but
objects of type (e.g.) Node<T>. Therefore, in most cases the
container would be passed an allocator<T> when what it needs is
an allocator< Node<T> >, and possibly other instantiations as well.
A separate proposal spells out the details. The difference between
Plauger's suggestion in the ANSI public comments and the proposal is
is the addition of:
1. A template constructor:
template <class U>
allocator(const allocator<U>&) throw();
2. and a member template containing a typedef:
template <class U> struct rehost { typedef allocator<U> other; };
These two changes permit a container to construct an allocator
of the required type, given one for any other type.
** Proposed Resolution:
As in N0??? = 95-0???, Allocator Cleanup.
** Requester: Plauger
----------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-007
** Title: C functions asctime() and strftime() use global locale
** Sections: 20.5 [lib.date.time]
** Status: active
** Description:
The Draft describes the functions asctime() and strftime() as identical
to the C Library functions of the same name. However, they depend on
the global locale, which is not the same in the C++ Library. We need
text here to describe how they use the global locale.
** Discussion:
The mapping is quite straightforward: they use
use_facet< time_put<char> >(locale()).put(...)
as many times as necessary to format their results.
[Note: this issue was voted on in Monterey, and passed, with
no actual resolution specified.]
** Proposed Resolution:
This issue is tied to Clause 22 issue 22-009. If that proposal
passes, this issue should be closed.
** Requestor:
** Owner:
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-010
** Title: auto_ptr specification wrong.
** Sections: 20 [lib.auto.ptr]
** Status: active
** Description:
The specification for auto_ptr in the July Draft did not match
the defining proposal, in many details. I don't know if Greg
is satisfied yet.
** Proposed Resolution
Change the specification to match the resolution accepted by
the committee.
** Requestor: Greg Colvin
** Owner:
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-017
** Title: implicit_cast template wanted
** Sections: 20.?
** Status: active
** Description:
To round out the set of casts, several people have suggested
an "implicit_cast<>()" be added to the set. It was not added
in Core because it can be implemented in a library. If it is
to be in libraries, many believe it should be in the standard
library.
** Proposed Resolution
Add the following definitions in Clause 20:
template <class T, class U> T implicit_cast(U& u);
template <class T, class U> T implicit_cast(U const& u);
template <class T, class U> T implicit_cast(U volatile& u);
template <class T, class U> T implicit_cast(U const volatile& u);
Returns: u, if all required implicit conversions exist; if not,
the call is ill-formed.
** Requestor: Jerry Schwarz, John Skaller
** Owner: Skaller
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-018
** Title: auto_ptr::reset to self
** Sections: [lib.auto.ptr.members]
** Status: active
** Description:
a.reset(p) where a.px == p would delete a.px,
which would be, of course, a bad thing to do.
Operator= has the same problem but is specified
in terms of reset() so presumably the solution for
reset() will also apply to operator=.
** Proposed Resolution
One of:
(1) a.px != p is a precondition for reset().
a.px != r.px is a precondition for operator=.
(2) a.reset(p) with a.px == p has no effect.
a = d with a.px == d.px has no effect.
I lean slightly toward (2) but don't have a strong
preference.
** Requestor: Beman Dawes
** Owner: Beman Dawes
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-019
** Title: no default ctors on many lib classes
** Sections: [many]
** Status: active
** Description:
Many of the classes defined in the WP, such as
pointer_to_binary_function<> cannot be stored
in (e.g.) a multiset because it requires a
default constructor for anything in it.
** Discussion:
We could give these things default constructors,
or work on allowing things without to be put into
stored in standard containers, or both.
** Proposed Resolution
[none, yet.]
** Requestor: Judy Ward
** Owner:
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-020
** Title: make_pair should go?
** Sections: [lib.pairs]
** Status: active
** Description:
Mike Lijewski says:
There isn't much difference between writing
return pair<const int, double>(5, 3.14159);
and
return make_pair<const int>(5, 3.14159);
I've come to the conclusion that this function should be removed from
the WP. It isn't needed, yet more importantly it isn't fully
functional; it does not provide all the function of a direct
constructor call to pair<>. [make_pair<>() cannot deduce the
constness of its parameters.]
It seems counter-productive to supply a function that can't build
pairs suitable for insertion into maps or multimaps, when these
containers are likely to be the only place where casual users of the
Standard Library need to explicitel use pairs.
** Discussion:
An alternative would be to add new members to map and multimap
to reduce the need for users to construct pairs. (Particularly,
overloading member insert().)
** Proposed Resolution:
** Requestor: Mike Lijewski <lijewski@roguewave.com>
** Owner:
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-021
** Title: should pair<> have a default constructor?
** Sections: [lib.pairs]
** Status: active
** Description:
The class template pair<> doesn't have a default constructor.
Many think it should. The public domain HP release had it.
** Proposed Resolution:
Add to [lib.pairs], the constructor
pair();
Effects: it initializes its members as if implemented:
"pair::pair() {}".
Note: pair<int,int>() is equal to pair<int,int>(0,0).
As an alternative, we can say:
Effects: it initializes its members as if implemented:
"pair::pair() : first(), second() {}".
Note: pair<int,int>() is not necessarily equal to pair<int,int>(0,0).
** Requestor: Mike Lijewski <lijewski@roguewave.com>
** Owner:
---------------
** Work Group: Library: Utilities Clause 20
** Issue Number: 20-022
** Title: unary_compose and binary_compose missing.
** Sections: [lib.utilities]
** Status: active
** Description:
The templates unary_compose and binary_compose do not appear
in the WP.
** Proposed Resolution:
[to be written]
** Requestor: Judy Ward <j_ward@zko.dec.com>
** Owner:
---------------
Closed issues:
** Issue Number: 20-001
** Title: Allocator needs operator ==
** Resolution: passed
** Issue Number: 20-002
** Title: allocator::types<> has no public members
** Resolution: passed
** Issue Number: 20-003
** Title: Allocator requirements incomplete
** Resolution: passed
** Issue Number: 20-004
** Title: allocator parameter "hint" needs hints on usage
** Resolution: passed
** Issue Number: 20-005
** Title: Default allocator member allocate<T>() doesn't "new T".
** Resolution: passed
** Issue Number: 20-006
** Title: allocator::max_size() not documented
** Resolution: passed
** Issue Number: 20-008
** Title: construct() and destroy() functions should be members
** Resolution: passed
** Issue Number: 20-009
** Title: Allocator member init_page_size() no longer appropriate.
** Resolution: closed
** Issue Number: 20-011
** Title: specialization of allocator::types<void> incomplete
** Resolution: passed
** Issue Number: 20-012
** Title: get_temporary_buffer has extra argument declared
** Resolution: passed
** Issue Number: 20-013
** Title: get_temporary_buffer semantics incomplete
** Resolution: passed
** Issue Number: 20-015
** Title: class unary_negate ill-specified.
** Resolution: passed
** Issue Number: 20-016
** Title: binder{1st|2nd}::value types wrong.
** Resolution: passed