|
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