Boost logo

Boost :

From: Andy Glew (glew_at_[hidden])
Date: 1999-12-01 13:36:09

> 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 can imagine something like specifying the 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.

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>?

Boost list run by bdawes at, gregod at, cpdaniel at, john at