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…
> 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. Funct…
Manipulating C++ Containers Functionally
11–12 of 12 posts
Yeah, but those "implementation details" are often relevant. I want to know if I am creating a bunch of extraneous copies when iterating through a container. It may not always matter, but sometimes it does, and performance matters more than functional purity.
Re: Manipulating C++ Containers Functionally
#12I do agree that C++'s STL is sometimes too verbose. It's important to be generic, but it'd have been great if the most common conveniences were added as well to make it pleasant to use. E.g.: erase remove idiom, count but no contains, specifying begin() and end() even when you mean the whole container, ... Anything where you need to type the variable name of your container more than once to do one operation on it. No…
There is STO library: http://github.com/lvv/sto
> E.g.: erase remove idiom
remove sub-string: string("abcd") - "cd"
> specifying begin() and end()
unary '+', '-' overloaded to return to begin()/end()
> when you mean the whole container, ...
Euler example in just one expression (with boost lambda): range(1000) | (!(_1%3) || !(_1%3)) | add