C++ creator responds to White House warning, but there's

In a March 15 response to an inquiry from InfoWorld, Stroustrup pointed out strengths of C++. “I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,” Stroustrup said.

Stroustrup highlighted a key fact at the root of the issue:

There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ.

This highlights a significant problem with C++. When any programming language permits the execution of potentially harmful actions, it shouldn't come as a surprise that a considerable portion of developers may misuse it.

And when confronted about writing bad code, developers may offer various arguments to justify their actions, though these are often excuses rather than valid reasons:

Tight Deadlines: "I had to rush because of tight deadlines. There wasn't enough time to write clean code."
Legacy Code: "The existing codebase is messy and poorly structured. My changes just blend in with the existing mess."
Scope Creep: "The requirements kept changing throughout the project, making it difficult to maintain clean code."
Technological Constraints: "The technology stack we're using isn't suitable for writing clean code. We're limited by what we have."

So yes, developers have a responsibility to ensure that they write their C++ code properly. However, this kind of approach could be risky for the future of C++. A few years ago, we witnessed Nokia’s decline. Indeed, Nokia's decline from being the world's leading mobile phone manufacturer to struggling in the market is a story marked by several factors and strategic missteps. One of Nokia's critical mistakes was its decision to stick with its Symbian operating system for too long. While Symbian was once a dominant platform, it struggled to compete with the user experience offered by iOS and Android.

In C++, we have relied on the current memory-management mechanisms for too long, and no radical solution has been suggested, only a few improvements that need to be applied by developers.

C++ vs .NET strategy:

C# was developed in 2000 primarily for Windows machines. Miguel de Icaza created Mono to enable its use on Linux and macOS. However, after over a decade of predominantly using the standard .NET framework on Windows, a significant issue arose regarding the language's portability. To address this, Microsoft collaborated with Miguel to create .NET Core, a subset of .NET designed to function on other operating systems.

This was not an incremental solution to the portability issue, but a radical one, even though some legacy code was incompatible. At that time, Miguel de Icaza described .NET Core as a "redesigned version of .NET that is based on the simplified version of the class libraries", and Microsoft's Immo Landwerth explained that .NET Core would be "the foundation of all future .NET platforms".

Ultimately, this solution worked very well: .NET Core became widely used, and the big portability issue was resolved.

Why not take a similar approach with C++ to address safety concerns more decisively? Why not develop a safe subset of C++ and provide the option to work with this subset through the compiler?

clang --safe

Conclusion:

If C++ continues to allow developers to engage in unsafe memory practices, this significant safety concern will persist, potentially leading to other languages such as Rust or Go being preferred for new projects. Maybe it is time to consider a more radical solution rather than relying solely on incremental improvements. Certainly, experience has demonstrated that despite the availability of modern features in C++ aimed at addressing safety concerns for over a decade, the issue persists due to the language's continued allowance of unsafe legacy practices.