christopher diggins wrote:

Several questions,

1) There is the (apparently) undocumented pipe operator http://www.ootl.org/boost/iostreams/pipable.hpp.htm . What does it do exactly? It appears to push filters into a filtering_stream or filtering_streambuf, but I am unsure.

I haven't written the docs yet, so here is a summary: A pipe expression is an expression of the form: f1 | ... | fn | d where the fi's are filters and d is a device. All devices can appear in pipe expressions. Filters can appear in device expressions only if they have been declared pipable: BOOST_IOSTREAMS_PIPABLE(filtername, template_arity) Here template_arity zero indicates a non-template. A pipe expression can be used to initialize a filtering_streambuf or filtering_stream, or as an argument to push.

2) Can we use it to write arbitrarily long chains such as:

source | input_filter | bidirectional_filter | output_filter | sink?

We talked about extending the notation to allow src | f1 | ... | fn | snk to be equivalent to filtering_ostreambuf out(f1 | ... | fn | snk); boost::iostreams::copy(src, out); I really like this idea, but I haven't implemented it because I haven't resolved the following issues: 1. If source has type std::istream, std::ifstream, etc. argument-dependent lookup may not find operator| unless I put it in namespace std, which is forbidden. If I don't put in operator| in namespace std, I'm worried that failure of the pipe notation to work with standard streams and stream buffers as sources will be one of the most common questions on the users list ;-) 2. The natural implementation of src | f1 | ... | fn | snk would use filter chains, but these are the most heavy-weight components in the framework, and I'm not sure I want to include them automatically when the user includes <boost/iostreams/pipable.hpp>

3) why the name bidirectional_filter when inputoutput_filter (or io_filter) would be apparently more consistent with stl naming convention?

The standard library naming conventions are not fine-grained enough. An iostream, for instance, could have any of the following modes seekable dual_seekable bidirectional bidirectional_seekable Calling a bidirectional_filter an io_filter would not really provide any clarification. Originally I used bidirectional, then switched to inout, then switched back to bidirectional at the suggestion of Rob Stewart. It's purely a matter of taste.

4) what is the url for the latest version and what is the status?

The latest version is in CVS: http://www.boost.org/more/getting_started.html#CVS The status is: good. ;-) Jonathan