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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk