Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-30 20:16:26


From: Dave Abrahams <abrahams_at_[hidden]>
> > I am thinking that some details of the shared_ptr implementation,
> > such as the deallocation function, should be abstracted into a
> > class with virtual functions, an instance of which can be passed
> > into the shared_ptr constructor, and the rest handled either by
> > derivation from shared_ptr (for adding or hiding operations) or
> > conditional compilation (for thread safety on various systems).
>
> Oh, I have always assumed something more like this:
>
> namespace boost {
>
> template<class T> struct deallocator
> {
> };
>
> template<class T> class deallocator<T*>
> {
> void deallocate()(T p) { delete p; }
> };
>
> }
>
> The user then specializes boost::deallocator<T> for her own type when it
> needs special treatment (yes, this means you need to wrap ints and other
> basic types in a struct unless you'll have only one way to deallocate ints.
> so what?)

If you can do this on per-type basis, then why not just override
operator delete for that type?

> Then you get fancy with the empty base optimization to store a deallocator
> object somewhere in the smart pointer. This avoids all virtual function
> overhead.
>
> If you don't wnat to get all fancy-like, you can construct the deallocator
> on-the-fly at deallocation time, or you can just use a template function for
> that matter.

So I take it you are not buying my concerns about recompiling everything
when you change the deallocation specialization?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk