I would recommend instead Facebook's folly::gen library, which provides these functional combinators in a high-performance fashion, by expressing them as streaming combinators. You get all the map/filter/take/drop/reduce primitives, but in a much cleaner way.<p>See <a href="https://github.com/facebook/folly/blob/master/folly/gen/test/BaseTest.cpp" rel="nofollow">https://github.com/facebook/folly/blob/master/folly/gen/test...</a> for an example.
One of the main reasons to use C++ today is the potential for high performance. One of the examples given is a great demonstration of what not to do: allocate a new container on the heap, scan it once, and delete it. I'm talking about the "I in team" example, which if you coded it by hand would almost certainly use a better algorithm. It's hard enough teaching people to avoid inefficiency when it's right there in front of them, and harder still when you encapsulate inefficiency in a pretty package. This is why some "obvious" functions don't exist in the STL.
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.
While working on my last projects I accumulated a collection of pure functions I needed now and then. So I thought, why not write a short pitch as a README and make it public? So here it is.
It would be very nice of you if you could tell me what you think, so I can learn and improve.