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