This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 220.127.116.11 [allocator.requirements] Status: New Submitter: Billy O'Neal III Opened: 2018-09-07 Last modified: 2018-12-16
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with New status.
In annotating things required to be called by ~vector, Casey pointed out that several operations I guarded with noexcept aren't actually mandated by the standard to be noexcept. However, the STL, and more specifically here, containers, consider inability to destroy an element an unrecoverable condition. This is evidenced for the whole STL by 18.104.22.168 [res.on.exception.handling]/3 "Every destructor in the C ++ standard library shall behave as if it had a non-throwing exception specification.".As a result, allocator::destroy and fancy pointer operations must be non-throwing for valid input, or the containers don't make any sense. This is obvious for things like vector::~vector, but less obviously the containers rely on these guarantees whenever inserting more than one element, etc. Moreover, we too narrowly specify the domain of the pointer_traits::pointer_to requirement in the Cpp17Allocator requirements, because any node-based container that uses container-internal sentinel nodes needs to be able to form pointers to said sentinel nodes; that operation must also be non-throwing.
[2018-09 Reflector prioritization]
Set Priority to 3
This wording is relative to N4762.
Modify 22.214.171.124 [allocator.requirements], Table 32 "Descriptive variable definitions" as indicated:
Table 32 — Descriptive variable definitions Variable Definition … YY the type allocator_traits<Y> … y a value of type 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.
n a value of type XX::size_type. …
Modify 126.96.36.199 [allocator.requirements], Table 33 "Cpp17Allocator requirements" as indicated:
Table 33 — Cpp17Allocator requirements Expression Return type Assertion/note
Default … pointer_traits<
X::pointer same as p … a.destroy(c) (not used) Effects: Destroys the object at c
Modify 188.8.131.52 [allocator.requirements], p5, as indicated:
-5- An allocator type X shall satisfy the Cpp17CopyConstructible requirements (Table 26). The X::pointer, X::const_pointer, X::void_pointer, and X::const_void_pointer types shall satisfy the Cpp17NullablePointer requirements (Table 30). No constructor, comparison function, copy operation, move operation, or swap operation on these pointer types shall exit via an exception. X::pointer and X::const_pointer shall also satisfy the requirements for a random access iterator (184.108.40.206 [random.access.iterators]) and of a contiguous iterator (23.3.1 [iterator.requirements.general]) .
Modify 220.127.116.11 [allocator.traits.members], as indicated:
template<class T> static void destroy(Alloc& a, T* p);
-6- Effects: Calls a.destroy(p) if that call is well-formed; otherwise, invokes p->~T().