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

Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-05 13:53:15

On Saturday, November 05, 2011 18:19:26 Olaf van der Spek wrote:
> On Sat, Nov 5, 2011 at 5:45 PM, Rhys Ulerich <rhys.ulerich_at_[hidden]> wrote:
> >>> Allocating
> >>> things is not smart pointers' business and I'd like to keep it that
> >>> way.>> 
> >> What principle/rule says it should be done out-of-class? STL
> >> containers like string and vector do their own allocation.
> > 
> > Tradition coming from the smart pointer API.  It seems fitting that
> > smart pointer API should continue following its own traditions.
> 
> 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 
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.

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