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