From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-07-23 14:17:24
From: Andy Glew <glew_at_[hidden]>
> Today's request: live_ptr
> A live_ptr is a variety of smart pointer that does not deallocate
> the object pointed to as long as there is a reference, etc. I.e.
> it is not a garbage collecting or reference counting pointer.
> Instead, a live_ptr points to the object as long as the object lives;
> when the object pointed to dies (is destroyed), then the live_ptr
> is set to 0.
> Example: a simulator for an OOO processor, where objects
> are linked all over the place. Objects represent versions of state;
> when state is committed, other objects pointing to that version
> can now access the committed version. live_ptrs simplify coding,
> allowing ad-hoc cross-linking of data structures, without having
> to worry about deallocation on commit.
> Alternate names: valid_ptr
> I have encountered several different implementations of live_ptr,
> with slightly different semantics and intrusiveness. live_ptrs
> are usually derived from registered_ptrs. Because of the limitations
> of C++, it is usuall necessary to have the pointed to data type
> itself be derived from live_ptee, although, if you can add a hook
> to all destructors, you can avoid this annoyance.
> Typically, the live_ptee destructor walks a registry which points to the
> live_pts themselves (not the objects they are embedded in).
> Methods: all pointer methods, registering on copying, assignment, etc.
In general, I dislike intrusive templates. The auto_ptr, scoped_ptr, and shared_ptr
templates make no special requirements on their type argument, which is, IMHO, an
essential part of their general usefulness.
Nonetheless, live_ptr looks useful, so I'd like to see if it can be done with minimal
intrusion. I don't consider requiring derivation from live_ptee to be minimal.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk