[boost] Re: weak pointers and cycles

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-02 00:10:59

From: Andy Glew <glew_at_[hidden]>
> > I've been backing into this one for years.  One of my committee
> > proposals had counted_ptr parameterized on an allocator, an idea
> > whose time may have come.
> > 
> > However, cyclic_ptr, shared_ptr, and weak_ptr do not have the
> > same semantics.
> 
> Can we enumerate the different semantics? I may have missed part 
> of cyclic_ptr<T>.
> 
> Repeating part of my last email, I see two main classes of semantics:
> 
> (1) Strong References, or, what I call keepalive_ptrs.
> 
>     Pointers that keep the pointee alive as long as a strong reference
>     is outstanding.
> 
> (2) Weak References, that signal the pointer when the pointee
>     is removed. My live_ptr<T> (using a registry), my versioned_ptr<T>
>     (using an intrusive version) and your weak_ptr<T> are examples.
> 
> Reference counting and garbage collection I see as just different
> implementations of such "keepalives".
> 
> Please pardon me if I am missing something, but I thought that
> cyclic_ptr<T> did this. cyclic_ptr<T> differs from the large number
> of reference counting classes out there (like shared_ptr?)
> in that it can GC cyclic data structures.  It doesn't do this 100%
> transparently, since GC must be explicitly invoked. But apart from
> this minor exposure of implementation, cyclic_ptr<T> is semantically
> compatible with the reference counted shared pointer implementation
> - isn't it?

I guess it depends on how minor GC is, but yes, it's just like shared
pointer otherwise.

> I can imagine something like specifying the implementation,
> 
>     keepalive_ptr<T,reference_counted_share_ptr_handle_implementation>
> or
>     keepalive_ptr<T,cyclic_ptr_GC_implementation>
> where the second, optional, arguments are renamings of the present
> shared_ptr and cyclic_ptr.
> 
> I *think* that this implementation template parameter differs significantly
> from an allocator. 

The point is that once you have added the allocator argument to
shared_ptr you can partially specialize to do all kinds of things.

> I can imagine that there may be an explicit keepalive_ptr<T,>::explicit_compress()
> method, which might be a NOP for a reference counted implementation, or would
> be the mark and sweep GC of cyclic_ptr.
> 
> ---
> 
> Q: am I missing something?  Or could not both shared_ptr<T> and cyclic_ptr<T>
> be viewed as implementations of what I call a keepalive_ptr<T>?

Yes they could.  I remain skeptical of the idea of specializing on
implementation, because I am not sure what requirements to place on
the implementation type.  If we can nail that down I'd less worried.
I am reluctantly coming around to specializing on allocator because
we already have a spec for what an allocator is.