This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.
Section: 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 calling YY::allocate, or else nullptr.
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 |