Flatmap implementation
There's a reason the algorithms in the standard library use iterators instead of dealing with containers directly. One is that it makes code like this quite a bit simpler. For example, using iterators, we could write Flatmap something like this:

template &lt;typename InIter, typename OutIter, typename FN&gt;
void Flatmap(InIter begin, InIter end, OutIter out, FN fn) {
    for (; begin != end; ++begin) {
        auto y = fn(*begin);
        std::copy(std::begin(y), std::end(y), out);
    }
}


This is somewhat more versatile, since it can take input from/write output to essentially any iterator, rather than necessarily reading from one vector and producing another vector. Likewise, what's produced by fn doesn't have to be a vector either--it can be essentially any container (anything for which we can use std::begin() and std::end(), to be more exact). While vector is certainly common, there are reasons for using other containers--and sometimes even a reason to write to something that isn't exactly a container either. For example:

std::vector&lt;int&gt; inputs { 1, 2, 3 };

Flatmap(inputs.begin(), inputs.end(), 
        std::ostream_iterator&lt;int&gt;(std::cout, "\t"), 
        [](auto x) { return std::vector&lt;decltype(x)&gt; { x, x * 2, x * 3 }; });


Note that I've used auto as the parameter type in the lambda, so this test code requires C++14, but Flatmap itself is fine with C++11.

If you wanted to be a bit more forward thinking, you could write this to work with ranges instead of iterators. Eric Neibler's range library is fairly nice, and seems well on its way toward being included in an upcoming C++ standard.

Along with the code being simpler and more versatile, the other obvious advantage would be that this follows the same style as standard library code--for example, its signature and usage is essentially identical to std::transform.