Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor

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
<andrey.semashev_at_[hidden]> wrote:
> 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
> containers.

shared_ptr doesn't provide operator[], shared_array does. So your
statement is clearly false.

char a[128]
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.
>
> Why?

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.

-- 
Olaf