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

Subject: Re: [boost] [shared_array] Why not in C++11 ?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-07-09 05:29:41

On Jul 8, 2013, at 6:39 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> 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.

You were using it to suggest the size was not needed for any use case, or at least that's how I read it.

>>> 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.

That depends upon the available interface, I suppose.

>>>> 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.

Without the extent, one cannot safely read or write anything.

>>> 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.

Granted, but a deleter is counterintuitive, relative to raw pointers, too. The class name begins with "smart" for a reason.

___
Rob

(Sent from my portable computation engine)