Boost logo

Boost :

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

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at