Re: standard vs. hand crafted loops
In article <e4bvns$iud$1@sunnews.cern.ch>,
Maciej Sobczak <no.spam@no.spam.com> wrote:
Daniel T. wrote:
Yes, I do apply the same arguments to 'if' statements (although there
its between the 'if' and a virtual function call.) Let's outline what
those arguments are. IE When do I think that algorithms/virtual
functions are a better choice than "for" and "if"?
(a) Is total line count reduced? (Here I refer basically to the
number
of semicolons.)
(b) Can a temporary be removed from the mainline function by using
the
algorithm/virtual?
(c) Is the cyclomatic complexity of the program reduced?
(d) Is the intent of the code better communicated?
The above are from least important to most important.
These are very good arguments. I would also add the number of function
calls as one of the factors (at least not to contradict myself in my
other debate with Carlos Moreno ;-) ).
Where would you place it in the priority list above?
I also think that some code metrics that takes into account
"functional"
tools used in the code could of great help. For example, function call
that uses tens of binders and tens of composers is definitely more
complex than the code that uses them less, even if both have the same
value of other metrics (like cyclomatic complexity).
What I try to say here is that in the language that allows to express
many different paradigms a single code metric is never enough. The
ultimate metrics is of course the "perceived complexity", although
it's
a bit difficult to formalize.
Yes, that is covered in item (d) above. Code that is complex in the way
you mention doesn't communicate its intent as well. But we have to
remember, this is a very subjective metric despite being the most
important of the ones outlined.
I'm reminded of a story I heard once that Newspapers write to a sixth
grade education because they want to be understood by as many readers as
possible. There is something to be said for such an attitude, "only use
for loops simply because we don't want to have to hire people who know
the STL," but I'm not going to say it.
Now, are you willing to assert that algorithms *never* reduce line
count, *never* help remove temporaries, *never* reduce cyclomatic
complexity, and *never* do a better job of communicating intent?
Of course not - I'm not asserting this. The point is that *some*
algorithms do very well in reducing the complexity of the code,
whereas
others don't. Statically speaking, for_each seems to be the black
sheep
of the family.
I don't quite agree. I will agree that sometimes a for loop does a
better job than any algorithm, but I don't think it is right to say that
any one algorithm is always worse than any equivalent for loop. Even
for_each has a place in the world. Maybe the example from "The C++
Programming Language" would be appropriate.
class Extract_officers {
list<Person*>& lst;
public:
void operator()(const Club& c ) {
copy(c.officers.begin(), c.officers.end(), back_inserter(lst));
}
};
void extract(const list<Club>& lc, list<Person*>& off) {
for_each(lc.begin(), lc.end(), Extract_officers(off));
}
How would that look as loops instead?
void extract(const list<Club>& lc, list<Person*>& off) {
for ( list<Club>::iterator it = lc.begin(); it != lc.end(); ++it ) {
for ( list<Person*>::iterator it2 = it->officers.begin();
it2 != it->officers.end(); +
+it2 ) {
off.push_back( *it2 );
}
}
}
To me, the for loops in the latter example are obfuscating the job being
done to the point of illegibility.
Or the example I gave earlier:
for_each( declarations.begin(), declarations.end(),
add_declaration_to( result ) );
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]