[boost] Re: Libraries requested or under construction

From: Andy Glew (glew_at_[hidden])
Date: 1999-07-23 13:43:08

>At 03:55 PM 7/22/99 -0700, Reid Sweatman wrote:
>>Anyway, I support your notion of a requested/in progress page for
>>the site.

I hope that nobody minds if I submit the following request?
Maybe one of you can point be to existing code; or maybe
I will be shamed enough to write it.

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.

registered_ptr<T>
centrally_registered_ptr<type T, pointer_registry R = default_central_pointer_registry>
locally_registered_ptr<type T, local_pointer_registry R>

        These smart pointers are reversible: that is, when a pointer to an object is taken,
        a backlink, i.e. a pointer to that pointer is registered onto a list. The list of
        backpointers can be manipulated in the normal ways.

        This is an example of the many-to-one reversible pointers found in object relational
        database systems.

        Because of the limitations of C++, it is usually necessary to derive the
        class pointed to from centrally_registered_ptee or locall_registered_ptee
        (ptee = ponted to). 

        locally_registered_ptees contain the registry in the object pointed to,
            hence the need for derivation from locally_registered_ptee.

        centrally_registered_ptrs have the backpointer lists stored separate from
            the objects pointed, typically in a global hashtable. Derivation from the ptee
            type can then be avoided, except when special action is desired on deallocation.

        The backpointer lists may consist either of pointers to the registered_ptrs
        within a structure, or pointers to the referencing structure itself.  The first technique
        is useful or generic registered_ptr needs, such as live_ptr, described above;
        it works without knowing the type of the object containing the pointer.
        The second technique is used when actual back traversal is desired.

        If the second technique is used, the back pointer list is potentially polymorphic.
        This polymorphism is handled in several ways
                a) the usual C++ ways: virtual functions or type tags
                b) the registered_ptr classes provide the ability to have several registries,
        typically one per type, specified at definition.

versioned_ptr<type T, version_offset VO, pointer_registry R = 0 >

        A versioned pointer is another pointer class on which a live_ptr may be based.

        Rather than explicitly going and finding the pointers pointing to an object when
        an object is deallocated, versioned_ptrs keep a version number with the pointer.
        
        For a versioned pointer to be valid, it's version number must match the version
        number placed in the object, which may be specified at template use point.
        (If, that is, you are one of the lucky people whose C++ compiler supports
        pointer to member as a template parameter.)

        When the object is deallocated, it's version number is changed.

        Versioned pointers are a little bit less safe than explicitly zeroed live_ptrs,
        since there is always a remote chance that the memory of the object may be
        reallocated, and exactly the same bitpattern may be reused for the version.
        You can only eliminate this possibility by assuming full control over new
        and delete.

        On the other hand, versioned pointers are often faster than live_ptrs,
        since deallocation does not require any backpoiner list traversal.

        Myself, I would never voluntarily use versioned pointers - I don't like 
        things that probably won't crash. Unfortunately, I have to work with 
        a large open source program that uses them a lot (the SimpleScalar simulator),
        albeit in ways that I think make it safe.

Anyway, these are some smart pointer flavours that I would like to have in my library.
Any pointers to existing source available implemenations would be appreciated.