Re: [boost] Re: Re: Re: Re: IOStreams formal review -- extended

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-09-17 12:01:23

From: "Jonathan Turkanis" <technews_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message:
> > From: "Jonathan Turkanis" <technews_at_[hidden]>:
> > > "Rob Stewart" <stewart_at_[hidden]> wrote in message:
> 
> > > > > If you mean that the above should be rewritten
> > > > >
> > > > >    filtering_ostream out;
> > > > >    out.push(file_sink("log"));
> > > > >    out.complete(base_64_encoder());
> > > > >    out << "hello world!\n";
> > > > >    out.push(zlib_compressor()); // error!
> > > > >
> > > > >  you may be right that users would be less likely to make this mistake.I
> > > don't
> > > > > see how add_resource would help at all.
> > > >
> > > > Because "add_resource" was offered as a synonym for "complete."
> > >
> > > But here, the component being added with add_resource (the base_64_encoder)
> is
> > > not a resource at all!
> >
> > But file_sink is.
> 
> To clarify, are you saying
> 
>     filtering_ostream out;
>     out.push(file_sink("log"));
>     out.add_resource(base_64_encoder());
>     out << "hello world!\n";
> 
> makes sense?

No, I meant:

    filtering_ostream out;
    out.push(base_64_encoder());
    out.add_resource(file_sink("log"));
    out << "hello world!\n";

> > >     I. Push the resource first, then push the filters, in order, starting
> with
> > > the one furthest from the user.
> > >     II. Push the filters first, in order (the reverse of I), starting with
> the
> > > one closest to the user, then push the resouce.

What does "starting with the one closest to the user" mean?

> > There are other reasonable conventions.  I like this one:
> >
> >    III. Push the filters first, in order of data flow, followed
> >         by the resource.
> 
> I thought of this early on, and liked it until I realized that data can flow in
> both directions. (See Fig 5 at http://tinyurl.com/5p2f5.) Therefore I still
> think only I and II make sense, and that II offers significant advantages.

(That link is broken, but I eventually found the figure.)

Offhand, I don't know how one assembles a bidirectional filter
and many pages at your web site won't load at present.  But, if I
can infer the right information, you have a single bidirectional
stream(buf) plus a sequence of filters, right?  The question is,
do you assemble the filters in input order or output order,
right?

You say that II makes sense in that case, but you have to choose
an order for pushing the filters, there isn't just one to choose
from.  The only thing you can do is decide whether the order is
biased toward input or output.  That is, you always assemble
bidirectional filter sequences as if it was an input filter, for
example.  Have I missed something?

> > > There's another problem with throwing out the current InputFilter and
> > > OutputFilter concepts. A filter which performs both input and output with
> two
> > > separate character sequences -- currently called InoutFilter but soon to be
> > > renamed BidirectionalFilter -- needs some way to know whether it's being
> asked
> > > to perform input or output. So the full interface becomes:
> 
> > I think you'd just have two instances of the same filter when you
> > want bidirectional filtering.  The framework would take care of
> > inserting each instance into the correct data stream.
> 
> The problem is that you may not want two copies of the same filter. You might
> want encryption for output and decryption for input.

I was thinking that if you were trying to use one instance to be
bidirectional, using two instances managed by the framework would
work better and make the filter implementation simpler.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;