[libcxx-commits] [PATCH] D120996: [libc++] Remove extension to support allocator<const T>

Arthur O'Dwyer via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Sat Mar 5 18:43:58 PST 2022


Quuxplusone accepted this revision as: Quuxplusone.
Quuxplusone added a comment.

This is the sort of thing to alert libc++-vendors about, right?



================
Comment at: libcxx/include/__memory/allocator.h:72-73
 {
     static_assert(!is_volatile<_Tp>::value, "std::allocator does not support volatile types");
+    static_assert(!is_const<_Tp>::value, "std::allocator does not support const types");
 public:
----------------
Nit: Maybe swap these lines to alphabetize them? (also to put the shorter and more common cv-qualifier first)


================
Comment at: libcxx/include/__memory/shared_ptr.h:290-292
+        using _TpAlloc = typename __allocator_traits_rebind<_Alloc, remove_cv_t<_Tp>>::type;
         _TpAlloc __tmp(*__get_alloc());
         allocator_traits<_TpAlloc>::construct(__tmp, __get_elem(), _VSTD::forward<_Args>(__args)...);
----------------
Pre-existing: Why do we rebind the allocator at all? `construct` is supposed to work on any allocator in the same family, isn't it? (IIRC, it deduces the type-to-construct from the pointer type of `__get_elem()`, not from the type of `__tmp`.) Is this a QoI thing, or just "historical reasons"?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120996/new/

https://reviews.llvm.org/D120996



More information about the libcxx-commits mailing list