RE: [boost] Re: IOStreams formal review start

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]> 
>wrote:
> > 2.  This library does what a lot of other text-I/O libraries do, try to 
>fit
> > in "kewl" compression schemes.  The problem is that the types of 
>compression
> > here are binary oriented; they convert between sets of byte streams.
> > However, characters are not bytes (although characters, like other 
>types,
> > are stored as bytes).
>
>Are you saying there are problems with the implementation of the 
>compression
>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.  
>This
> > 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 
>buffers:
>
>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 
>very
>natural interfaces. You don't have to worry about buffering or about 
>putting
>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.

Regards,
Reece

_________________________________________________________________
Use MSN Messenger to send music and pics to your friends 
http://www.msn.co.uk/messenger