[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