Re: [boost] IOStreams Formal review -- Guide for Reviewers

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.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).