[boost] Re: live_ptr

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-08-01 13:22:34

From: Dave Abrahams <abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, August 01, 1999 11:58 AM
Subject: [boost] Re: live_ptr

> > Although it seems impossible to create a non-intrusive weak
> > pointer class that can track the liveness of an arbitrary class of
> > object, it is possible to create one that tracks the liveness of
> > objects controlled by shared_ptr.
> >
> > The changes to out current shared_ptr would be:
> >
> >    Switch to the "indirect" implementation of shared_ptr.  That
> >    is, the shared_ptr contains just a pointer to a handle struct
> >    containing a pointer to the object shared and the count.
> >
> >    Add a second count field for the number of weak pointers using
> >    the object.  When the number of shared pointers goes to zero
> >    the shared object is deleted and the pointer to object field is
> >    zeroed out, but the handle struct is not deleted until both
> >    counters go to zero.
> 
> Fiendishly clever!
> 
> Questions/observations
> 1. How do you create a weak_ptr? I presume its constructor would need to
> take a shared_ptr parameter...

Yes.

> 2. This design, though not intrusive in the same sense, places other
> restrictions on the object being pointed at: you shouldn't make a weak_ptr
> to an object created on the stack.

Right, any more than you should make a shared_ptr to such.

> 3. In general, the intrusive "notify somebody when I'm destroyed" paradigm
> is still quite useful. For example, you can use it to design a collaboration
> system where a "broadcaster" transmits notifications to any number of
> arbitrary "receivers". When a receiver is destroyed, it must be removed from
> the broadcaster's list.

I can imagine generalizing the above scheme to parameterize
shared_ptr on some sort of notification functor.