Re: [boost] RFC: A better shared_array

Subject: Re: [boost] RFC: A better shared_array
From: Rhys Ulerich (rhys.ulerich_at_[hidden])
Date: 2011-10-19 17:42:06

>> This
>> implementation is intended as a public descendent of iterator_range
>> moreso than a shared_array.
>
> Ranges don't own anything. A shared_range still sounds wrong.

Dunno what more to say.  It's a mashup of a shared_array and an
iterator_range.  The options were shared_iterator (wrong),
shared_range (eh), array_iterator (wrong), and array_range (wrong).
"shared_block" sounds better but "block" is tremendously ambiguous.
And the concept implemented really is a range.  So, "shared_range".

>>> Where did data() go?
>>
>> This is the biggest departure from your implementation and one that
>> stems from wanting a "shared iterator_range" more than a "shared_array
>> with a length".  iterator_range has an operator= taking any
>
> Isn't it more like a ptr_range anyway?

I don't follow this comment.  Is there a ptr_range somewhere that I
can neither Google nor grep?  My coffee's wearing off...

>> ForwardRange.  To have shared_range::operator= logically accomplish
>> the same thing, I opted for it copy a ForwardRange but not to perform
>> any shared resource ownership.  In that case, the shared_array
>> shared_range::p_ has no well-defined semantic (since nothing's
>> managed) which makes data() (among other things) not well-defined
>> concepts.  Consequently, no data() member nor any access to the
>
> data() would just return empty() ? NULL : &front();

You just implemented begin().  It's a range. :)

- Rhys