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?