[boost] Re: live_ptr => live_container / live_iterator

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-08-13 15:23:04

> E.g. a live_map: a map from address to a cached object,
>     that automatically removes entries from the map when
>     they are removed from the cache.  Rather like an auxiliary
>     index to a cache, always kept consistent as objects are removed
>     from the cache.
> 
>     (I  think that Reid will undestand this application).

I was about to post a reply when I got to that line <g>.  Yup, you just
barked up my tree (to mangle a metaphor).

> "Automatic" removal of pointers to deallocated objects might be
> 
> a) instantaneous: the live_container might be registered
>     the same way a live_pointer is, and have a method called
>     on pointee deallocation
> 
> b) deferred: the live_container might contain live_pointers.
>     When the live_container is queried, all entries containing 0
>     live pointers would be removed.
> 
>     Typically this would be done inside an iterator:
>             begin(), end(), ++, --, [], etc.
> 
>     As usual, I am lazy, and would prefer not to have to code 
> up all of
>     the iterator access methods - but I don't see anything like
>     "iterator hooks".
> 
>     Count queries would be problematic: probably the stale objects
>     should be removed from the container first.
> 
>     Overall, the complexity of this deferred implementation probably
>     means that the instantaneous, registered, implementation 
> is cleaner,
>     even though the deferred implementation might be preferrable
>     for performance.

I can see benefits to going either way, so I wonder whether you couldn't
combine them.  That is, use the registry method, but don't physically remove
the pointer, even when its count goes to zero; that way, you'd get a (small)
win by simply reassigning the nulled pointer, rather than having to
reallocate it.  Don't know if this would be enough of a win to matter,
though.  If not, I think I'd personally prefer deferred.  Or perhaps combine
the two by maintaining a simple linked list of nulled pointers still in the
map, sort of an available allocation pool.  I've written schemes like that
often enough to appreciate having them built in.