Re: [boost] On shared_xxx

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-03 22:35:42

----- Original Message -----
From: "Greg Colvin" <gcolvin_at_[hidden]>

> It seems that by adding one constructor to shared_ptr and shared_array
> we could satisfy Dave's needs:
>
>    shared_ptr::shared_ptr(
>       T* object, shared_counter_base* counter=shared_ptr_counter);
>
>    shared_array:shared_array(
>       T* array, shared_counter_base* counter=shared_array_counter);
>
> Where shared_counter_base is something like:
>
>    class shared_counter_base {
>    protected:
>       long count;
>       void* object;
>       void (*destroy)(void*);
>    public:
>       shared_counter_base(): count(0),object(0),destroy(0) {}
>       void increment() { ++count; }
>       void decrement() {
>          if (!--count)
>             assert(destroy), destroy(object);
>       }
>    };
>
> It is the job of the destroy function to release storage for the
> shared object and itself when the count goes to zero.  I use a
> pointer-function rather than a virtual destructor so as safe a
> smidgen of time and so as not to forclose options for how the
> counter is allocated.
>
> Then Dave can derive his own counter class and arrange for his array
> allocator to stash the counter at the head of his array.
>
> Whether this is easier to do than to write his own class I can't say.
> It would be a slightly larger header than needed for a custom
> implementation.  One advantage to this approach, if it matters, is
> that the rest of Dave's code can traffic in shared_array without
> caring about the array allocator.

Does this approach require storing a separate pointer to the counter in the
shared pointer?
That's something I don't want to pay for.

Taking a step back, we can come up with any number of designs, but shouldn't
we talk about what the designs should accomplish first?

-Dave