diff options
author | Jonathan Wakely <jwakely@redhat.com> | 2021-08-03 14:00:47 +0100 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2021-08-03 15:30:36 +0100 |
commit | 13a1ac9f6f700f4e214fcc83b122a4a405c6b13d (patch) | |
tree | a09d223b37dea4182bfd8a16f7ec75a639c4553c /libgcc | |
parent | 9bd87e388724baab9597ef232ea7e855c99eb7d7 (diff) | |
download | gcc-13a1ac9f6f700f4e214fcc83b122a4a405c6b13d.zip gcc-13a1ac9f6f700f4e214fcc83b122a4a405c6b13d.tar.gz gcc-13a1ac9f6f700f4e214fcc83b122a4a405c6b13d.tar.bz2 |
libstdc++: Specialize allocator_traits<pmr::polymorphic_allocator<T>>
This adds a partial specialization of allocator_traits, similar to what
was already done for std::allocator. This means that most uses of
polymorphic_allocator via the traits can avoid the metaprogramming
overhead needed to deduce the properties from polymorphic_allocator.
In addition, I'm changing polymorphic_allocator::delete_object to invoke
the destructor (or pseudo-destructor) directly, rather than calling
allocator_traits::destroy, which calls polymorphic_allocator::destroy
(which is deprecated). This is observable if a user has specialized
allocator_traits<polymorphic_allocator<Foo>> and expects to see its
destroy member function called. I consider explicit specializations of
allocator_traits to be wrong-headed, and this use case seems unnecessary
to support. So delete_object just invokes the destructor directly.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/memory_resource (polymorphic_allocator::delete_object):
Call destructor directly instead of using destroy.
(allocator_traits<polymorphic_allocator<T>>): Define partial
specialization.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions