Boost logo

Boost :

From: Jonathan Graehl (jonathan_at_[hidden])
Date: 2004-09-08 23:58:45

>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 << "hello world!";
> out.close();
> 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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at