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 15:05:21

Hi Olaf,

First, thanks for checking out the implementation.

>>>>>> The current shared_array doesn't keep track of size. This greatly
>>>>>> decreases it's usefulness. So I wrote a variant that does:
>>>>>> http://pastebin.com/wkdLVqM1

>> I extended the spirit of Olaf's shared_array2 implementation quite a
>> bit so that it really is a smart resource-managing iterator_range
>> called shared_range. The implementation (with documentation) and
>> tests are up at https://github.com/RhysU/shared_range.

> Hmm, I thought mine was really smart already. :p

It was, but it seemed like you wanted a shared_array and that you
subclassed iterator_range as only an implementation detail.  This
implementation is intended as a public descendent of iterator_range
moreso than a shared_array.

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

>> Olaf, I've added your name to the implementation header in
>> shared_range.hpp.  Please let me know if that's not okay with you.
>
> That's fine.

Great.

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

> 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
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
implementation's private smart pointer.  The choice is documented in
the third paragraph under  "IMPLEMENTATION COMMENTS".

- Rhys