Re: Yet Another Container: DynamicArray

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-01-29 05:27:38

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#allocate_unique

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?