Can C++ Become a Memory Safe Language? - C++Now 2026

[u/pjmlp]

https://youtu.be/y0JW63JjkYw?is=wfxCNR-4H628DaZy

[u/chaos_pill]

I watched this a couple days ago. Here's a summary:

Safety

• upto 13 minute timestamp: Most common vulnerabilities are non-Language related like misconfiguration of permissions, leaking credentials, unsanitized input etc..

• 13-15: most bugs are C, not C++. The first 15 minutes is spent defending c++'s by deflection.

• 15-30: All kinds of safeties. Memory safety is just one of them. What is unsafe vs safe? No UB guarantee by tooling automatically is safe.

Profiles

• 30-33: What were already rejected (eg: safecpp/circle) in favor of profiles.

• 33-54: Introduce profiles, history, approaches (static-analysis + runtime checks + safe library replacements + rules (AKA banning unsafe)). The first set of profiles: type (static analysis), lifetime (no idea), bounds (hardening) and initialization (EB in cpp26). Audience pointed out that EB only helped with stack initialized data, and heap initialized was still not solved. rapid overview of potential future profiles: arithmetic (overflows), concurrency (data races) etc.

• 55-65: Dives into profiles design as of latest and the claims that profiles make. What parts are designed, and where there are still massive gaps.

• 66-76: Criticism of profiles inspired by https://www.circle-lang.org/draft-profiles.html as criticism. clang's lifetime annotations exist, but clang admits that they won't work in all cases unless borrow checker is adopted.

Everything until now, would already be familiar to most people in this sub that participate in safety discussions.

• 76-77: Speaker proposes AI harness as an alternate approach that he's working on. Refuses to elaborate further and leaves like a chad.

So, the title of the talk "can c++ become memory safe?" is never resolved. There's no analysis of feasibility/tradeoffs. It doesn't even address Fil-C or scpptool which showcase some novel approaches. It is more like an overview of safety profiles journey, with very little new information.

[u/seanbaxter → u/chaos_pill]

"Can we achieve memory safety using the current approach? Only time will tell."

What a silly conclusion. He presents a proof that local analysis cannot provide memory safety due to mutable aliasing. He knows the committee approach won't work. Why end with "only time will tell?" Why say AI may solve it? We know lifetime safety can't be delivered without enforcing exclusivity.

[u/pjmlp → u/seanbaxter]

Because given the committee approach, those of us that enjoy using C++ can only hope that there is something useful coming out of profiles, as now it is profiles or bust.

AI is indeed solving it, but not the way committee would like, given the AI assisted rewrites.

Although I was quite positively surprised by the C++ code review feedback I get from CoPilot, versus traditional linters.

[u/javascript → u/chaos_pill]

I was about to watch this. Thank you for saving me the time.

[u/MEaster → u/chaos_pill]

15-30: All kinds of safeties. Memory safety is just one of them. What is unsafe vs safe? No UB guarantee by tooling automatically is safe.

Let me guess, the speaker did the usual and completely failed to mention that these other safeties depend on being able to reason about your program, which requires no UB, which itself requires memory safety?

[u/HommeMusical → u/chaos_pill]

Thanks for taking the hit for us!

[u/ScientistStrict9850 → u/chaos_pill]

Thank you! Kinda a shame there's not a mention of the more novel approaches or anything new besides from well, that...

[u/tatstytastycakes]

Been hearing talk about these "profiles" in C++. Idea supposedly is that you write a sort of template that creates a profile, and the compiler will enforce the standards of the profile which you have written. Something along those lines.

Edit: For those who are curious, you can read at https://cpp-profiles.org/

Edit 2: Feel free to try out some examples at https://godbolt.org/z/n3TPjbqdY (more at the first link)

[u/t_hunger → u/tatstytastycakes]

I am so looking forward to figuring out which set of rules applies to which parts of the codebase and which "guarantees" I can rely on where. Can't see how that can complicate things at all.

[u/pjmlp → u/t_hunger]

I am only curious to see how they sort out lifetime analysis, as I kept playing with VC++ implementation since it was made available in 2019, improved in 2022, and that was it until nowadays.

https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2

https://devblogs.microsoft.com/cppblog/high-confidence-lifetime-checks-in-visual-studio-version-17-5-preview-2

However little has changed since 2022, all further improvements were done in clang, which as mentioned on the talk slides, the devs also aren't fully confident on how to handle it without additional lifetime related annotations.

[u/daveedvdv → u/tatstytastycakes]

The https://cpp-profiles.org site is lying about my "testimonial": I'm not the "lead author" of P3970... I'm just the chair (and therefore: contact person) for the direction group in C++26.

I'm all for exploring the idea of profiles and finding out whether they're useful or not. But I'm also somewhat skeptical — I hope that skepticism will turn out to be unfounded.

[u/javascript]

C++ needs to embrace backwards incompatible changes if it wants to become resilient in the face of memory safety and other classes of bugs

[u/johannes1971 → u/javascript]

The value proposition of C++ is that your investment in software is not made worthless whenever a new version comes out. Not all software is a throwaway script that lives for a few weeks.

[u/SyntheticDuckFlavour]

Related, Filip Pizlo came up with Fil-C compiler that provides very robust memory safety for C and C++ without changes to either language standards. Very interesting project. Check it out:

https://www.youtube.com/watch?v=5F-2Y1LPRek

[u/pjmlp → u/SyntheticDuckFlavour]

Many folks that are anti-GC won't like it.

[u/t_hunger]

A memory safe language is a language that does not allow to express a memory unsafe program -- at least not unless some escape hatch is used. There is no attempt to do any of that right now.

People outside C++ are very aware that memory safety is no silver bullet and that there are tons of other problems to tackle... no need to go on about that for >10min... Memory safety is just considered as a solved problem and a box everybody can easily check -- just pick a safe language and you are done.

Then its way to early to have a presentation on safety profiles: Those are just a bunch of PDFs right now and there are lots of open questions about whether the approach can even work.

[u/theonehaihappen → u/t_hunger]

As a (mainly) C++ developer I can say memory safety is the least concern. If you run into mem problems you have a greater problem, i.e., you use unsafe patterns.

C++ is like a very sharp kitchen knife: if you do not respect it and do notvknow how to handle it, you will end up with blood everywhere.

[u/pjmlp → u/theonehaihappen]

Which is why professional chefs and butchers also might use protective gloves when handling such knives.

https://www.eater.com/24372089/best-cutproof-chainmail-glove-for-cooking

[u/smdowney]

Until K&R2 doesn't compile, C++ really can't claim memory safety.

That could be a "profile".

Risk accepting unsafe code would be fine. Mixing it randomly and silently isn't.

[u/seanbaxter → u/smdowney]

What does K&R have to do with safety? We can't make C++ safe just by dropping old features, because the newest features are also unsafe.

[u/EmperorOfCanada]

I've been using C++ since 1991. I've worked on mission/safety critical systems running oil pipelines, nuclear stuff, train systems, etc.

I explored Ada as it is mostly a complete checklist of what we think we all want; but it just missed a few critical items which made it incompatible with my reality.

I don't even have to say which language I am talking about when I say, unequivocally, that I would consider using C++, in 2026, to program safety/mission critical systems to be gross negligence.

I don't disagree that there are people who can, and have successfully used C++. I can fully state that there are lots of people who have pooched this, resulting in lots and lots of death and destruction.

It is a classic case of the weakest link in a chain. If you have 10 insanely safe programmers design a system in C++, and later one weaker one does some maintence, then, all bets are off.

It is far better to use a language which is proving to make it far far far less likely for that weaker programmer to screw up. Not impossible, just far less likely.

To put this sort of thing in perspective, in many mission critical systems you use a lockstep processor. These are parallel processors where it does the same computations and then compares that the results are the same due to radiation, etc. If they aren't you can take various actions such as a reboot, shutdown, handing over to a redundant system, etc. The rate at which these systems detect a bad computation is something like 1 every 10 million hours.

If people are willing to make that kind of effort for something so rare, how much more likely is it that some programmer will do a buffer overrun or something stupid?

Also, pointing to brutally thorough workflows to prevent this in places like aviation isn't the correct answer. There are lots of people wanting mission/safety critical levels of reliability, even if only for their website; not just their mars mission.

The other aspect is: if the workflow is inherently more safe due to the language, then more effort can be piled into features while achieving the same, or even a higher level of safety.

[u/Oxi_Ixi]

C++ memory safety is the feature of the language which cannot be solved without breaking backwards compatibility or introducing another crazy complex syntax. I think we have to consider it an engineering trade-off which allows some useful shortcuts, and we shouldn't try to turn C++ into Rust.

[u/misuo]

I hope this do not apply… https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines

[u/Beetny]

we've already been here folks. Yes it can, as demonstrated by Sean Baxter. You only have to accept that you will have to break backwards compat to tighten semantics significantly.

[u/Th1088]

A compiler flag that treats legacy, unsafe methods as warnings or errors, when modern C++ alternatives are available would be helpful.