[libcxx-commits] [PATCH] D81133: Use allocator_traits to consistently allocate/deallocate/construct/destroy objects in std::any
Eric Fiselier via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Thu Jun 4 01:34:56 PDT 2020
EricWF added a comment.
`std::any`, like other type erased types, cannot follow the allocator model and therefore does not use allocators.
The behavior of a user-provided specialization of `allocator` or `allocator` traits cannot differ meaningfully from the current code.
So I don't understand what the observable difference is here. Could you add a test?
================
Comment at: libcxx/include/any:370
static _Tp& __create(any & __dest, _Args&&... __args) {
- _Tp* __ret = ::new (static_cast<void*>(&__dest.__s.__buf)) _Tp(_VSTD::forward<_Args>(__args)...);
+ typedef allocator<_Tp> _Alloc;
+ typedef allocator_traits<_Alloc> _ATraits;
----------------
Can `std::allocator` have behavior that observably differs from this code? (which is just the default std::allocator inlined).
================
Comment at: libcxx/include/any:382
static void __destroy(any & __this) {
- _Tp & __value = *static_cast<_Tp *>(static_cast<void*>(&__this.__s.__buf));
- __value.~_Tp();
+ typedef allocator<_Tp> _Alloc;
+ typedef allocator_traits<_Alloc> _ATraits;
----------------
Is it the case that the allocator which allocated this memory is always equal to a default constructed allocator? If not, this is UB.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D81133/new/
https://reviews.llvm.org/D81133
More information about the libcxx-commits
mailing list