Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-11-06 16:06:41
On Sun, Nov 6, 2011 at 2:19 PM, Andrey Semashev
> On Sunday, November 06, 2011 12:15:35 Olaf van der Spek wrote:
>> On Sat, Nov 5, 2011 at 6:53 PM, Andrey Semashev
>> It's not a xor. Supporting a (size_t) constructor does not mean you
>> can't (also) implent make_ and allocate_ functions.
> Why would we need the ambiguous constructor then? Just do "the right thing"
> from the start.
Because some people prefer the simpler syntax.
>> >> 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.
> Actually, they are. The only difference is the deallocation method. They stop
> being similar when you add advanced features I mentioned, then arrays become
shared_ptr doesn't provide operator, shared_array does. So your
statement is clearly false.
char* p = a;
Is sizeof(a) == sizeof(p)? Array and pointer were synonyms, right?
>> > 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.
For example, I can't put a memory mapped file into a vector. I don't
(always) want the memory to be initialized. I don't want two
allocations. I do want sub arrays.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk