Bjarne Stroustrup’s Plan for Bringing Safety to C++
The 72-year-old creator of C++ gave a forward-looking keynote address last month as the programming language’s annual convention.
As the C++ community gathered for “CppCon” C++ conference in Aurora, Colorado, Bjarne Stroustrup promised his audience a talk that would first identify the specific kinds of safety measures needed in a programming language, and “Then I’m going to show you that we’ve been creeping up on that for a few decades.”
Stroustrup took some time to address critics who say the problem is C++ itself, and the solution is switching to another language. But he also went into more detail on a proposal that adds new safety tooling to address their specific criticisms — finally bringing a new solution to the world’s billions of lines of C++ code.
The Case Against Switching Languages
Early in the presentation, Stroustrup shared a slide titled “Safety is not just type safety,” highlighting everything from resource leaks and overflows to memory corruption and timing errors. There’s concurrency errors, termination errors — and of course, type errors. “Often the safety mentioned is just memory safety — that’s not enough… And the need to interoperate with other languages, including C++ and C, tend not to be mentioned. And the cost of conversion can be ferocious. That’s rarely mentioned…”
“And anyway — which other language? The way I have seen it argued, we are going to have C++ replaced by about seven different languages, as of suggestions of about now. By the time it happens — 40 years from now — we’ll probably have 20 different ones, and they have to interoperate. This is going to be difficult.”
Elsewhere in the talk Stroustrup also points out that “A lot of the so-called ‘safe’ languages outsource all the low-level stuff to C or C++,” temporarily escaping the original language to access hardware resources or even the operating system (which is often written in C) — or even “trusted code” which may actually be very old, tucked away in an external library… or written in an entirely different programming language.
Stroustrup calls our current situation “an argument for an incremental and evolutionary approach, as opposed to just going to something brand-new.” One slide even ends by quoting Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked.”
As Stroustrup sees it, “This idea of just building a new system over on the side, without any of the problems of the old one, is a fantasy. But it’s a very popular fantasy.”
‘Where Do We Go from Here?’
So about 54 minutes into the talk, Stroustrup told his audience, “Now I want to get to future stuff: where do we go from here…? ”
Stroustrup calls our current situation “an opportunity,” remembering how type and resource safety had always been a goal of C++ since its earliest days. “We couldn’t have complete safety with the hardware we had then, and we can’t now for all languages and for all uses.” But Stroustrup doesn’t want to see restrictions on what can be expressed in C++, and in fact envisions a solution that still adheres to the language’s ISO standard. “We need it to be C++. That is, there shouldn’t be restrictions on what we can do, even though there might be restrictions on how we do it.”
And Stroustrup also doesn’t want to see heavy additional run-time overhead. “There shouldn’t be any decline in performance… Actually, some of the techniques for writing safe code improve performance. I’m talking mostly about what can be done by a compiler and static checking because it is free, or actually gives improvements in performance.”
Stroustrup has arrived at his solution: profiles. (That is, a set of rules which, when followed, achieve specific safety guarantees.) They’d be defined by the ISO C++ standard, addressing common safety issues like pointers and array ranges. In response to a later question from the audience about the difficulty of adding new tooling, Stroustrup pointed out that the C++ compiler itself is now a pretty sophisticated static analyzer, and could also be tasked with meeting the profile’s requirements. So when it comes to adding safety-improving tooling, “I think profile annotations should help with that problem.”
Stroustrup lays out the general strategy: using static analysis to eliminate potential errors. But “Global static analysis is just unaffordable,” Stroustrup adds. “So basically we need rules to simplify what we are writing to something that can be analyzed efficiently and cheaply — local static analysis… And then provide libraries to make relying on these rules feasible.”
One slide also noted another advantage: that “Gradual conversion from older code to modern code offering guarantees is supported. The slide emphasized that there’ll be a standard “fundamental” set of guarantees, with a larger, open universe of available guarantees. Stroustrup says “I’m imagining type- and resource-safety, memory safety, range safety. Arithmetic safety, things like that, could be standardized.” And there will also be rules for applying different guarantees to different fragments of code.
Code could even gets explicit expressions of which guarantees were applied (thus reassuring future readers). Stroustrup again put up his slide listing the “many notions of safety” — a slide titled “Safety is not just type safety,” highlighting resource leaks, overflows, memory corruption, timing errors, concurrency errors, termination errors — and of course, type errors.
One slide succinctly makes the case: “Being careful” doesn’t scale. So while the core guidelines may suggest safe coding practices, “We need enforced rules.” As Stroustrup puts it, “We have to formulate the rules for safe use. We have to provide ways of verifying that people actually do what they’re trying to do.” Stroustrup points out that much of what he’s describing has already been tried, even at scale. “But nowhere has it all been integrated into a consistent, coherent whole. And that’s what I’m arguing we should do.”
One slide lays out the formula in six words: hygiene rules + static analysis + run-time checks. Stroustrup put up a slide saying C++ can eliminate many common errors — including uninitialized variables, range errors, null pointer dereferencing, resource leaks, and dangling references.
Toward the end of the talk, Stroustrup went into more detail. “I’m suggesting that you have module-based controls.” The slide shows how it would work in code.
|
1 2 3 |
export My_module[[provide(memory_safety)]]; import std [[enable(memory_safety)]]; import Mod [suppress(type_safety)]]; |
Also still under development are in-code controls, to be applied to fragments of code.
|
1 2 |
[[suppress(type_safety)]] X [[enforce(type_safety)]] X |
Stroustrup also has suggestions for what would initially be the standard profiles. (Type_safety, range, and arithmetic). Putting up a slide of just 11 new keywords, Stroustrup says, “Here’s a summary of what it would take to do this, in terms of syntax.”
“It’s a work in progress,” Stroustrup tells his audience. “There’s papers written about it, and you can go and look it up. There are also talks about it. And basically, no we’re not here yet.” But “We’ve come a long, long way from classic C. And from ‘C with classes’, and from C++ 11.”
One of the last slides said “How can you help,” with Stroustrup suggesting users could help refine profiles and formalize their specifications. (“I’m dreaming of something like Profiles Light, that provides most of the guarantee of a profile, but can’t do all the last things because, say, the static analyzer isn’t up to it yet.”)
He’s created a GitHub repository, “where people can put suggestions, and where I’m going to put my drafts and such, so that we can create a community working on getting this kind of stuff done in a reasonable time.”
The repository asks what’s needed to make profiles “an industry-wide tool for the variety of C++ safety needs,” calling the concept a framework. “Many parts have to be created and fitted in to enable widespread use. Much has been done, but relatively little is widely available. This is a wish list. Please help in whichever capacity you can.”
