Recently, there seems to be a lot of debate about the future of C++. These discussions can be found everywhere, whether on Reddit, HN, or at meetings of the C++ Standards Committee.
1. The Current State of C++
Currently, the C++ we are using seems to be in the following situation:
1. The C++ Evolution Working Group (EWG) has just reached a consensus on adopting P3466 R0—namely, (re)confirming the design principles for the future evolution of C++:
-
ABI (Application Binary Interface) interruptions are not allowed, maintaining compatibility with C and earlier versions of C++.
-
Do not introduce “viral annotations” (e.g., no support for lifecycle annotations).
-
Adhere to a set of contradictory goals, such as requiring both ABI preservation and zero-cost principles.
This indicates that, whether good or bad, the direction of C++ development is further solidifying its current trajectory.
2. Meanwhile, on one hand, the U.S. government hopes people will stop using C++:
-
The U.S. Cybersecurity and Infrastructure Security Agency (CISA)
-
The U.S. National Security Agency (NSA)
-
Even the White House
As of now, various departments of the U.S. government have released documents, reports, and recommendations warning the industry against using memory-unsafe languages.
3. Various large tech companies are adopting Rust:
-
Microsoft is clearly rewriting core libraries in Rust: last October, Microsoft released a series of development kits on GitHub, allowing developers to write Windows drivers using Rust.
-
Google also seems committed to Rust: it first announced support for developing Chromium with Rust, and is also developing a bidirectional C++/Rust interoperability tool.
-
In 2019, AWS stated it would increasingly use Rust in its infrastructure and decided to sponsor Rust, allowing the Rust team to rent AWS infrastructure at a discount for language development.
-
……
Speaking of large tech companies, there are a few noteworthy events recently:
-
Not long ago, Herb Sutter, the chair of the ISO C++ committee, announced on his personal blog that he has left Microsoft after 22 years to officially become a technical researcher at the financial company Citadel Securities. Meanwhile, MSVC (Microsoft Visual C++) seems to be making slow progress on implementing C++23 features and is still soliciting priority opinions from the community.
-
The infamous Prague ABI voting incident occurred (in short: “C++ 23 will not break ABI, and whether it will break in the future is still unclear.”). It is said that Google has significantly reduced its involvement in the C development process and has begun developing its own successor language to C++, called Carbon. They even wrote a document summarizing the difficulties they encountered while trying to improve C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md).
4. Issues in the Community:
-
Many people have previously shared their efforts to participate in the C++ Standards Committee process, only to be completely drained. Even if some features have been implemented in C, it is of no use.
-
As of now, the module feature has not been implemented. Do we have modules? The answer is no.
-
Many people still remember that during the 2023 CppCon presentation, Bjarne Stroustrup, the father of C++, first introduced the concept of Safety Profiles, aimed at providing stronger type and resource safety for C++ while minimizing disruption to existing compatibility. The core of Safety Profiles is to guide developers in writing safer code through a set of rules and tools, while allowing different projects to choose the appropriate level of safety based on their needs. However, “Safety Profiles” are still in a strange state, with no existing implementations, attempting to add some degree of safety to existing C++ code while minimizing changes to existing code.Sean Gaxter, a developer from the C++ Alliance (creator of the Circle compiler), publicly opposed the profiles, calling C++ a “poorly defined” language.
I don’t know what you think, but from an outsider’s perspective, C++ seems to be fundamentally falling apart, and many people seem to have lost confidence in the C++ committee’s ability to address these issues.
2. The Two Factions of C++
People seem to be looking for other solutions.
For example, Google. Since the ABI voting, Google has clearly lost faith in “this standardization process.” This disappointment is not directed at the C++ language itself—Google has a large C++ codebase that has performed well for them. However, they have lost confidence in C++’s ability to continue evolving under multiple pressures (such as potential government regulation, competition from other languages, and the demand for higher performance and safety guarantees from large companies).
So where does the problem lie? Why can’t C++ make changes?
The answer is actually quite simple. We can refer to what Herb Sutter, the chair of the ISO C++ committee, said in his paper on profiles:
“We must minimize the need for changes to existing code. Based on decades of experience, for most customers with large codebases, even for safety reasons, they will not modify even 1% of their code due to strictness rules unless mandated by regulations.”
——Herb Sutter
This makes sense, doesn’t it? No one is surprised by this.
Now, compare this with the introduction of Google engineer Chandler Carruth on the WG21 member page:
“I led the design of Clang-based C++ tools and automated refactoring systems, which are now part of the Clang project… In Google, I led the team to extend these Clang-based automated refactoring tools across the entire codebase, over 100 million lines of C++. We can analyze the entire codebase and apply refactoring in 20 minutes.”
Do you see it? Here, Chandler Carruth mentioned a keyword: “automation tools.” But not just automated migration tools; this is just the most obvious example.
Opposition Between Two C++ User Camps
In fact, we are witnessing a conflict between two completely different camps of C++ users:
-
Relatively modern, capable tech companies that understand their code is an asset. (This is not strictly limited to large tech companies; any emerging C++ startup also falls into this category.)
-
Everyone else. Those still debating how to indent code in old companies, and young engineers trying to convince management to allow them to set up code checking tools.
The key difference between these two users is:the former can relatively smoothly handle migration because they can build the entire C++ stack from versioned source code, while the latter are still using outdated libraries from 1998.
This capability—building the entire dependency stack from versioned source code (preferably with automated testing)—is the most important dividing line between the two camps.
Of course, in practice, this is a gradual process. I can imagine how much sweat, tears, bills, and effort it takes to transform a large company’s codebase from a terrible mess into a somewhat manageable, buildable, code-checked, properly versioned, and slightly less terrifying mess.
In hindsight, it is easy to think that all of this was inevitable:the needs of companies like Google (using relatively modern C++, with automation tools and testing, and modern infrastructure) are clearly at odds with the strong desire for backward compatibility.
Boldly speaking,the concept of a single, dialect-free, and unified C++ seems to have been dead for many years. At least, we have two mainstream styles of C++:
-
A slightly more modern C++. Everything can be built from versioned source code through some dedicated, clean, and unified build process, at least slightly more complex than the original CMake, and if squinting a bit, it can work properly. It includes some static analyzers, formatters, and code checkers. Any consensus on keeping the codebase clean and modern is valuable. It is likely at least C++17, with features like `unique_ptr`, `constexpr`, `optional`, etc., but that is not the point. The important thing is the tools.
-
Traditional C++. That is, any C++ that does not meet the above conditions. For example, C++ stored on old servers in medium-sized banks. Any C++ that relies on some completely old and compiled code block, whose source code has been lost, and the original author cannot be contacted. Any C++ deployed on pet-type servers, to the extent that starting it elsewhere requires an engineer to spend a whole month figuring out all the implicit dependencies, configurations, and environment variables. These are primarily classified as cost center codebases. Any binary files used from source code require pressing more than a few buttons or are simply impossible to build.
You will notice that the divide between these two cultures is not about the C++ language itself, but about the tools and whether a clean, well-defined build can be made from versioned source code.
Ideally, it should even be deployable without needing to remember that flag or environment variable that previous developers typically set.
For example, whether Google’s codebase fully adopts “modern” C++ practices is not the point. The key is whether the tools are in place and whether it can be built from source.
Many people will say that tools are not the responsibility of the C++ Standards Committee, and that view is correct. Tools are indeed not the responsibility of the C++ Standards Committee because the C++ Standards Committee has relinquished that responsibility (they focus on language specifications rather than specific implementations). This is by design, considering the legacy burden, it is hard to blame them. C++ is a standard that unifies different implementations.
That said, if there is one thing that Go has done right, it is that they place great importance on tools. In contrast, C++ was born in an era older than linters. C++ lacks a unified build system, and there is no close to a unified package management system, the syntax is complex and difficult to parse (which is bad for tools), and every change struggles against Hyrum’s Law.
There is a huge and widening rift between these two factions (good tools that can effortlessly build from source vs. poor tools that cannot build from source), and there seems to be no possibility of bridging it in the short term.
The C++ committee seems determined to maintain backward compatibility at all costs.
By the way, I do not necessarily oppose this! Backward compatibility is very important for many people, and there are good reasons for it. However, for others, it is not important. This is not a matter of who is “right,” but a conflict between two completely different and irreconcilable positions.
3. Consequences
This is why the design of profiles is as follows:The purpose of safety profiles is not to meet the needs of modern, technically proficient C++ companies. They are designed to bring improvements without requiring any changes to old code.
Similarly, the design of modules is intended to allow you to “simply” import header files in module form without triggering any backward compatibility issues.
Undoubtedly, everyone likes features that can be directly introduced and bring improvements without changing old code. But it is clear that the design of these features is aimed at meeting the needs of “traditional C++”. Any features that require migration from traditional C++ are not feasible for the C++ Standards Committee because, as Herb Sutter said, you cannot expect people to migrate on their own.
(Again, considering the needs of traditional C++ is not a bad thing. This is a perfectly reasonable decision.)
I always keep this in mind whenever I read C++ proposals: C++ actually has two main audiences.One is modern C++ users, and the other is traditional C++ users. These two camps have vastly different views on many issues, and many proposals are written to meet the needs of one specific group.
Clearly, this leads to many people being unable to understand each other, and the conversation does not connect: although many people think that safety profiles and safe C++ are addressing the same problem, in fact, they are aimed at completely different audiences and solving completely different problems.
The C++ committee is trying to prevent this rift from widening further. This may be why Sean Baxter’s “Safe C++” is meaningless to them. This proposal is a radical and comprehensive change that could create a completely different way of programming in C++.
Of course, there are also questions raised about whether some members of the C++ Standards Committee are simply too stubborn, holding onto various reasons to prevent evolutions they personally do not aesthetically approve of.
Whether this is true, I cannot judge, but the claim that the C++ Standards Committee applies a “double standard” is not new. For example,“If you want this proposal to pass, we require you to provide complete, usable implementations across multiple compilers; but we are still willing to support certain large projects (like modules, profiles), even if these projects have no usable proof-of-concept implementations at all.”
If this is indeed the case (I cannot confirm), I cannot predict how long C++ can continue down this path unless a more severe split occurs.
Not to mention the huge troubles and series of issues that breaking ABI compatibility could cause; that would be a bottomless pit.
4. Where Will C++ Go in the Future?
Faced with the polarization trend brought by modern enterprises and legacy systems within the C++ community, opinions among netizens vary.
A user from Reddit, ravixp, stated:
This resonates with me, perhaps because I have witnessed a very large C++ codebase gradually transition from “legacy” C++ to “modern” C++ at different levels and scales. This transition involves different teams advancing at their own pace and timing, spanning decades of development, and is still ongoing. Any new code modernization plan must face the issue of inconsistent modernization levels across different parts of the codebase.
(Imagine trying to add static analysis support to such code: it contains a strange intermediate state with std::string, C-style strings, and a custom string type created by the team 20 years ago when STL performance was poor!)
The key point is that the cost of modernization is very high. The “modern” C++ mentioned here is not just about writing code differently; it also includes a whole set of tools that support modern standards, which may need to be built from scratch, along with an engineering team capable of keeping up with C++ evolution.
It is important to remember that the conflict here is not between those who “like legacy C++” and those who “like modern C++”; rather, it is a conflict between those who “can afford modern C++” and those who “cannot afford it.” C++ does need to change, but the real question is: how much change can we collectively afford, and how can we derive the most value from it?
Kronikarz commented:
From a moral perspective, I think this reflects a divide: one part of the people is indifferent to C++ gradually becoming the next COBOL, while another part is repulsed by this idea.
Another user, KittensInc, believes:
Legacy C++ is rapidly becoming a burden. The U.S. government has realized that by making different design decisions, certain types of vulnerabilities can be completely avoided, and is pushing people to reduce these errors. I believe that the agencies responsible for managing liabilities will eventually join this trend; it is just a matter of time.
If vulnerabilities like buffer overflows are considered completely preventable, then logically, if a hacking incident, ransomware event, or data breach is caused by a buffer overflow, insurance companies may refuse to pay. This would lead companies to require software vendors to conduct third-party static analysis audits of their codebases.
Thus, we reach a point where the cost of not modernizing becomes too high. You either upgrade your codebase, or your company faces extinction. Companies adopting modern development practices only need to run some simple analysis tools and complete some paperwork, while those without any decent tools and burdened with decades of technical debt will find themselves in serious trouble.
What do you think about this?
Author | Mond Translation | Tu Min