Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-11-06 06:15:35
On Sat, Nov 5, 2011 at 6:53 PM, Andrey Semashev
>> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk