Re: [boost] [shared_array] Why not in C++11 ?

Subject: Re: [boost] [shared_array] Why not in C++11 ?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-07-08 06:39:45

On Mon, Jul 8, 2013 at 1:49 PM, Rob Stewart <robertstewart_at_[hidden]> wrote:
> On Jul 8, 2013, at 4:21 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>
>> Size could be implied from other components around the pointer. E.g.
>> you could have multiple buffers of the same size encapsulated in a class that maintains this invariant.
>
> That's a very limiting view.

Why? I just suggested a use case where embedded size is not needed.

>> In fact, you don't share anything here, so by using vector you express your intent more clearly. You may argue about copying the buffer contents or asynchronous operation execution, but move semantics helps here.
>
> Move semantics won't help with async use cases.

Why not? You can move a vector into a bind function, fill it and then
move/swap out of the handler.

>>> The buffer object no longer behaves like a regular shared_ptr<>, but behaves very much like an array, and for all intents and purposes, it is an array, it is a buffer!  What I mean is, it is not a pointer anymore, and you can no longer do this:
>>>
>>>        buffer-> ????   // what can the pointer operator be used for ????
>>
>> The operator-> would work like with any raw pointer - it would return a pointer to the first element of the array.
>
> His point is that, without at least knowing the capacity, code called with a shared_ptr<T[]> cannot use it because the extent is unknown.

You mean that the pointer may refer to a zero-sized array? Yes, that
is UB, just as well as with the raw pointers.

>> Specializing the interface based on the template argument is not intuitive, IMHO.
>
> We have that already with the subscript operator.

That is not counterintuitive because you can apply the operator to the
raw pointer.