From: rogeeff (rogeeff_at_[hidden])
Date: 2002-03-11 17:55:19
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "Rainer Deyke" <root_at_r...>
> To: <boost_at_y...>
> Sent: Monday, March 11, 2002 12:33 PM
> Subject: Re: [boost] Interest in a cache class?
> > ----- Original Message -----
> > From: "David Abrahams" <david.abrahams_at_r...>
> > > ----- Original Message -----
> > > From: "Rainer Deyke" <root_at_r...>
> > >
> > > > > > However, having lots of shared_ptrs
> > > > > > keeping the cached objects alive defeats the purpose of
> > cache.
> > > > >
> > > > > Maybe your purpose. When I've needed a cache, I've needed
> > way
> > > > to
> > > > > prevent certain objects from being flushed.
> > > >
> > > > Why?
> > >
> > > Because the objects were "currently in use" - essentially
> > they
> > > were likely to be needed again soon,
> > I remain unconvinced. There is no semantic difference between
> > the same object around and discarding it and reloading on demand.
> > There is a difference in performance, but the cache itself is
> > in a better position to judge when objects should be discarded
> > the user.
> It seems a bit perverse to design a cache around the idea that the
> doesn't understand her performance needs as well as the cache
> Once I'm using a cache, I'm already in the domain where I want
> over low-level details that affect performance. If I didn't care
> that, I'd just recompute the data each time I needed it.
I am using manager algorithms (Policy) for this purposes. Every time
I need to make a decision what/when to flush/load I call appropriate
methods of manager algorithm class. You could apply something like
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk