From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-31 10:55:19
"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
> If you want to read a bzip2 file (for example), the bzip2 file will be a
> binary stream and the resulting stream will be either binary or text
> depending on what the compressed file stores. You can tell std::ifstream to
> read the stream as binary, so what is the problem? Also, you might want to
> convert between text and binary modes:
> file > bzip2 (binary) > text > (process) > bzip2 (binary) > file
Line-ending conversions can be done by sticking a newline filter in between the
binary and text filters. When converting_stream is up and running, code
conversion will be inserted at the appropriate place in a filter chain
consisting of mixed narrow- and wide-character components.
> > > 1. Actual code using this library is very slick and easy to set up.
> > > ease of use/set-up also applies to the plug-in filters and/or resources.
> I also like the ability to chain filters. I have a program that uses a
> similar mechanism on a character tape stream that allows text to be split to
> a certain character length and/or merged back into one block. It would be
> interesting to compare the performance of using my program verses an
> implementation using this library.
I'd be interested too. There are a number of optimization I've held in reserve
because I'm not sure ther'ye necessary. The big question is: what should I
compare my library to?
> >There are two main resons to write Sources and Sinks instead of stream
> >1. Sources and Sinks and sinks express just the core functionality of a
> >component. Usually you have to implement just one or two functions with
> This is similar to what iterator adaptors and flex_string do for iterators
> and std::strings respectively. This makes it easy to write standard
> conforming components.
> For example, if you wanted to add support for a
> COM-based IStream, it would be easy to implement a source and/or sink.
This was one of the original applications, actually :-)
> I will post a more detailed review once I have had a better look through the
> documentation and library, but at the moment it looks good.
Thanks, I'll look forward to it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk