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...
I think the most common use case for blocks in C++ are functional-ish STL algorithms, unlike C blocks, which were built for async operations. In that use case, they absolutely shine - since they don't outlive their parent scope, no memory management is necessary, they can be inlined and ideally add no overhead. I think this easily outweighs the cases where you need slow shared pointers.
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.
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:"
std::function can store function pointers (and member function pointers) by value, but using a function-like object that defines operator()—or by extension std::bind()—requires dynamic allocation, which can throw. The templated version, on the other hand, always stores its parameter by value. Come to think of it, you could also make the constructor take an rvalue reference (F&&) to use move construction instead of copy construction.
... 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. ...
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).
As someone who has done the interviewing thing, I can see where this article is coming from. I don't really buy into all of it though. All this stuff about being a great communicator. That is cool but not always required. I have spent a lot of time working with amazing people who are crap communicators and crap people who are great communicators.
But - I am sure a lot of people interviewing use indicators like these so it it worth knowing about them.
Finally, on the CV thing. This is a hard issue because agents look for buzz words. If you've done a lot of stuff you need to write a lot to get all the buzz words in. That is the only way the agent will forward our CV. Then - you cannot tailor the CV to the job because you did not submit one for that job, you submitted one for buzz words.
Yeah, it tends to make me a bit irritable after the 500th time I've seen a resume touting the candidate's skills with DreamWeaver, so I sympathize. But while the article is a well-intentioned rant, it's still a rant.
In short, if you're looking for a job, try to put yourself in the position of the interviewer and adjust your approach accordingly. Don't go in cold, and don't assume the interviewer will make allowances for you.
Nice links thanks. Would you agree that there is at least a similarity in purpose between Currying in functional languages and fluent interfaces? It seems to me that techniques and ideas from partial application and currying are useful in the design and implementation of fluent interfaces.
I agree there is some similarity. Also other functional concepts like closures (although not available in Java) are useful in building fluent interfaces.
Now the idea of open digital communication is well established, legal frameworks will not be able to do anything but slow it down. Whilst the US government is producing laws to stop free/open digital coms they are also developing stuff like internet-in-a-suitcase which is designed to get around 'repressive governments' which do to allow open access to the internet. This indicates the stupidity of using legal systems to control communication in this way.
