On Sat, Nov 5, 2011 at 5:45 PM, Rhys Ulerich <rhys.ulerich@gmail.com> 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