From: "Howard Hinnant" <[EMAIL PROTECTED]>
> On Sunday, November 17, 2002, at 10:01 AM, Peter Dimov wrote:
>
> > From: "David Abrahams" <[EMAIL PROTECTED]>
> >>> 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
