Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-17 13:02:40


"Peter Dimov" <pdimov_at_[hidden]> writes:

> 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.
>> }
>
> Hmm. Do you really need access to the deleter, or only information about the
> deleter type used? Or do you actually need an answer to the question "did I
> create this shared_ptr?"

I need the deleter. The deleter, if it's one of mine, contains a
pointer to the actual owning Python object. When converting these
shared_ptrs back to Python, I want to return that same object,
preserving object identity. The alternative is to build a new Python
object around the shared_ptr, but that has many drawbacks, including
the fact that Python attributes and the most-derived type of the
original Python object will be lost.

> BTW, introspection isn't currently part of shared_ptr because whenever I
> encounter a need for yet another shared_ptr feature, I always try _very
> hard_ to solve the problem using only the existing public interface. This
> unofficial filter has always worked well so far. :-) (And when I failed to
> apply it - shared_from_this - it was a mistake.)

Good policy.

> Have you considered keeping a std::set< weak_ptr<> > to track shared_ptr
> instances created by boost.python? (Shot in the dark, don't yell at me if I
> missed the point.)

I could use something like a std::map< weak_ptr<>, PyObject* >, but
that would be truly awful:

1. I would need to sweep the map of dead entries periodically
2. It would incur a great deal of overhead
3. It would be very complicated.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk