|
Boost : |
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk