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:
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk