C++, like all things, has numerous problems. Pointing out how Rust addresses many of them is a major topic of my blog, but some of the problems are bigger than others. The biggest, most famous, loudest problem, the problem that got the federal government’s attention and resulted in a surreal flame war between Dr. Bjarne Stroustrup and the NSA (which I also commented on/contributed to), is C++’s lack of memory safety.

This is C++’s biggest problem, its memory safety problem. That’s the one everyone’s talking about. Can it be fixed?

First, a spoiler: In brazen contravention of Betteridge’s Law, I am going to answer “yes” to this question! But perhaps it’s a qualified enough “yes” to still fit the pattern – you be the judge!

Can we migrate C++ programmers to a safe programming language?#

C++’s lack of memory safety can, of course, be addressed by moving away from C++ proper. It can be fixed by creating a new language, inspired by C++, that has many of its properties, but memory-safe. The idea would be that C++ programmers interested in memory safety, hopefully most C++ programmers, would move to this new programming language. New projects that would have been begun in C++ in a previous era, are now run in this new programming language, which also offers more modern tooling to boot.

Can this be made to work? Can a majority of C++’s user base be replaced by a “novel” safe programming language? Can that new language be shiny enough to attract people, offering memory safety but also other ecosystem benefits to entice people away? Can that end C++’s hold on its part of the market for programming languages?

Yes. Yes, it can. It can because this entire thing has already happened.

You might think I’m insane – Rust hasn’t captured most C++ programmers – but when I say it’s already happened, I’m not talking about Rust. I’m talking about Java, back in 1995. Remember, C++ is now considered a systems language. It is niche. Before the Java era, C++ was used for application programming!

And then came Java. Since 1995, Java has successfully smashed C++’s previous programming language position. C++ is now only used for legacy applications, and/or applications where Java’s mechanism for memory safety (namely garbage collection and mandatory heap usage) isn’t performant enough. All the rest of C++’s much broader market has, since 1995, gradually moved to safe programming languages.

This is why Dr. Stroustrup’s response to the NSA was so upsetting, and part of why I felt compelled to write my rebuttal! Far from being “novel,” the safe programming languages that have most competed with, and most drawn most away from C++ have been Java, along with its Microsoft-branded twin, C#. Even games are written in C# now, not C++!

“Safe programming languages” aren’t remotely “novel.” They’ve been around for aeons. What Rust contributes is not memory safety, which is old hat (although there are some ways in which Rust is better at preventing programming mistakes than Java), but memory safety combined with a non-garbage collected, systems programming language level of control over memory usage.

C++ is hanging on by a hair because of this niche where garbage collection is unacceptable, where until Rust memory safety was thought infeasible. Now that Rust has demonstrated that you can have this cake and eat it too, you can have memory safety without garbage collection, it is only a matter of time before safe memory languages capture this small hold-out.

Most programmers aren’t systems programmers, and so most programmers use memory-safe programming languages, like Javascript or Python, or Java or C#. Only a small minority are still in a backwater of memory unsafety. Framing memory safety as a weird, unnecessary requirement, when seen from that perspective, is raw parochialism.

I made a throw-away comment in my Stroustrup response, that a majority of programmers would continue to use memory-safe programming languages. Somewhere, in an obscure discussion thread, one person (call him George) said this was clearly false, as many more people used C and C++ than Rust. Another (call him Frank) responded that most programmers use languages like Java or Javascript. George responded that they had assumed I couldn’t possibly have meant managed programming languages, but must have been speaking within a systems programming context.

But Frank was absolutely right about what I meant! The right perspective for understanding this process is programming as a whole. The only reason systems programming was special in not requiring memory safety before, was because it was believed memory safety required GC. Now that we know this is false, it’s not special anymore. Memory safety will rapidly become an expectation there as well.

And so, Rust will be able to do to the remnant of C++ what Java did 30 years ago: convert a majority of C++’s userbase to Rust and its friends. C++ has been becoming a legacy language for a long time, and this will make the process complete.

Can C++ itself be made suitably memory safe?#

That said, C++ will still be with us for quite some time! Even if it is just used for old projects, there are a lot of projects in C++, that won’t be rewritten in Rust or Java anytime soon. Is there a way to bring safety to them? Can C++ itself, in new versions, be made memory safe?

Yes, I think this is coming, eventually! Not soon enough – it’s long past its due – but it’s being worked on!

I don’t refer to the vaporware that is C++ safety profiles. I’m referring instead to a research project that tries to take the lessons and successes of memory safety in Rust, and apply them to C++, without changing anything else about the programming language.

That project is Circle C++ with memory safety, designed by Sean Baxter. It is a work in progress, but it is a proposal with many benefits over safety profiles. Importantly, it doesn’t shy away from changing the programming language itself where necessary.

The keyword safe has similar rules to noexcept. In safe code, pointers are disallowed in favor of safe borrows, borrow-checked by a system similar to Rust’s. All the ideas borrowed from Rust, however, are done with a C++ aesthetic. And the entire thing is opt-in, on a file by file basis – but once your file is opted in, safety is on by default. This actually strikes me as a reasonable compromise for C++!

Go read the website, Sean explains it better than I could.

Standard C++ could adopt this approach, and still be C++. Perhaps, if the right people hear about it, the C++ fans who think Rust is pointless might even be able to get on-board. Maybe.

So, will C++ become a memory-safe programming language? Maybe. Can it? This research has convinced me it is possible, without losing its C++-nature. We shall see if the stakeholders in the C++ community feel similarly.

Conclusion#

The memory-safety problem of C++ is, ultimately, a transient problem. Memory-safe languages will continue to eat away at C++ usage, just as they have for decades, any blips to the contrary notwithstanding. C++ will then continue to fade into the land of legacy – which, don’t underestimate the size of legacy code in this world – but ultimately, it won’t be used for new projects.

In the meantime, C++ has an opportunity to fix this problem with itself, although many others would remain. They have a duty to do so, and to take this issue seriously, as memory safety remains a serious problem for those large codebases that will remain for some time.