Re: [boost] Rationale for shared_ptr/array including both ptr to control and ptr to data in class

Subject: Re: [boost] Rationale for shared_ptr/array including both ptr to control and ptr to data in class
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-09-26 10:49:37

On Mon, Sep 26, 2011 at 3:20 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Olaf van der Spek wrote:
>>
>> Ah. BTW, why doesn't shared_array provide size()?
>> IMO it'd be quite useful to have.
>
> The obvious answer, that it doesn't have this information, has already been
> given, but it's not enough; you could legitimately ask why shared_array
> doesn't have it, that is, why its constructor doesn't take a size in
> addition to the pointer.

make_shared_array (not implemented yet) would also have the info.

> The answer is, well, historical reasons. While the current shared_ptr allows
> you to easily implement a sized shared_array by storing the size in a
> deleter, when shared_array was first designed, this was not the case.
> shared_array was kept a simple reference-counted wrapper over new T[].
> shared_ptr then evolved considerably, and shared_array has failed to keep
> up. So here we are. :-)

So, could 'this' be 'fixed'? ;)
Not having size() and others like begin, end, etc, is a serious drawback IMO.

P;af