[libcxx-commits] [PATCH] D94544: [libc++] NFCI: Refactor allocator_traits

Mon Jan 18 11:38:52 PST 2021

ldionne added inline comments.

================
Comment at: libcxx/include/__memory/allocator_traits.h:273
+    template <class _Ap = _Alloc, class = void, class =
+        _EnableIf<!__has_allocate_hint<_Ap, size_type, const_void_pointer>::value> >
+    _LIBCPP_NODISCARD_AFTER_CXX17 _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX17
----------------
zoecarver wrote:
> Why the has_allocate_hint? Is that just for the deprecation warnings? Is it worth just taking the deprecation warnings so we could have just one implementation? For compile-time if nothing else. Those SFINAE checks are slow. 
Do you mean that you'd prefer doing the check for whether `a.allocate(n, hint)` is supported inline in the template declaration?

If you're asking why we call `allocate` with a hint at all, it's because we must. If a user-defined allocator does something special when called with a hint, we need to maintain that.

================
Comment at: libcxx/include/__memory/allocator_traits.h:296
+    static void construct(allocator_type&, _Tp* __p, _Args&&... __args) {
 #if _LIBCPP_STD_VER > 17
+        _VSTD::construct_at(__p, _VSTD::forward<_Args>(__args)...);
----------------
zoecarver wrote:
> I don't really understand why we have two implementations here. This isn't a constexpr context, so they both do the same thing.
`construct_at` isn't provided before C++20.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94544