[libcxx-commits] [PATCH] D93071: [libc++] NFCI: Implement make_shared as allocate_shared with std::allocator

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Dec 16 13:31:13 PST 2020

ldionne added a comment.

In D93071#2456926 <https://reviews.llvm.org/D93071#2456926>, @glenjofe wrote:

> In D93071#2447152 <https://reviews.llvm.org/D93071#2447152>, @ldionne wrote:
>> @glenjofe  Taking a chance to tag you here since you've been involved in most changes to `std::shared_ptr` (and Peter Dimov does not appear to be on Phabricator). Was the intent that `make_shared` could be implemented via `allocate_shared` with the default allocator, or am I missing something subtle?
> My implementation Boost's does: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/make_shared_array.hpp
> i.e. Those `boost::make_shared` overloads just call `boost::allocate_shared` with `boost::default_allocator`
> It would be nice to do specify `std::make_shared` overloads in the standard as just returning `std::allocate_shared` with `std::allocator` but we would need wording for that.
> As pointed out users can specialize `std::allocator` and some even specialize `std::allocator_traits`.

Thanks for the clarification of intent! I believe it's a reasonable implementation -- I can hardly imagine someone relying on `std::allocator` *not* being used by `std::make_shared`. Or at least, that would imply a very specific way of reading of the standard.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list