Allocator
's allocate
functionSection: 16.4.4.6 [allocator.requirements] Status: C++14 Submitter: Daniel Krügler Opened: 2012-03-05 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with C++14 status.
Discussion:
According to Table 28 — "Allocator requirements", the expression
a.allocate(n, u)
expects as second argument a value u
that is described in Table 27 as:
a value of type
YY::const_pointer
obtained by callingYY::allocate
, or elsenullptr
.
This description leaves it open, whether or whether not a value of type YY::const_void_pointer
is
valid or not. The corresponding wording in C++03 is nearly the same, but in C++03 there did not exist the concept of
a general void_pointer
for allocators. There is some evidence for support of void pointers because
the general allocator_traits
template declares
static pointer allocate(Alloc& a, size_type n, const_void_pointer hint);
and the corresponding function for std::allocator<T>
is declared as:
pointer allocate(size_type, allocator<void>::const_pointer hint = 0);
As an additional minor wording glitch (especially when comparing with the NullablePointer
requirements imposed on
const_pointer
and const_void_pointer
), the wording seems to exclude lvalues of type
std::nullptr_t
, which looks like an unwanted artifact to me.
[ 2012-10 Portland: Move to Ready ]
No strong feeling that this is a big issue, but consensus that the proposed resolution is strictly better than the current wording, so move to Ready.
[2013-04-20 Bristol]
Proposed resolution:
This wording is relative to N3376.
Change Table 27 — "Descriptive variable definitions" in 16.4.4.6 [allocator.requirements]:
Variable | Definition |
---|---|
u
|
a value of type YY::const_pointer obtained by calling YY::allocate , or else
nullptr XX::const_void_pointer obtained by conversion from a result
value of YY::allocate , or else a value of type (possibly const) std::nullptr_t .
|