[boost] Re: Smart Pointers - (many) thanks and (some)questions

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-12-30 23:19:16

Greg wrote that I wrote:
>> 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?

Simple answer: the type might not be a pointer.
I assumed your motivation for the virtual function proposal was to be able
to manage non-memory resources, but the more I look at it, the less sense it
makes. What do you get when you dereference a smart pointer which isn't
holding a T*? It's oxymoronic. Maybe just moronic ;)

So why _do_ you want to use virtual functions to customize deallocation?

>> 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?

I guess not, but maybe I haven't considered the scenarios carefully. Perhaps
you'd like to give some examples?

I can see the value of using polymorphism for deallocation at least in the
case of shared_ptr: If you keep the deallocator with the count, a shared_ptr
just becomes a way to maintain the reference count, and there's full
assignment compatibility between shared_ptrs regardless of how the objects
they refer to will be deallocated.

template <class T>
void call_delete(T* p) { delete p; }

template <class T>
class shared_ptr { ...
  shared_ptr(T* const p, void(*deleter)(T*) = call_delete<T>);
  ...
};

The downside is that you pay for an extra function pointer per shared
object. I don't think we'd want to incur that sort of cost for something
like auto_ptr, but it may be acceptable for shared_ptr.

-D