Huh what lisp functional programming whaa...?! LISP is as imperative as it gets. The key feature of LISP is that code is data. That way you can run complex things at compile time -- things that write code for you, generate tables, implement domain specific languages, etc. The functional features are an afterthought and not really in any way key to LISP's power. They are a commonplace in most languages these days. I mean, come on, once you have function pointers in C, you can directly emulate all of LISP's "functional" features save for ones that need to generate code at compilation time (or runtime, too). It's not like qsort(...., int (*cmp)(const void *, const void*)) is not possible in C, you know. Lambda is very nice syntactic sugar, but not impossible to live without. Same goes for continuations: it's possible all right to have continuations in C and C++, just that you have to make to continuation state explicit in a data structure. Heck, it's even possible to have full-fledged coroutines in C -- again, you have to code for it, and it doesn't look pretty, but it's not technically impossible. No stack switching hacks needed. Of course if you want to run arbitrary C, you need stack switching :)
The template metaprogramming in C++ is a completely unnecessary crutch. It's there only because nobody had the balls to have full-featured compile time code execution in C++. Once you have that, you can write things in a much easier to interpret way using simple imperative style. C++ is, at heart, an imperative language. The fact that you need a functional-style language added to it just in order to work around a reasonably simple deficiency is quite telling. C++ basically requires you to learn two languages that have nothing in common, that use completely different idioms, etc.
Just look at how much trouble there is making the C++ metaprograms actually execute decently in the compiler: now a C++ compiler is not merely a compiler, but also a functional programming runtime / virtual machine! Those things are hard to make to run well -- just look at how long it took Haskell people to get something semi-useful. Adding template functionality that allows metaprogramming to C++ suddenly doubled or tripled the effort required to implement a C++ front-end. Whoever thought it a good idea should be shot.
What would have been the problem to simply let C and C++ compilers run code that is declared as a macro, just like LISP does it? This would have solved everything one uses templates for. A C/C++ host-targeting compiler shouldn't have any problems in extracting the macros, compiling them and running them -- and then consuming their output.
Instead of doing the simple thing, and leveraging the skills of imperative mindset already needed to be an effective C/C++ developer, the C++ language designers have implemented a limited, hard to implement and hard to use functional programming crutch that effectively doubles the requirements placed on the end user. Never mind the poor sods who implement the C++ front end and have to take constant flak from folks who actually want to use the damn feature without having to endure hour-long compile times and multi-gigabyte compiler resident sets just to get through a 10-line metaprogram. Give me a fucking break. Most of boost's metaprogramming stuff is there to basically say: hey, if it really worked here's how it'd look. Then you try to actually use it, and you run into the silly compiler-imposed limitations quicker than it takes to read this sentence. Large scale template metaprogramming is, essentially, completely impossible. About the only thing it's good for in practice are eigen-style libraries. Everything else it promises is summarily non-delivered. It's not funny.