[boost] Re: Libraries requested or under construction

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-07-23 14:17:24

From: Andy Glew <glew_at_[hidden]>
> 
> Today's request: live_ptr
> 
> live_ptr<T>
> 
>         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.