Re: [boost] On shared_xxx

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-03 10:28:20

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> It seems to me that you needed a type that
>
> * is like shared_ptr, but with an intrusive count, i.e. has reference
> semantics;
> * is a dynamically-allocated array, i.e. has a constructor like
> my_shared_array(int n);
> * remembers this 'n', i.e. has a size() member.
>
> This is something that is halfway between shared_array and vector. In a
> situation like this I'd have created a shared_ptr<vector<T> >-based
> prototype first. I assume that you didn't like the performance of the
> prototype.

It's premature optimization on my part, although I'm pretty sure it's
justified. I am going to create many thousands of these, all of the same
length (determined at runtime), and operate on them in the core of my
algorithms. I don't want to pay for the extra indirection, allocation
overhead, reserve pointers in the vector, etc.

> Perhaps I've misunderstood, but I think that a policy-based design would
> likely allow you to specify interface and behavior, but not provide the
> tools necessary to achieve the low-level customizations needed for this
kind
> of performance-tuning. I may be wrong.

It seems clear to me that it could. If we took the Iterator Adaptors library
as a model, the deallocation behavior would be designed into the policies
class, and this particular smart pointer would store the allocation size
there as well. Using compressed_pair to store the policies would prevent
storage overhead in case it was an empty class.

In fact, I can easily see how iterator_adaptor and ptr_adaptor could draw on
a common functional core (dereferenceable_adaptor).

-Dave