Boost logo

Boost :

From: Andy Glew (glew_at_[hidden])
Date: 1999-12-01 07:08:08


> So there you have it. All the simplicity of shared_ptr for applications that
> don't create cycles, and garbage collection for applications that do, at the
> cost of two extra pointers in the handle structure and a small amount of code
> for doing the collection, which need not be called by applications that don't
> need it.

So, there's a whole slew of possible reference counted and garbage collected
pointers, with implementations ranging from
    + various reference count and GC
        + Boost shared pointer
        + Greg's pointers
    + my version numbered pointers
    + non-intrusive handle oriented, registry oriented,
        intrusive, with data stored at the pointee,
        etc., etc.

All of the implementations have various advantages and disadvantages.

I think that all seem to essentially implement one of two semantics:

(1) strong reference semantics, what I call a "keepalive" pointer:
    a pointer that prevents the object it is pointed to from being deleted

(2) weak reference semantics - as Greg puts it, an implementation that
    signals when the storage it is pointed to is reclaimed.

    There are several possible signalling techniques. The one I have used
    most often is
        + set the pointer to null (or otherwise mark invalid)
    

----
When I see a relatively small set of semantics, but a large set of possible
implementations, each with differing advantages, my reaction is to 
parameterize:
    template<class T, class Implementation=shared_ptr_implementation>
    class shared_ptr : shared_ptr_implementation<T> {
        ...
    }

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