Peterchen[^] seems to be pretty angry with the trend in modern C++ to replace loops with STL-like algorithms. He says, among other things:
Look the framework we have to build to minimise (not remove, just "minimise") writing loops:
iterators. const. unidirectional. bidirectional. reverse iterators. const or not. iterator adaptor. functors. binders. composers. bind. function. lambda library. anything I forgot? most likely. We need to templatize like hell, bending the compiler to a point where we are happy it makes it through our code alive - and when not, we don't dare ask for sensible error messages. To avoid what?
It's a loop, for god's sake. It's not a bear trap, it's not the infamous goto-spaghetti mess, it's not a terrorist nuke we have to keep out of our code whatever sacrifice of sanity is necessary.
What can go wrong in a loop?
- you forget to increment
- you are off by one
- you invalidate the container or the iterator
The first requires some discipline, the second some basic calculus training, and the third heaven forbid thinking! whoo!
Resolution: From now on I'll call all algorithm aficionados loopophobics. Yes, Scott Myers, this includes you.
Some of the comments from the fellow programmers:
after a certain point, trying to turn C++ into Haskell just creates confusion for anyone unfortunate enough to have to maintain the code.
for loops are way too readable, the whole purpose of STL and especially Boost is to enable the production of completely unreadable code that will utterly confuse the slack-jawed imbecile who only knows C# and is asked to maintain my C++ code.
This seems to be complexity for complexity's sake, or possibly just to distance itself from anything obvious non-STL
However, I would agree with Meyers' conclusion on this matter:
In the ongoing tussle between algorithm calls and hand-written loops, the bottom line on code clarity is that it all depends on what you need to do inside the loop. If you need to do something an algorithm already does, or if you need to do something very similar to what an algorithm does, the algorithm call is clearer. If you need a loop that does something fairly simple, but would require a confusing tangle of binders and adapters or would require a separate functor class if you were to use an algorithm, you’re probably better off just writing the loop. Finally, if you need to do something fairly long and complex inside the loop, the scales tilt back toward algorithms, because long, complex computations should generally be moved into separate functions, anyway. Once you’ve moved the loop body into a separate function, you can almost certainly find a way to pass that function to an algorithm (often for_each) such that the resulting code is direct and straightforward