On 29/01/2020 17:56, Glen Fernandes wrote:
On Tue, Jan 28, 2020 at 10:51 PM Gavin Lambert wrote:
On 25/01/2020 01:21, Glen Fernandes wrote:
Heap storage, fixed size at runtime: allocate_unique<T[]>(alloc, size, ...)
Gives users everything they need for buffers. (They don't need a Container that is copyable).
Not quite. These keep the storage pointer and the storage size separately,
Yes quite. i.e. What you believe is not true boost::allocate_unique.
i.e. For auto p = boost::allocate_unique<T[]>(a, n); assert(p.get().size() == n);
This is because the unique_ptr stores a pointer adaptor around the Allocator::pointer which also stores the size.
So the pointer and size are stored together in the unique_ptr result.
To get the plain Allocator::pointer out of it you can use p.get().ptr()
Or, for example, p.release().ptr() for someone who wants to manage it themselves.
https://www.boost.org/doc/libs/1_72_0/libs/smart_ptr/doc/html/smart_ptr.html... claims that it returns a std::unique_ptr<T[], D>. This seems incompatible with what you're saying above. (There is also no mention of ptr() or size() there.) If you're returning some mysterious other type to inject size information, isn't this going to become subject to slicing?