The examples are clearly achieving the goal of "concise". I would counter with a different style though, because I try to imagine how the code would change over time and how it would fare when given constraints on memory and runtime.<p>Compare:<p><pre><code> for (int x : numbers) {
if (1 == (x % 2)) {
odds.push_back(x);
}
}
auto odds = KeepIf(IsOdd, numbers);
</code></pre>
To me, the first case is preferable. The 2nd case uses custom functions that may not be familiar to the maintainer, and semantics are clearly hidden (e.g. does KeepIf() modify the list, return a copy, or return some kind of intelligent generator object that still depends on the lifetime of "numbers"?).<p>Suppose I discover that my application starts crashing with the odd number 15 and I have to work around that case very quickly. The loop version above is trivial to modify, whereas I have <i>no idea</i> how the 2nd version would be modified to filter out one value! And if I want to do several things with the numbers while they're being found (e.g. print them out), the loop is easy to change but the 2nd version basically has to be replaced entirely (and replacing even a concise expression is risky due to the issues above, e.g. unclear semantics).<p>Now compare approaches for another case:<p><pre><code> if (FindWord("I", team)) ...
if (Contains("I", SplitWords(team))) ...
</code></pre>
This shows a general problem with a "functional style" at times: it's placing constraints on the implementation that don't need to be there.<p>To me, the first style is preferable because FindWord() could easily walk a raw string and <i>stop</i> as soon as it finds the target word, with a chance for better-than-N average complexity. The second case would mandate: copying strings, visiting all characters in the string every time, and revisiting at least some of the characters in the form of words.<p>Finally, I think that the C++ standard algorithms, lambdas, and compact-"for" do allow a lot of these tricks to be avoided. Consider algorithms like std::all_of() for instance, which can be combined with lambdas to produce the same results as examples like "AllBy(And(..." but without the downsides I mention at the beginning of my comment.