I think going this way is going to turn out painful. The sort of immutable container logic that people associate with FP is against the nature of C++ and you'll be constantly bumping into other people's code, and parts of the library, that don't like it.
C++ style prefers
for_each(xs.begin(), xs.end(), f);
to
xs = std::transform(xs,f);
Because the first does not copy the container and its elements, which in C++ is a meaningful operation which may not be allowed for xs's elements, or may be remarkably expensive.
I thought the annoying verbosity when using the whole container with <algorithm> was fixed in C++11 like it was for for loops, but I can't find documentation to that effect. Boost's range algorithms library is still useful here:
> The sort of immutable container logic that people associate with FP is against the nature of C++...
My argument is that C++, a multi-paradigm language, benefits from not being bound to purity and that being able to mix imperative and functional code is a good thing. We aren't stuck in pure-land so we can insert IO where it needs to be, not where it propagates, but neither do we need to be stuck in state-land. Functional programming is not against the "nature" of the language, it gives us the freedom to choose.
> Because the first does not copy the container and its elements...
This is a quality of implementation detail. It would have been detrimental to the point of the article to waste time showing optimizations such as "if F is a function X to X, use the in-place version". But I assure you, my optimization testing has shown there is little difference between the code generated by this and vanilla <algorithm>. In fact, it is at times better.
C++ style prefers
to Because the first does not copy the container and its elements, which in C++ is a meaningful operation which may not be allowed for xs's elements, or may be remarkably expensive.I thought the annoying verbosity when using the whole container with <algorithm> was fixed in C++11 like it was for for loops, but I can't find documentation to that effect. Boost's range algorithms library is still useful here:
http://www.boost.org/doc/libs/1_52_0/libs/range/doc/html/ind...