I hadn't thought of that. I'd much rather teach people how to write correct filters, so they can be used with maximum efficiency. There's also no good way to turn a blocking input filter into a non-blocking one
The mechanism I was alluding to would work in general, requiring a dynamic buffer to handle the single largest output the dumb blocking filter wants to produce all at once. I agree that it would be best to make such a wrapper unnecessary.
About the close() or open() methods for a filter that wants to write some prelude or coda (e.g. gzip): aren't these only necessary because you can't guarantee that the constructors and destructors for the filter stack are called in the proper order?
No -- filters should be reusable. Here's an example from a reply I wrote to Rob Stewart (it turned out not to be relevant to that discussion, but maybe it'll be relevant here ;-).
zlib_ostream out; out.open(file_sink("hello_world")); out << "hello world!"; out.close(); out.open(file_sink("goodbye_world")); out << "goodbye world!";
Only one zlib_compressor is constructed, but it is used several times.
OK. I understand your rationale - you think that constructing these filtered streams might be expensive, and that one might want to cache and reuse them for many files/network connections/etc. I guess you can repeatedly open() and close() fstreams that way, although I've never wanted to.
Actually, I can run the destructors in any order I want, since I'm using boost::optional<Filter> to avoid requiring that filters and resources be default constructible. So I can just do filter_ = none;
So what I suggested (having filters be use-once and able to emit prelude/postlude in their constructor/destructor) is technically possible, but you prefer to make them reusable and thus need Openable/Closeable concepts (or require all filters to implement some open() and close(), even an empty one).
I don't think a second, simpler interface would be that much of a win;
I've lost you here. Which is the 'second, simpler interface' which you don't think is a good idea?
I meant the simpler (current) "blocking-only" filter interface that needs a wrapper to handle sinks that consume less than they're given without actually failing/EOFing (only nonblocking sinks, really).