|
|
Boost : |
From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-01-11 11:32:50
----- Original Message -----
From: "Jonathan Turkanis" <technews_at_[hidden]>
>> void DoWork() {
>> // do work
>> }
>>
>> int main() {
>> DoWork();
>> }
>
> Okay, but do you really expect people to start writing programs this way?
Yes, especially if the iostreams library provides the functionality to them.
My point is that C++ code is pointlessly hard to reuse as is, and I am
pushing for new ways to make small programs more reusable. This is incrediby
important when managing large numbers of small programs (for instance
library tests and demos). It is trivial to refactor code to make it look
like the above, just cut and paste the main!
> I
> think people would only do this to conform to your filter concept. My
> question
> is: why aren't the other concepts sufficient?
The other concepts are fine, they are just more obfuscated than most
programmers require. Just imagine trying to explain how to use a filter
concept in a way which makes sense to a Java / Delphi / C programmer. I
think it is important to try and provide alternatives where possible which
makes sense to professional programmers who may not be familiar with the
intricacies of generic programming techniques and functors.
>> By taking this one simple step, a person's code could then be easily
>> reused. This does overlook the fact that most filter programs take
>> parameters which is trivially remedied.
>
> Note that none of the other concepts has this problem.
Noted. I think that all of the concepts should be supported! I simply
arguing the case for void(*)() as a valid concept for now.
> I guess I should have asked for a *realistic* example. If you really write
> such
> simple programs you don't have to worry about reuse; it's simpler to write
> the
> whole program again from scratch.
First off I do write programs as simple as that and I have a lot of them.
This occurs frequently for testing, prototypes, demos, and systems admin. I
strongly disagree with maintaining multiple code bases, rather than
refactoring and reusing the code. As a professional coder I am always
looking for ways to be more productive and and have less code to manage.
Nonetheless, I do currently have a non-trivial program which converts C++
into a <pre></pre> html tag, CppToHtmlPreTag, it operates obviously on the
stdin and outputs to stdout. It looks essentially like this:
void CppToHtmlPreTag() {
// calls multiple other functions to do the work
};
int main() {
CppToHtmlPreTag();
return 0;
}
I want to reuse this program in another program which outputs an entire Html
Docucment with a header and footer. ( CppToHtmlDoc ). The easiest way I can
think of to do this is to write a new program such as (this is to a certain
degree psuedo-code):
struct CppToHtmlDoc {
CppToHtmlDoc(string css, string title) : mCss(css), mTitle(title);
void filter() {
cout << "<html><head><title>" << mTitle;
cout << "</title><link rel='stylesheet' type='text/css' href='";
cout << mCss << "'/><body>"
cin | CppToHtmlPreTag();
cout << "</body></html>";
}
string mCss;
string mTitle
}
int main(int argc, char** argv) {
assert(argc == 4);
CppToHtmlDoc(argv[1], argv[2]) | filestream(argv[3]);
}
So I wrote program2 using the [b] approach you outlined which I agree that
it is superior for this program. I also managed to retain my original code
precisely as is using the [a] approach. If I had to rewrite the original
program to use a filter concept I would have had to rewrite *all* of my
functions to pass the the Source and Sink types to each one, and to use src
and snk instead of cin / cout.
I guess my point here is that I am able to refactor existing code more
easily and quickly if you support [a] and [b] syntax. [c] is perfectly
acceptable, and has its advantages in several scenarios, even though it is
overkill for my work.
>>> The expression
>>>
>>> filter1() | filter2() [A]
>>
>> Sorry, I thought it was a statement. Wouldn't it be useful to also
>> allow one liners with a separate syntax:
>>
>> source() > filter1() > filter2() > sink();
>
> As I mentioned in a previous message, I think this is a good idea, if it
> uses
> the pipe notation. I don't see why a different operator should be used.
I just want to be able to write:
filter1() | filter2();
as a statement, with the implicit understanding it pumps from cin and to
cout. But you told me I can't have that, so I am offering ">" as a possible
work-around. Implementation aside, don't you agree that the POV of an
end-user isn't it obvious that the above statement should be equivalent to:
cin | filter1() | filter2() | cout;
I see that this conflicts with the current meaning of filter1() | filter2(),
so I would propose that instead that could be rewritten as filter1() +
filter2(). As an end-user I expect a | to have executed the data pumping by
the end of the statement. If it does it sometimes (i.e. source() | filter()
| sink(); statements) but not other times (i.e. filter1() | filter2()
expressions) then these are two separate and conflicting meanings of filter
| filter, which I am not comfortable with.
best regards
CD
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk