Re: [boost] RFC: A better shared_array

Subject: Re: [boost] RFC: A better shared_array
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-10-19 15:26:41

On Wed, Oct 19, 2011 at 9:05 PM, Rhys Ulerich <rhys.ulerich_at_[hidden]> wrote:
>> Hmm, I thought mine was really smart already. :p
>
> It was, but it seemed like you wanted a shared_array and that you

I do.

> subclassed iterator_range as only an implementation detail.  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.

>> Where did the (size_t) and (..., shared_ptr<void>) constructors go?
>
> // Free function
> template< class T >
> shared_range<T> make_shared_range(::std::size_t sz);
>
> // Constructor
> shared_range(const ::boost::shared_array<T>& p, ::std::size_t sz)
>
>>> I've opted to
>>> move resource allocating operation's like Olaf's shared_array2(size_t)
>>> constructor into free functions in the spirit of make_shared and
>>> allocate_shared.
>>
>> Ah. Why? shared_array<char> v(10) (like vector) would be neater.
>
> I agree, but it seems that boost::smart_XXX constructors don't
> allocate memory.  That functionality gets left to free functions.
> Just following the existing pattern.

That's not a good reason. ;)

>>> typedef T element_type;
>>> advance_begin()
>>
>> Doesn't iterator_range take care of that?
>
> It does, but it returns a reference to iterator_range.  I wanted
> shared_range::advance_begin() to return a reference to shared_range.

Ah.

>> 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?

> 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();

> implementation's private smart pointer.  The choice is documented in
> the third paragraph under  "IMPLEMENTATION COMMENTS".

Will have a look.

-- 
Olaf