From: christopher diggins <cdiggins@videotron.ca>
From: "Rob Stewart" <stewart@sig.com>
From: christopher diggins <cdiggins@videotron.ca>
From: "Jonathan Turkanis" <technews@kangaroologic.com>
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!
You assume that nothing fails in the above, since main() falls through and, therefore, returns zero. Are you proposing that main() should actually catch exceptions and, possibly, extract its exit status from the exception object?
No I am not proposing that. I don't care at this point how a programmer chooses to deal with that.
If your framework doesn't account for exit status codes and doesn't provide an exception mechanism for communicating the exit status, then you assume nothing can fail whether by omission or comission.
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
You've admitted to being relatively new to C++. Can you rightly determine what "most programmers require?"
First off, I said "I'm not exactly wet behind the ears". Exactly how much, or how little I know about C++ should be irrelevant. I think it is extremely rude to put someone's credentials into question in such a discussion. If you disagree with something I said, then please state why, don't question the validity of my opinion.
You've tried to suggest that you weren't expert to explain various shortcomings and here you tried to make yourself knowledgeable, if not expert, on what "most programmers require." I simply called you on that. Granted, I could have omitted the first sentence and avoided the trouble. For that, I'm sorry.
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.
A reasonable goal, though all C++ programmers need to become familiar with generic programming and function objects. These really aren't novel or academic techniques.
No, but they are overkill in cases when a void procedure will do just as well.
Then keep your arguments to the merits of the approach; don't bring the knowledge and skills of unmotivated programmers into your argument.
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; }
So the result of this program is to write "<PRE>" to stdout, copy stdin to stdout, and write "</PRE>"? Why do you need a program for that?
Sorry I was unclear, the CppToHtmlPreTag adds <div class="xxx"></div> tags around the various syntactic elements so that a css document can control coloring.
Ah, got it.
This would be even easier to assemble via scripting and you don't need to compile anything or maintain source and binaries independently.
I am perfectly aware of how to use the various shells and scripting languages. I don't see how that is relevant to a discussion of C++ techniques.
I had no idea of what you or others reading the thread knew, hence my discussing the matter. As to how scripting is relevant, I thought I made that pretty clear in what you snipped: shells are very good at I/O redirection and assembling multiple programs into a new program, without requiring that the code conform to any structure except using stdin and stdout. This raises the question of whether your idea has merit within C++. (If all you have is a hammer....) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;