... and you have to work really hard to make C or C++ run any faster than the JVM. For all normal levels of programmer effort there is no difference or the JVM is faster.
I see your point, but then money is money. So, why pay MS anything? Why is computing treated in this unique way where minimizing cost is not standard practice?
Oracle moving on from the 1.6 doldrums was a huge plus for Java and the JVM. Now the buzz is around 1.8 with lambdas and enhancements to performance of invoke dynamic.
Makes sense - the JVM is fast and stable. It comes with a huge array of tooling and its own built in debugging system. It is well supported and cross platform. Why would you not want to take advantage of all that good stuff?
In this case a team could work across the project. One on the parser/lexer one on AST translation, one of code generation, Two on the runtime and 1 on build/ci. I think that makes 6.
The JVM has a huge advantage over the CLR in that Mono is nothing like as well supported as Oracle supports the JVM and Microsoft's CLR is Windows only - which makes it far to expensive for cloud computing.
The implementation is compiler dependant. Nevertheless, it would appear that the normal implementation is to create something which looks like a normal object with pointers back to the state it closes around. In theory it should be fast and light. The problem (as always with C++) is ensuring that the things to which the pointers point does not go away. Smart pointers help - but they are slow...
Which kinda goes to my point about out of memory exceptions - they generally end up being fatal sooner or later. Trying to catch them just results in memory running out somewhere else. The only place you can deal with them is if the code is doing something you expect to cause memory issues because it is consuming an atypically large amount of memory (like a cache or some such) which you can get away with shrinking.
... because the compiler knows how big the function like object will be at compile time when the template is used but it only knows it at runtime if the class is used. ...
That is really nice. Could you expand on how this works a little "You can also avoid problems with exceptions and std::function’s dynamic allocation by using a template instead:"
I get your points. In general, the use cases for this pattern are not production code. The post points out this is not a good way of handling resource and that the example is about debugging. It would be up to the implementer to ensure the finally clause does not throw and exception or to catch it (I think there is something about nesting).
As for memory allocation failures, my experience is that depends a lot on the platform. It is a common misconception that dynamic memory is likely to run out and therefore we need to worry about that but not automatic memory. However, I have seen stack overflow many many many more times than a genuine 'out of memory'. Further, if an application has actually run out of memory so badly that a allocation of the closure's internal storage barfs then I suspect it cannot be retrieved. Naturally this does not apply if your platform has a very low heap size (e.g. realtime hardware or some such).