Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-08-31 06:34:46

Jonathan Turkanis wrote:
>"Daryle Walker" <darylew_at_[hidden]> wrote:
> > On 8/28/04 8:09 PM, "Jeff Garland" <jeff_at_[hidden]>
> > 2. This library does what a lot of other text-I/O libraries do, try to
> > in "kewl" compression schemes. The problem is that the types of
> > here are binary oriented; they convert between sets of byte streams.
> > However, characters are not bytes (although characters, like other
> > are stored as bytes).
>Are you saying there are problems with the implementation of the
>filters, e.g., that they make unwarranted assumptions about 'char'? If so,
>please let me know. I'm sure it can be fixed.

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

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

>Can I rephrase this as follows: InputFilters and OutputFilters are a useful
>addition to the standard library, but Sources and Sinks just duplicate
>functionality alread present? If this is not your point please correct me.
>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
>natural interfaces. You don't have to worry about buffering or about
>back characters.

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.

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.


Use MSN Messenger to send music and pics to your friends

Boost list run by bdawes at, gregod at, cpdaniel at, john at