PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.
With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.
I'm inclined to agree that for objects that are going to be created and destroyed very often, especially in tight loops, PIMPL is not an ideal idiom. I wouldn't use it to generate fleeting effects in graphics, for example.
For objects that are used in setting up parts of a system and that will persist for long periods of time, maybe even the lifetime of the app, PIMPL is particularly well-suited for such classes. Classes that might manage networking, or encompass an entire part of app's running architecture, etc.
Thw complexity and overheead of PIMPL is justified in one scenario, and one scenario only - when you are writing a shared library and need to maintain a stable ABI. Otherwise it is complete overkill.
20 year C++ programmer here. I work on multithreaded server code. Stopped using modern C++ features 5 years ago. I'd compare my use of C++ to be roughly equivalent to the use of C++ in the NodeJS project or the V8 project. I'm not a user of Boost.
I have to agree with the author of the article. It takes longer to train developers to write idiosyncratic modern C++ code and compilation times explodes. Compiler support for bleeding edge C++ features is spotty at best. Harder to reason about the correctness of modern C++ code.
I continue to use babel 5.x which is much easier to use than babel 6.x which cannot be globally installed. Babel 5.x supports jsx by default. Would be great if buble would have feature parity with babel 5.x to ease the switch over.
Hey Rich, I wish some time you would write more about magic-string and what makes it special. You say "no costly code generation step", but what makes codegen costly compared to what you're doing in magic-string?
I plan to write about this in the near future (in fact I'm writing slides for a talk on it this week) – essentially, codegen is more costly because a) you have to generate the entire program, rather than just modifying the nodes that have changed, b) your code generator needs to know about every single node type, and c) you have to keep track of state (e.g indentation levels).
