I just can't help but have the feeling that the ship is sinking and this article busies itself with arguing over how much spackle is sufficient to plug one of the many holes. There is too much UB allowed in the C++ spec to be worth saving at this point. Focusing only on CVE reduction still punts on all the money and time wasted with buggy software because the language cannot do much to prevent data races, for example.
There is a huge amount of large C++ code bases out in production that won’t be rewritten in a different language anytime soon. Improving C++ from within there is a worthwhile strategy.
A lot of these improvements sound like the code will need to be rewritten anyways. Granted, it might allow for a more gradual rewrite.
Gradual and targeted rewrites are at least an order of magnitude more affordable.
There isn’t too much UB for it to be fixed.
Fil-C fixes it (albeit just for C, for now). CHERI fixes it (and it works great for C++). There are other systems that fix it, too.
Unfortunely Intel and AMD keep shoting themselves in regards to memory tagging implementations.
Yep. The parallel universe in which this could have been fixed in a sound way would have had C fixed first (bounded pointers, semantics of UB made similar to JVM, etc) and C++ would have adopted that.
C++ also brings the baggage of dogshit syntax and extremely verbose and confusing types and error messages that new languages do not suffer from. I get why this guy who has built his career in C++ is defensive of C++, and certainly existing codebases cannot be migrated overnight or even ever, but I would not start a new project in C++ if I could help it.
[flagged]
> You sound like you don't have much programming experience.
Based on aesthetic judgments? That makes so little sense that one can make certain guesses about the motivation for such a comeback—best left unsaid.