Interview: Bjarne Stroustrup on 21st century C++, AI risks, and why the language is hard to replace • DEVCLASS

C++ inventor Bjarne Stroustrup talked to DevClass on how to write modern C++, the problem with trying to replace the language, AI risks, and why having multiple compilers with slightly different implementations is actually a good thing.

At the Qt World Summit in Munich this week, we spoke to Stroustrup ahead of his presentation on “21^stcentury C++”.

Despite the name of his session, Stroustrup is not focused on upcoming features in C++ 26 (the next major version) such as reflection and contracts. “The language is not just the last features that were put into it,” he says. “To write contemporary C++ you have to use a combination of features from the earliest days to modern days … my main point is not that there are some neat new features that you should absolutely use. It’s that you should use the language as it is now. It’s a more coherent whole, it’s more efficient, it’s more expressive, it’s safer.”

What are the features of C++ that every programmer should use in order to be in that modern mode?

“A lot of it has to do with features working together,” says Stroustrup. “I work on trying to get things expressed more directly in the language. For instance, if you want to write a loop, you don’t have to have loop variables. 95 to 99 percent of your loops are, do everything over this container, so you can write ‘for x in y’ or whatever, and say directly what you want. It’s easier for the compiler to optimize, it’s harder for you to make mistakes, and it is shorter to write.

Stroustrup also refrences generic programming, saying that “the types are usually deduced so you always get the right type.” 

Another thing he says is critical is resource management. “If you use RTTI to guarantee that you get things deleted or closed or whatever, you have a scope where things are going in. So every resource should be owned by a handle, and the handle should be in the scope, then a lot of your leaks disappear.”

What are the things that modern C++ developers should never do?

“Never use a raw pointer as a resource handle, for instance. Then you violate everything I said. Never pass a set of elements by a single raw pointer like a pointer to an array. You don’t know how many elements there are. You can’t do a decent range check. If you pass a vector, it knows how many elements it’s got, it knows what types it’s got.

“I hardly ever use casts any more, by the way that’s the generic programming stuff. And if you don’t use casts, there’s a lot of type errors you can’t make. 

“Traditionally the way you get a lot of stuff out of a function is that you put something on the free store, the dynamic store, and then you pass a pointer out, and then you have to remember to delete it sooner or later. These days you can just move a vector out. That’s usually zero cost.”

In his presentation, Stroustrup also talked up modules, used with an import statement, rather than the older #include. Using #include is transitive (the order matters), causes repeated compilation, and can introduce subtle bugs. By contrast, import is not transitive, and much compilation can be done once only.

Other features he highlighted are templates and concepts (a required part of C++ since C++ 20). “Using concepts is easier than not using them,” said his slide on the subject. He also said that he does not make use of “anything more advanced than you see in this talk” in production code, and that he has not seen resource leaks after basic testing for years.

How can you enforce writing C++ in a modern style? This is a problem, Stroustrup tells us. “You can’t actually follow guidelines in large pieces of code. We need support for it. I’m working on guidelines enforced by something I’ve called profiles, which say, I want this set of guarantees and it will then be enforced.”

There is no future, he says, in trying to remove “dangerous, complicated things” from the language itself, even though “people have been asking for simpler versions of C++ forever.” The problem, he tells us, “is that the dangerous, complicated things like pointers and arrays and casts and such, are what we need to implement the good abstractions … what you can do is, you can remove them outside the implementation of the abstractions. For instance, operator new and operator delete shouldn’t be in application code.”

He is frustrated though that there is no support for profiles in the C++ specification, nor will there be soon. “The sad thing is, the standards committee got confused and did not guarantee that this would be in C++ 26,” he tells us.

In the meantime, developers can use things like Clang-Tidy. “It has part of the checking for what I call the C++ core guidelines, which is a joint project with Red Hat, Microsoft and others,” he says.

Is he concerned about the impact of AI on C++ coding? “Yes, I do have serious concerns. I’m not saying it won’t help, but it does have a tendency of guiding people towards things which everybody used to do. It’s not a good way forward. Furthermore, I fear that people lose the ability to detect problems because they are so used to having it done for them,” he said.

Another trend is the advent of new languages, some based on C++ such as Google’s Carbon project. Is there any future in these?

“It’s easy to design something that’s better than C++ for something you are focused on, if you have a small domain, but one of the C++ strengths is that it works in very diverse domains,” Stroustrup says. Another issue is that “if any of those languages succeeds, they must be able to interact with C++, Python etc. So if we don’t watch out, instead of getting one language that’s too big, like C++, we will get 10 languages that are all insufficient and each desperately trying to be able to interoperate with the others.”

Does C++ evolve too slowly?

“One of the ways of knowing you’re moving at the right speed is that half the people complain you’re too slow, and the other half that you’re too fast,” says Stroustrup. “And yes, I would like to move a bit faster than the Standards Committee. The Standards Committee is humungous and has people concerned with lots of things and that slows things down … but there’s probably more C++ developers that think it’s moving too fast,” he told us.

The various C++ compilers vary in what they actually implement from the official specification, is that friction for developers?

“Yes, but each of the major compilers, and each of the embedded compilers which aren’t considered major, probably have more users than most languages … the other thing is that I really don’t like monocultures. If you look at history, monocultures, it just takes on bug or one kind of poison and you’re dead.” 

The implementation in major C++ compilers is “not identical, but they’re pretty close, and they keep getting closer,” Stroustrup told us. “If you have a single implementation, you have some advantages, but you have a monoculture. The fact that there are several means you have some competition. It means you have some scope for innovation. And it also means that they are not absolutely identical … I believe it’s a fact there there is no fully compliant C compiler and there never has been.”