From: christopher diggins <cdiggins@videotron.ca>
From: "Rob Stewart" <stewart@sig.com>
From what I can see, you use the term "program" to mean an instance of class Program or, more specifically, a derivate thereof. That isn't what I think of when I see the word "program."
What would you suggest the name of the class be instead? It is intended to provide the main entry point for a program, so that the program can be easily reused separately.
From what I see, you're packaging functions, not system() calls to executables or separate processes connected by some IPC.
Finally, your Program class is too intrusive since one must derive from it. It would be better if there was a make_filter() function template called with a function (object) returning a streamable object. Then, make_filter() can return an object which can invoke the function(object) as necessary and can be chained with other instances to create a pipeline.
Why is it considered better to model a concept rather than inherit from a base class and override a virtual function? It seems to me that it is simpler to explain to a newcomer to inherit from a class, and it is more apparent from looking at the code what is actually happening.
If I already have a function (object) that provides the desired output, why must I create a class, implement a member function that forwards to that function(object), and then use the class? A simple call to make_filter(f) will do the job without the need to write any code.
Oh, I should also point you to Jonathan Turkanis' IOStreams Library (recently accepted, but not yet added to Boost). See http://home.comcast.net/~jturkanis/iostreams/ for code and documentation. Look especially at the filters functionality.
I am sorry but I don't see the connection with the iostreams library and what I am doing. Could you explain the similarities?
Perhaps if I understood the distinction you're trying to make between a "program" and ordinary functions, we can understand one another better. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;