From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-20 07:53:39
From: "David Abrahams" <dave_at_[hidden]>
> 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
Looks like I have to apply my mad "diligent reader" skills to the above.
A library lib1 contains the following functions:
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
Problem: the map needs to be periodically swept to eliminate expired
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.
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: ???
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk