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