3 ms·
Although I've been doing C++ for about a decade now, the one thing that is making me somewhat wary of its future is the difficulty of versioning key components
by _huayra_ 5y ago
Although I've been doing C++ for about a decade now, the one thing that is making me somewhat wary of its future is the difficulty of versioning key components of the language. Sure there are tricks with namespaces to version things to get around ABI breaks (to a degree; this is a world of problems), but fundamental features of the language are set in stone in a way that is very unfortunate.
The latest I've come across is the "R-value lifetime disaster". Arno gave a great talk at cppnow this year [0] highlighting this and Arthur O'Dwyer gave a great rebuttal / follow-up that is also worth considering [1]. The gist of it is that have const& also bind to r values (T&&) causes information about the lifetime to be thrown away. In reality, the "universal binding" ought to have been const&&, as that encodes "can't modify this thing" and "it may not live longer than this function call". This is quite a footgun, but I'm not sure if there's a way to change it with some sort of "language epochs", especially considering that this will have to be exposed in modules / headers so that different "epochs" don't try to link to or use each other's code!
[0] https://www.youtube.com/watch?v=sb7cj-3l1Kc https://www.youtube.com/watch?v=sb7cj-3l1Kc
[1] https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetime-disaster/ https://quuxplusone.github.io/blog/2020/03/04/rvalue-lifetim...
- ncmncm 5y agoThe importance of the observation is radically exaggerated. When the compiler can see both the call site and the function definition (such as when the function is inline, or a template) it is free to ignore ABI. If there is a break, it will either be wholly backward-compatible, so that new code can still call old functions, or be a whole separate build target, like the jump from x86 to amd64, with no possibility of linkage mistakes. (There must be people reading here who don't recall the move from 32- to 64-bit x86. It was wholly painless for programmers; not so much for OS distributors.) Imagine building for ARM today; you are at absolutely no risk of accidentally linking x86 code.
- _huayra_ 5y agoYes when you can compile from scratch it does not matter anymore, but as you mentioned it has mostly to do with software vendors (OS distros, proprietary apps, etc). There are things that are basically disallowed for upgrades in the standard library because certain things (e.g. class member layout, default vs. empty user-defined constructor, such as the register promotion issue when pair<> was '=default' from the empty constructor). I think Marshall Clow gives a pretty good overview of the ABI issues at a high level [0]. [0] https://www.youtube.com/watch?v=-XjUiLgJE2Y https://www.youtube.com/watch?v=-XjUiLgJE2Y