"Robert Ramey" <ramey@rrsd.com> 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