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

Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Rhys Ulerich (rhys.ulerich_at_[hidden])
Date: 2011-11-05 12:45:00

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

> 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
container (but it is not a container).  2 and 3 look like what I'd
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?

- Rhys