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
> 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
>> 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;
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk