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-05 13:19:26

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?

>> Code simplicity
>>
>>  // typedef boost::shared_array<unsigned char> shared_data;
>> 1. shared_data d0(256);
>> 2. BOOST_AUTO(d1, make_shared_data(256));
>> 3. auto d2 = make_shared_data(256);
>>
>> 2 is much more verbose than 1, 3 is also more verbose than 1
>
> All three are simple, readable, and straightforward.  1 looks like a

Don't you consider 1 more simple and readable than 2?
Does something like Visual Studio Intellisense work with 2?

> container (but it is not a container).  2 and 3 look like what I'd

Isn't it kinda like a shared container (except it doesn't know it's size etc)?

> expect given the existing smart pointer APIs.

> Re: verbosity.  We've all collectively spent more keystrokes
> responding to this thread than one will likely save in code
> abbreviated by the proposed feature.
>
> Olaf, beyond saving some keystrokes, what genuinely new capability
> does this proposed feature add?

Readability is more important than writability.
I'd also like to see a shared_array that knows it's size, this is a
first step towards that.

Olaf