This is a pretty flippant response to a rather insightful point by someone who isn't exactly a newbie to the language. They understand very well the implications of move being nondestructive and the point they're making stands nevertheless.
Let me clarify something here (And my apologies if this looked a bit aggressive).
There is always a cost to abstraction, and that can take different form. In C++, it is often build time (and/or complexity). And Chandler, in his talk, is perfectly right about that.
But that does not change the validity of the C++ concept 'zero cost abstraction at *runtime*'. It is possible to get proper language abstractions while not sacrificing runtime performances.
I did get sharp on his comment because this talk is constantly posted by a specific C crowd that profoundly hate any form of abstraction and use it as a totem to justify terrible development practices.
If your language support zero cost abstraction and genericity, by the sake of god, use it... most of the time the impact in term compilation time is worth the benefits.
You're not only undeservedly dismissing very salient high-level points but also just completely missing the low-level ones. Even ignoring build times and looking only at execution times (and btw it's not just time that matters here), even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others.
Nobody is concluding you shouldn't write functions either.
My remark is still valid. Even considering memory space and cognitive complexity.
> even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others
Divergence about the support of inlining in compiler implementation have nothing to do with the debate here. Some idiosyncrasy about C++ argument passing and lifetime might causes a cost in some specific scenario, still that is specific to C++.
It still does invalid the concept of zero runtime cost for abstraction.
As much as people like to dismiss it, Stepanov was right all along.
> Nobody is concluding you shouldn't write functions either.
Then, you will be surprised to learn that some 'devs' actually recommend exactly this and write guideline that minimize the number of function written. They tend to be from the same crowd that the one was describing before.
