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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-01-12 10:02:03

From: christopher diggins <cdiggins_at_[hidden]>
> From: "Rob Stewart" <stewart_at_[hidden]>
> > From: christopher diggins <cdiggins_at_[hidden]>
> >> 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!
> >
> > 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;