Subject: Re: [boost] RFC: A better shared_array
From: Rhys Ulerich (rhys.ulerich_at_[hidden])
Date: 2011-10-19 17:42:06
>> 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. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk