Still, there you go ;-)
Rather than a cache that does A or a cache that does B, I'd rather see someone do a review of various cache features in the literature (or at least whatever Google can find), identify the most useful ones, and then design one or more classes (probably template based) that delivered that useful feature set.
For example, "Least Recently Used", "Least Frequently Used", and "Least Recently Added" are common replacement policies, but there are probably some others that are occasionally useful. I've used a scheme where entries are never flushed as long as there are any live references to them. Another way to approach a cache library design would be to collect a set of use cases, and then see what feature set would be needed to satisfy those use cases.
Caching is one of the fundamental ways to achieve improved performance. I'm a bit surprised it hasn't been more of a topic in Boost discussions, or in computer science in general.
That isn't a criticism of your object_cache; it is just that I think the topic deserves more than a single-solution approach.
Yep, I couldn't agree more: since I only needed one use case I only wrote one, and that's really why I haven't brought it forward for review. Or to put it another way I couldn't be bothered to go through all the possible caching policies ;-) John.