[boost] Re: Re: Re: Functions as Filters (was Program Reuse ...)

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-01-10 20:14:31

christopher diggins wrote:
> ----- Original Message -----
> From: "Jonathan Turkanis" <technews_at_[hidden]>
>>> I compiled and successfuly ran this on Visual C++ 7.1. What are the
>>> chances something like this could find its way into the iostreams
>>> library?
>>
>> If you can convince me that it's useful.
>
> It is not that useful, unless you are inexperienced in C++, or just
> want something that is simple, easy to use and "good enough" (I fall
> into all of these camps). I understand that these may not be
> sufficient motivations to make an addition to the library, especially
> one written in the style of the STL, which is so rigorous.

I'm happy to add classes to make the library easier to use even if efficiency is
sacrificed. one_step_filter is an example of this. I'm just looking for an
example where it would be easier to write a filter as above than to use one of
the existing filters concepts.

>> If it really were possible to reuse existing code, as you orginally
>> suggested, then it would be a clear win. However, I haven't yet
>> seen an example of a pre-existing procedure which meets the
>> requirements of the proc_as_filter class.
>
> You mean a simple void procedure with no parameters, which reads from
> standard in, and outputs to standard out? The main() from many
> programs fits this bill.

Not conforming programs: main must return int. Also, you can't *use* the main
function. E.g.,

     void f()
     {
       return main(); // error.
     }

>> Therefore, I first must decide whether writing a filter as a function
>> which reads from standard input and writes to standard output is ever the
>> best way to write a filter, given the other choices that the library
provides.
>
> It is possibly never the "best way", technically speaking.

I'm willing to define 'best' broadly. It might mean easiest to teach, fastest to
write, ... .

>> You clearly
>> think the answer is yes, but I'd like to see some examples.
>>
>> Second, is there any reason to prefer functions with the signature
> [a, b, c]
>> ?
>
> The only reason to ever choose a over b or c, is simplicity and ease
> of use.

I understand that's what you're arguing, and it's a perfectly acceptable
justification. But I haven't seen an example yet.

>>> ... Is there any reason why
>>> the source() and sink() can not be assumed to be cin and cout
>>> respectively when absent?
>>
>> Yes. When you use the pipe operator you don't always want to form a
>> complete
>> chain:
>>
>>               filtering_ostream out(filter1() | filter2() |
>>               filter3()); out.push(sink());
>>
>> In a real world example the first and second lines might be at
>> different locations in a program.
>
> But in the example of:
>
>   source() | filter1() | filter2() | sink();
>
> Then why couldn't we just write:
>
>   filter1() | filter2();
>
> And assume that source and sink were cin and cout respectively.

The expression

   filter1() | filter2()  [A]

yields a lightweight object which when added to a chain c has the effect of
executing

        c.push(f1);
        c.push(f2)

where f1 is the temporary instance of filter1and f2 is the temporary instance of
filter2. Suppose evaluating [A] had the effect of copy input from std::cin and
pumping it through f1, fs2 and std::cout. How could you prevent this from
happening in the ordinary case:

    filtering_ostream out( filter1() | filter2() );

?

> Christopher Diggins

Jonathan