On Sat, Nov 5, 2011 at 6:53 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
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
Might be a good idea to get to know the reasons before you copy the design.
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.
It's not a xor. Supporting a (size_t) constructor does not mean you can't (also) implent make_ and allocate_ functions.
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
It's about shared_array. Arrays are pointers are not synonyms.
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.
Stop kidding me please. shared_ptr<vector> is totally unsuitable. -- Olaf