Bjarne Says C++ Is Under Attack

Bjarne Stroustrup, the creator of C++, has issued a call for urgent action from the C++ community and standards body after U.S. cybersecurity guidance and other experts pushed memory-safe languages like Rust, Go, and Java toward the center of security policy. The core claim is that C and C++’s manual memory management leaves too many opportunities for memory safety failures—out-of-bounds reads/writes, dangling pointers, and related bugs—that have become a dominant source of vulnerabilities and costly exploitation in large codebases.

The pressure point is policy. A U.S. government report from CISA (issued last October) advises that by January 1, 2026, manufacturers using memory-unsafe languages should produce a memory-safety roadmap that eliminates memory-safety vulnerabilities or switch to a memory-safe programming language. That timeline has intensified skepticism toward C and C++, even as the C++ ecosystem has proposed multiple “safer C++” pathways—such as Safe C++, bounds-checking approaches, and other profiles-based ideas—rather than a wholesale replacement.

Stroustrup’s intervention centers on a “profiles” framework aimed at making memory safety enforceable in C++ without abandoning the language. In a February 7 note to the C++ standards committee (WG21), he frames the moment as more than incremental progress: it’s a need for a public narrative and visible, credible steps that can compete with the industry’s strong momentum toward Rust. The argument also leans on C++’s long-standing goals around type safety and resource safety, positioning memory safety as an extension of C++’s original design aims.

Not everyone is convinced. Critics argue that “opt-in” safety is unlikely to be adopted widely, and that marking code with profiles could break existing language features—effectively forcing developers to rewrite code to keep compiling. There’s also a deeper concern that memory safety cannot be guaranteed consistently across compilation units when developers mix subsets, extensions, and different safety modes.

That skepticism is echoed in related technical pushback. A visiting researcher at the University of Cambridge and a systems architecture director at SECI Semiconductor questions language-level solutions when real systems span multiple languages. Even if Rust or C++ code is “safe,” unsafe boundaries—such as foreign-function interfaces—can reintroduce memory hazards. The same concern applies to interruption and cross-language integration: safety models can fail when other components don’t respect ownership and lifetime rules.

Meanwhile, the transcript highlights alternative approaches that try to make migration less disruptive. One proposal discussed is Trap C, which aims to enforce memory-safe behavior at compile time by transforming pointers into checked “memory safe pointers” and preventing buffer overruns and segmentation faults. Another thread emphasizes that rewriting billions of lines of legacy code is risky and bug-prone, so incremental modernization—through tooling, tests, and gradual adoption—may be more realistic than a revolution.

Overall, the dispute is not simply about which language is “best,” but about feasibility under deadlines, how to enforce safety across large, mixed-language systems, and whether C++ can regain trust with credible mechanisms before policy and industry momentum lock in a different future.