[boost] Re: Iostreams questions

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-01 15:04:54

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