Re: [boost] shared_ptr deleter introspection?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-18 08:11:32

From: "Howard Hinnant" <hinnant_at_[hidden]>
> On Sunday, November 17, 2002, at 10:01  AM, Peter Dimov wrote:
>
> > From: "David Abrahams" <dave_at_[hidden]>
> >>> I haven't encountered a need to inspect the deleter yet... what
> > interface
> >>> are you suggesting?
> >>
> >> How about:
> >>
> >>     // attempt to extract a deleter of type D
> >>     D* d = boost::get_deleter<D>(p);
> >>     if (d)
> >>     {
> >>         // that was the deleter type used.
> >>     }
>
> Why is it important that the type of the deleter be able to vary at
> runtime?  It seems to me that this problem could be more elegantly and
> efficiently solved if the shared_ptr's deleter type were fixed at
> compile time.

In this particular context or in general? In general, the deleter is not
part of shared_ptr's type to abstract allocation details away from the
client.

shared_ptr<X> create(args...); // in a DLL

You can change the way the DLL allocates memory for the X, or return
differently allocated X'es depending on args, or even sometimes return a
static X instance. The client need not recompile (or even relink in the DLL
case).

Or consider the case with two libraries:

shared_ptr<X> lib1::create();

lib2::f(shared_ptr<X> px);

Even if you don't mind recompiling when lib1 changes the way it allocates
the X, if the deleter is part of the returned shared_ptr's type, you'll no
longer be able to pass it to lib2.