Let me tell you about watching a titan fight for his legacy. Bjarne Stroustrup, the 74-year-old Danish computer scientist who gave us C++ back in 1979, is now locked in what might be the most consequential battle of his career. Not against Rust evangelists or government regulators—though they’re certainly in the mix—but against the perception that his language has become a liability in the age of memory safety paranoia.
The Profiles proposal isn’t just another C++ evolution; it’s Stroustrup’s attempt to retrofit safety onto a language that was never designed for it. And the way it’s playing out? It’s tearing the C++ community apart like nothing I’ve seen in my three decades working with the language.
You want to understand why Stroustrup is pushing Profiles so hard? Look at the timeline. Back in 2015, when he unveiled the C++ Core Guidelines at CppCon with Herb Sutter, the safety conversation was still academic. Those of us in HFT were more worried about nanosecond latencies than memory corruption. The Guidelines were positioned as best practices, not survival tactics.
But something shifted around 2022. The NSA started making noise about memory-unsafe languages. Then CISA jumped in. By February 2024, the White House itself was calling for memory-safe programming. Suddenly, C++ went from being the backbone of global infrastructure to public enemy number one in the security world.
Stroustrup’s response in his February 2024 paper P2739 was telling: “This is a call to urgent action partly in response to unprecedented, serious attacks on C++.” The man who spent 45 years building this language now watches as government agencies basically declare it unfit for purpose. You think that doesn’t sting?
Here’s what most people miss about the historical context. Stroustrup has been thinking about safety since the beginning. In his 1991 history paper, he wrote about how C++ deliberately kept C’s unsafe features because “the language could not guarantee such checks without leaving C with a large advantage in run-time and space efficiency.” The decision to prioritize performance over safety wasn’t ignorance—it was a calculated trade-off that defined an era of systems programming.
So what exactly are Profiles? Let me walk you through the mechanics, because the devil’s in implementation details here.
Profiles work on what Stroustrup calls a “subset-of-superset” strategy. First, you extend C++ with some library abstractions (the Guidelines Support Library or GSL). Then—and this is the controversial part—you ban certain language features within specific contexts. The result is what Stroustrup colorfully calls “C++ on steroids”: the good parts amplified, the dangerous parts suppressed.
The initial proposal focuses on three core profiles:
The type profile eliminates uninitialized variables, unsafe casts, and union abuse. The bounds profile prevents array overruns and pointer arithmetic gone wild. The lifetime profile—the most ambitious—attempts to track object lifetimes statically to prevent use-after-free bugs.
What makes this different from just following coding guidelines? Profiles are meant to be compiler-enforced, not suggestions. When you mark code with a profile, the compiler becomes your enforcer, refusing to compile code that violates the profile’s guarantees.
The GSL provides the supporting cast—types like span, not_null, and owner that make safe patterns more ergonomic. But here’s where it gets interesting: Stroustrup insists this is “100% ISO standard C++.” No new language, just restrictions and library support.
Now we get to the drama. While Stroustrup was pushing Profiles, a brilliant engineer named Sean Baxter was building something far more radical. Baxter, the madman who single-handedly built the Circle compiler from scratch, proposed Safe C++ (P3390)—essentially grafting Rust’s borrow checker onto C++.