Re: [boost] shared_ptr deleter introspection?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-20 07:53:39

From: "David Abrahams" <dave_at_[hidden]>

[get_deleter]

> I think that considering the alternatives require:
>
>    1. Periodic map sweeps (we might as well be doing GC ;->), or
>
>    2. Solving the constructor forwarding problem for tacking on
>       additional data to the pointed-to class
>
> IMO it's worth giving serious consideration to deleter
> introspection.

Looks like I have to apply my mad "diligent reader" skills to the above.

Problem statement:

A library lib1 contains the following functions:

shared_ptr<X> lib1::f();
lib1::g(shared_ptr<X> p);

The library needs to communicate a piece of private data from f to g, i.e.
lib1::g needs to determine whether p has been created by lib1::f, and if so,
what is the private data associated with p.

Solution #1: put the private data in X.

lib1::f can return a shared_ptr<X> that stores an instance of a class Ximpl,
derived from X, that contains the private data. lib1::g can use
dynamic_cast<Ximpl*> to detect the presence of private data.

Problem: if X is not defined by lib1, transparently wrapping it in a Ximpl
requires forwarding constructor arguments from Ximpl's constructors to X's
constructors (X may be noncopyable.)

Solution #2: use a map<weak_ptr<void>, Data>.

lib1::f can use the generated shared_ptr<X> as a key to a global map,
storing the private data there. lib1::g can use p to find the associated
data in the map.

This solution is more general since it doesn't require lib1 to create the
shared_ptr<X> itself. Even external shared_ptr instances can have associated
private data.

Problem: the map needs to be periodically swept to eliminate expired
weak_ptr keys.

Solution #3: use the two-argument shared_ptr constructor and put the private
data in the deleter.

Problem: given a shared_ptr, there is currently no way to obtain a reference
to the deleter, if there is one.

Correct?

Now the interface questions.

Q: Why a free function? A: a member would require the p.template
get_deleter<D>() syntax when p is dependent on a template parameter.

Q: Why use a generic 'get_deleter' name for the free function? A: ???