christopher diggins wrote:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
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.
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
Not conforming programs: main must return int. Also, you can't *use* the main function. E.g., void f() { return main(); // error. } 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