Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor

Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-11-06 06:15:35

On Sat, Nov 5, 2011 at 6:53 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
>> I think I already asked you, but:
>> Why does shared_ptr / make_shared do it that way and does that reason
>> apply to shared_array?
>
> I don't know the original reasons but in my understanding external allocation

Might be a good idea to get to know the reasons before you copy the design.

> is more flexible. One can control where and how the pointed object is
> allocated and constructed. In case of shared_ptr, one can also specify the
> deleter at the allocation place. All this simplifies implementation of
> different patterns, such as factory or singleton.

It's not a xor. Supporting a (size_t) constructor does not mean you
can't (also) implent make_ and allocate_ functions.

> Since array pointers are also pointers, it is straightforward for them to
> follow the interface guideline started by shared_ptr.
>
>> Isn't it kinda like a shared container (except it doesn't know it's size
>> etc)?
>> I'd also like to see a shared_array that knows it's size, this is a
>> first step towards that.
>
> I'd like to repeat that pointers are not containers. Their purpose and

It's about shared_array. Arrays are pointers are not synonyms.

> application are quite different, and hence there's no reason to follow
> containers interface. If you want things like size, iterators and built-in
> memory management, just use containers. And if you want a shared container,
> just use shared_ptr with a container.

Stop kidding me please. shared_ptr<vector> is totally unsuitable.

-- 
Olaf