Nicholas Neumann wrote:
Peter Dimov wrote:
If you're going to use a client-supplied callback, the most straightforward one would just return a shared_ptr<FILE> (or the appropriate equivalent). Then both opening and closing are under the callback's control.
That's interesting to think about. A simultaneous pro and con I see is that the callback now has to deal with how to open and close a file, which was an implementation detail of the backend before. If you want or need that level of control, it is useful. But a callback which asks "close the file?" only has to take a path and return a boolean, leaving most of the concerns to the backend. Both allow for any caching strategy. Either one works for me so if the shared_ptr<FILE> approach solves problems for others that the boolean approach does not, I'd be just as happy with it.
The boolean callback only allows for "never cache" and "cache forever" strategies, unless I'm missing something. That is, it allows the backend to implement other caching strategies, but not the user writing the callback.