Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

petewood

"an algorithm is usually preferable to any hand-written loop"

This topic is 5367 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
It''s beautiful when you can collapse an entire loop into one line of code:
for_each(accounts.begin(), accounts.end(), boost::bind(Account::Disconnect, _1)); 

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hmm... seems familar to me too... maybe...

for each acct in accounts
acct.disconnect
next acct

Ahh, vb anyone?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!