[boost] Re: IOStreams formal review start

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-08 23:59:08

"Robert Ramey" <ramey_at_[hidden]> wrote in message:

Hi Robert,
    I've been looking over the old messages in this thread, to see if I let any
important points slip by.

> 5) What is your evaluation of the design?
>
> a) I've already stated my reservations about the mixing of streams and
> stream buffers.
>
> b) the concept of "chaining" is quite different than what I would have
> envisioned.  As I understand it, if 10 filters are chained together, this
> system is going to require ten levels of function calls to get a character
> in/out.  Someone is bound to object to this.  On the other hand,  this
> system permits filter to be composed "chained" at runtime which may be
> useful in some instances.
>
> I would have expected something like the filters be composed at construction
> time with templated constructors.  This would permit the inlined member
> functions to be collapsed by the compiler to minimize copying.

I think I may have missed your point the first time through. I though you were
just talking about eliminating function call overhead. Now I see that you are
suggesting that copying is minimized too. How does this work?

> The Dataflow
> iterators in the serialization library manifest this expection.

I remember when you first suggested I handle filtering
(http://lists.boost.org/MailArchives/boost/msg48300.php) you mentioned an
approach using iterator adapters.

I decided not to use iterators because I concluded that it would miss the
opportunity for many important optimizations that can be made when one is
presented with a contiguous buffer full of characters instead of one character
at a time. For example, I don't think zlib is very efficient if you pass it one
character at a time.

Still ...

I wish I had looked at the Dataflow Iterators in your library when I first read
your message! I put it on my mental 'to do' list then promptly forgot. It looks
like Dataflow Iterators and input/output filters are intended to solve exactly
the same sort of problems in many cases. So there are these obvious questions:

1. Where the functionality overlaps, which approach is faster?
2. What can your approach do that mine can't?
3. What can my approach do that yours can't?
4. If your approach is better all around, or in a broad class of cases, can I
adapt my library to use it? (I think so -- the pipe notation, which you don't
like, can give the compiler a clue which filters should be fused at compile
time.)
5. If my approach is better, can your library use it? (BTW, How do you use the
Dataflow Iterators in your library?)

I'm going to try to re-implement some of your iterators as Filters, and see what
happens.

Best Regards,
Jonathan