Comments on: Is std::for_each obsolete?

By: Uri Goren

Uri Goren — Tue, 10 Apr 2018 17:56:00 +0000

In this example std::for_each looks elegant, but a slight complication ruins it. What if we want to print to an arbitrary stream rather than std::cout?

Add an ostream& parameter to displayAsInstruction, that’s easy enough.
But now we can’t pass it to for_each, and the lambda returns, as ugly as can be:

ostream &os = …;
ranges::for_each(numbers, [&] (int n) { displayAsInstruction(os, n);}); // Guy Fawkes smiley?

Perhaps std::bind would slightly improve it (depending how painful you find std::placeholders::_1).

The range based for loop doesn’t suffer at all:

ostream &os = …;
for (auto number : numbers)
{
displayAsInstruction(os, number);
}

By: Jonathan Boccara

Jonathan Boccara — Sun, 08 Apr 2018 14:55:00 +0000

In reply to Jon Kalb. Thanks for pointing this out, Jon. This is an interesting point indeed, and I've put an entry in my backlog to dig it further and hopefully come up with a more detailed analysis.

By: Jonathan Boccara

Jonathan Boccara — Sun, 08 Apr 2018 14:45:00 +0000

In reply to Luis Díaz Más. That's a good point, I'm noting in my backlog to work on a performance comparison between for_each and a range-based for loop. Will write about my findings. Thanks Luis!

By: Jon Kalb

Jon Kalb — Fri, 06 Apr 2018 00:16:00 +0000

Jonathan,
In your example you are passing a function address to a generic algorithm. This is fine for correctness, but Luis correctly raises the issue of the compiler’s ability to inline the function call.

This is not relevant to the point that you are making but a better example for readers to follow would be to call an object with an inlined function call operator overload. Such calls can be inlined, whereas, in the general case, functions passed to generic algorithms by address cannot be inlined even if the function itself is an inline function.

Jon

By: Luis Díaz Más

Luis Díaz Más — Thu, 05 Apr 2018 18:07:00 +0000

What about performance? Is std::for_each able to inline the function body to avoid function calls, or will it make functions calls for each element in the collection? I think it is an important factor to consider when deciding which version to use.

By: Arnaud Brejeon

Arnaud Brejeon — Thu, 05 Apr 2018 01:05:00 +0000

My most common pattern for using std::for_each is something like this:

const auto endOfPartition = std::partition(begin, end, []() { predicate code });
std::for_each(begin, endOfPartition, []() { whatever processing });

By: Shreyans

Shreyans — Mon, 02 Apr 2018 21:19:00 +0000

I have slightly different point of view for these 2 ways to achieve the same thing. If the function inside the loop is stateless (independent of order in which it will be called for all the values in the container), I go for for_each, otherwise I go for range based for loop.
Reason behind this is, in future, there’s a chance of getting parallel for each with similar API. This way, we can reduce future efforts to make it parallel if required.
If it is stateful, there’s no way but to perform the action sequentially and range based for loop meets the requirements for that.

By: Vincent Zalzal

Vincent Zalzal — Mon, 02 Apr 2018 20:09:00 +0000

If the argument of abstraction isn’t enough to convince one of the usefulness of std::for_each, here is another: since C++17, one can pass an ExecutionPolicy to for_each for easy parallelism. And yes, that small ranges namespace is totally worth it. At work, I have done exactly the same for _all_ algorithms, and since then, they are used much more! (note: we weren’t allowed to use boost at the time).

By: sephorusFR

sephorusFR — Mon, 02 Apr 2018 16:01:00 +0000

I would say, it’s the say cullprit than with if vs ?: We tend to use if if the important thing is to claim “guys, this is a conditionnal piece of code” and we use ?: to say that we’re selecting value. for range loop claims this is important this piece of code is a loop, for_each put the emphasizes on what happens to the range. My 2 euro-cents

By: Jonathan Boccara

Jonathan Boccara — Fri, 30 Mar 2018 16:54:00 +0000

In reply to Helmut Mülner. Yes, thanks Helmut, it's fixed now :)