quote:This article argues that calling an algorithm is usually preferable to any hand-written loop. Why? There are three reasons: Efficiency: Algorithms are often more efficient than the loops programmers produce. Correctness: Writing loops is more subject to errors than calling algorithms. Maintainability: Algorithm calls often yield code that is clearer and more straightforward than the corresponding explicit loops. The remainder of this article lays out the case for algorithms.

Thought people might find this interesting. There are people who shy away from using the Standard Library containers because they want to write their own. This article suggests that you shouldn't even be writing your own loops. [edited by - petewood on March 5, 2004 7:42:46 AM]

It''s essentially a reprint of one item (43) of Scott Meyers excellent book on STL.

Scott bring up a lot of good points on why you should do this.

The the biggest downside is that for each loop you are not writing you are probably writing another function so that you can pass it to the algorithm.

quote:Original post by Anonymous Poster
It''s essentially a reprint of one item (43) of Scott Meyers excellent book on STL.

I have the book but reckon there are plenty of people who don''t.

quote:The the biggest downside is that for each loop you are not writing you are probably writing another function so that you can pass it to the algorithm.

I find, on the whole, that if I am refactoring code I will move the complicated contents of a loop into its own function with a nice clear name. Alternatively, if there''s not much going on in the loop, then, using boost.lambda, you can make simple one-liners.

Refactoring would suggest that if moving code into its own function makes it clearer what is happening then it''s a good idea.

It''s a nice thought, but for it to have weight the algorithms in C++ would need to be more natural - which would require extensive modification of the language. Let''s take antareus'' example:

for_each(accounts.begin(), accounts.end(), boost::bind(Account::Disconnect, _1)); 

The thing is a horror! And that''s the simplest sort. It''s not an intuitive construction (until you actually start thinking in C++, which, frankly, is frightening), and it makes use of the completely orthogonal identifier _1 (which you and I may know as a bit of template magic to extract the positional iterator, dereference and apply to the function as a parameter, but does it visually suggest that?). Then complicate the matter by requiring multiple parameters.

An elegant construction would be something along the lines of

for acct in accounts{  acct.Disconnect();} 

By Jove! Why does that seem so familiar...? Oh, wait, that''s Perl syntax! (Python is much the same, except replacing the braces with a colon and indentation.)

The article may make a perfectly valid academic opinion, but it fails to countenance the widely varying levels of skill of programmers and the horrible construction of most algorithms (restriction of the language, not deficiencies of the algorithm writers). So, bleh.

Hmm... seems familar to me too... maybe...

for each acct in accounts
acct.disconnect
next acct

Ahh, vb anyone?

What are the PERL, Python and VB equivalents of the following

find
find_if
adjacent_find
find_first_of
count
count_if
mismatch
equal
search
search_n
find_end
accumulate

These functions provide all the state variables needed without you having to worry about it. Something like search_n isn't a trivial thing to be writing out by hand every time.

It's easy to try and discount the whole idea of using algorithms just because using for_each doesn't seem to buy you much.

[edited by - petewood on March 5, 2004 9:00:12 AM]

I agree, while for_each is somewhat cumbersome and ugly (i usually end up writing an iterator-for instead), many of the other stuff in algorithm is great!

[edited by - marijnh on March 6, 2004 8:07:53 AM]

quote:Original post by petewood
These functions provide all the state variables needed without you having to worry about it. Something like search_n isn''t a trivial thing to be writing out by hand every time.

Agreed. In C++. In Python, I''d use a list comprehension or other tool.

quote:It''s easy to try and discount the whole idea of using algorithms just because using for_each doesn''t seem to buy you much.

That''s not my point. My point is that the utility that these algorithms provide only exists because writing equivalent code is non-trivial - a language flaw. I''m no fan of adapting what are essentially system languages to high-level work; I feel it isn''t particularly productive. I would much rather use the system language to extend a truly high-level language, and thus gain the benefits of both where appropriate.

The STL is great. It''s a massive boon to C++ developers, poor devils that they are.

quote:Original post by Oluseyi
My point is that the utility that these algorithms provide only exists because writing equivalent code is non-trivial - a language flaw. I''m no fan of adapting what are essentially system languages to high-level work; I feel it isn''t particularly productive. I would much rather use the system language to extend a truly high-level language, and thus gain the benefits of both where appropriate.

The STL is great. It''s a massive boon to C++ developers, poor devils that they are.

Indeed. In my work I have to use C++. I''ve introduced Python as a replacement for our old macro language in applications but we aren''t going to be programming in the main in high-level languages any time soon. A lot of what I do is number crunching code, engineering calculations and fast display of large volumes of data graphically. I know choosing C++ is premature optimisation but that''s what we use.