Bjarne Stroustrup on C++: Zero-Overhead Abstraction, Good Code and How the Language Evolves

High-Level Overview

Lex Fridman sits down with Bjarne Stroustrup, the creator of C++, for a technical but very approachable conversation about where the language came from, what it is for, and how it keeps changing after four decades. Stroustrup traces his path from Algol 60, assembler and microcode to Simula, the language that taught him he could build his own types, and then explains the ideas he carried into C++: efficiency and reliability together, abstraction that costs nothing, classes that behave like built-in types, templates, and the newer feature called concepts. Fridman, who says he has written several hundred thousand lines of C++ himself, asks as a fan and as a working programmer.

The tone is calm, precise and dryly funny. Stroustrup is modest about his own role, blunt about what he does not like (monocultures, too much dynamism, fuzziness in safety-critical systems) and generous to the people he learned from. The conversation flows from history, to the philosophy of good code, to the mechanics of specific language features, to the standards committee, and ends with machine learning and what he is proudest of.

The Discussion Explores:

• Stroustrup's first programs and the languages that shaped him, above all Simula
• A short history of programming languages, from Fortran to Algol to Simula, and why he is not a Lisp person
• Why a programmer should know several languages, and which kinds he would pick
• Efficiency and reliability as a pair, and why safety is a property of the whole system
• What good code looks like: simplification, the C++ Core Guidelines and static analysis
• The zero-overhead principle, and how classes, virtual functions and templates meet it
• Concepts, the decades-long effort to check what a template requires of its arguments
• How the ISO standards committee works, and why C++ moved to a three-year release cycle
• Constructors and destructors as the feature he finds most beautiful
• His wariness about machine learning in life-threatening settings, and his proudest achievement

Deep Dive into Main Ideas

From Algol 60 to Simula: building your own types

Stroustrup's first program came in his second year at university. Written in Algol 60, it calculated the shape of a superellipse and connected points on the perimeter to make star patterns printed on paper. He liked Algol, did not fall for Fortran or Pascal ("It all got in the way of me."), and then had fun with assembler and microcode, work that he says paid for his master's degree.

The turning point was Simula, an extension of Algol 60 built mainly for simulation. Its designers, Kristen Nygaard and Ole-Johan Dahl, invented object-oriented programming, inheritance and run-time polymorphism along the way. Stroustrup says every language that uses the word class for a type descends from Simula, directly or indirectly; the two were mathematicians who thought in sets and classes of elements. Simula taught him that a program's problems need not grow with the square of its size, because you can modularize, and that a stricter type system than Pascal's could actually help as long as it was extensible. Pascal, in his description, was the simplest language that served the needs of its designer and carried a moral tone; Simula let you build your own world.

For him the key idea was not class hierarchies but getting his own types, appropriate to his problem and its constraints. Inheritance mattered when types were related. His classic example is a city simulation with vehicles: instead of big case statements for how a bicycle, a car and a fire engine each turn, you tell the base class vehicle to turn left. He says this was a real project that simulated and optimized emergency services in Norway in the 1960s.

A brief history of languages, and why not Lisp

Asked for a history of programming languages, Stroustrup starts with the first Fortran, which he calls the most interesting and major improvement. Before it, all code was written for a specific machine in that machine's language. John Backus and his team at IBM let engineers and physicists write formulas in terms natural to them, and got portability as a side effect. The lesson he keeps: raise the language toward the human level without losing efficiency. Business people got Cobol; Algol brought precise notions of type and scope and was a technical breakthrough even though many considered it not flexible or efficient enough; Simula then made the idea more flexible.

When Fridman notes he skipped John McCarthy and Lisp, Stroustrup says Lisp is important and interesting but not one of his favorites. His world is constrained by performance, reliability, deployability and hardware cost, and he does not like things to be too dynamic. His illustration is a telephone switch in Bogota that hits an error late on a Sunday night: what is the chance a programmer is around to use the debugger? "The chance is zero." He guesses that maybe 70 or 80 percent of all code is not under the constraints he cares about, but somebody has to connect the high-level flexible languages to the hardware.

Know more than one language

Stroustrup once said a professional programmer should know at least five languages. He admits he picked five out of a hat; the real point is that the number is not one. Like someone who speaks only one natural language and assumes their culture is superior, a programmer with one language is limited, and it is the second language that matters most.

His categories: machine code or assembler, because understanding the machine matters (mess up the cache and you can be off by a large factor in performance); C++ for abstraction with performance; a functional language such as Haskell or ML for expressing mathematical notions clearly with a strict type system; and something for quickly churning things out, such as JavaScript, Python or Ruby. He adds that going low level is no longer what gives performance. "My favorite way of optimizing these days is to throw out the clever bits and see if it still runs fast." Sometimes it runs faster. He describes a conference keynote by Jason Turner, who wrote Pong for an old, very limited machine in modern C++ while the audience watched the generated assembler shrink as the abstraction level rose.

On JavaScript, he says a tool's designer has no control over how it is used. Running in the browser was an enabling thing, even if it is not the prettiest language. He is proud of much of what C++ is used for and wishes people would not use it for some things, naming Bitcoin mining and its energy use as his favorite example.

Efficiency, reliability and the whole system

Stroustrup insists that efficiency and reliability have to come together. He wants his phone calls to get through and his bank not to crash. Efficiency is not just speed; it is an enabler. If a system spends all its time interpreting a simple function call, there is no time left for proper signal processing, or you need ten times as many computers. He points out that the brake pedal of a modern car is connected to a computer, and that computer had better work.

When Fridman asks how to test software that could cause fatalities, such as driver assistance systems, Stroustrup answers that safety, like performance and security, is a systems property. People look at one part and declare it secure, but you have to look at the whole system. To those who say C++ is not type safe, he replies that he can break anything that runs on a computer, and would not necessarily go through the type system to do it.

What good code looks like

The practical route to fewer crashes, he says, is simplification: less code, and code that expresses ideas directly so that what you were thinking is visible in the code rather than left in your head. Directly expressed code is easier to maintain, test and modify, and it tends to run faster. He borrows the line attributed to Einstein: as simple as possible and no simpler.

He has tried to write down what good code looks like in the C++ Core Guidelines, which separate what you can do in a language from what you should do. Rules limit the damage and the possibility of mistakes, but they do not create masterpieces; he compares them to rules for chiseling marble, which do not make anyone Michelangelo. "It's easier to recognize ugly than to recognize beauty in code." Messes share features, so static and dynamic checkers can catch a lot of sloppiness mechanically. He is a great fan of static analysis, for example checking whether resources leak, and expects much more of it in the coming decade. He would much rather find errors before the code runs, because error handling code is among the hardest to write: you know something went wrong, but usually not exactly what.

The zero-overhead principle

Fridman calls C++ an object-oriented language, and Stroustrup corrects him: "I actually never said that." He said C++ supports object-oriented programming among other techniques, and the best solutions to complex problems mix several styles. Designing the language, he realized that adding features one by one would never give a coherent whole, so he wrote guiding rules, described in his book on the design and evolution of C++.

One rule is the zero-overhead principle: an abstraction should cost nothing compared with writing the equivalent code at a lower level. A matrix multiply should be written so that dropping to arrays and pointers could not make it faster. He says people have written such matrix code that outran Fortran, because the right abstraction lets the compiler eliminate temporaries and fuse loops. He even says that his main tool for performance is abstraction.

This takes programming techniques, language features and implementation techniques together. He credits Brian Kernighan with pointing out that the craftsmanship of his early compilers was one reason C++ succeeded. He never chose to have many compilers; that was simply how the world was, with many machines and, among his users, 25 different linkers. Today he counts at least four front ends and many back ends, and he is glad. Of monocultures he says, "They are dangerous." Whoever owns one can go stale, and he credits competition between Clang, GCC and Microsoft with improving all of them.

Classes, inheritance and templates

Stroustrup lays out the language in two parts. The machine-facing part looks much like C: loops, variables, pointers, direct memory access. He does not dislike C; he built on it, had lunch with Dennis Ritchie most days for 16 years, and says "these C versus C++ fights are for people who don't quite understand what's going on."

The other part is abstraction, and the key is the class: a user-defined type that should be usable just like a built-in type and run just as fast. A real example is a range-checked integer built for the fuel injection of marine diesel engines on the largest ships, which goes to error handling instead of overflowing. Related types are handled by inheritance. Types that are the same idea with different contents, such as a vector of doubles, integers or chess pieces, are handled by parameterization, which is generic programming with templates.

Both had to be efficient. For virtual functions, taken from Simula, he used the simplest implementation he knew, a jump table, with an overhead he puts at a small percentage over an ordinary call, and none if you do not ask for a virtual function. For templates, the compiler combines the template, its parameters and the context of use and generates code as if you had written that specific version by hand. The price is ugly generated code and debugging that he admits can be truly horrid; he does his first level of debugging with the optimizer off.

Concepts and the standards process

When he designed templates around 1987 he wanted three things: great flexibility, speed equal to hand-written code, and proper checking of what a template requires of its arguments. Nobody knew how to get all three, so he took the first two, and the third bothered him for a couple of decades. An attempt in the early 2000s aimed at what became C11 failed, in his view because the ideas were too conventional, did not fit C, did not compile fast enough and were too hard to use.

Concepts, designed with Gabriel Dos Reis and Andrew Sutton and part of C20, are compile-time predicates. A sort function can require something sortable: a sequence with a beginning and an end, random access, and elements that can be compared. He credits the word to Alex Stepanov, whom he calls the father of generic programming in the context of C.

Standardization began in 1989 when two people, one from IBM and one from HP, came to his office and told him their organizations could not depend on a language owned by another corporation. "So through a combination of arm twisting and flattery, it got started." The committee is open to anyone who pays a modest fee, meets three times a year for a week, votes one vote per organization, and works by consensus rather than narrow majorities. The first standard took eight years, finishing in 1998. The next took 13, a second-system effect. After C++11 the committee moved to a three-year cycle, and he says 14 and 17 shipped on time and 20 will too.

Constructors, destructors and shared principles

Asked for the most beautiful feature, Stroustrup has one clear answer: constructors and destructors. A constructor establishes the environment for an object and the destructor cleans up at the end. "That is the key to C++." It is why the language does not need garbage collection and can deliver predictable performance. The idea is known as resource acquisition is initialization, a name he laughs at: "It's also the best example of why I shouldn't be in advertising." It was there in about the second week of his work on the language. Control of copying and then move operations complete the set of key operations on a type.

He does not expect one unified language, but he thinks languages should be designed from principles rather than by bolting features together. He recalls sitting down with designers of Common Lisp and discovering that, despite very different constraints, they reasoned from similar principles. He sees some convergence already, with Rust adopting his resource idea and garbage-collected languages imitating construction and destruction. Computing, he reminds Fridman, is about 70 years old and very immature compared with physics, which has had centuries longer.

Machine learning, and what he is proudest of

Fridman describes machine learning as a fuzzy kind of programming. Stroustrup calls it a different world and says that in his domain he does not like fuzziness. He does not want everybody programming airplane or car controls, and he says C++ is a sharp tool for professionals. Accuracy rates he has seen, in the eighties or low nineties of percent, are fine for pre-screening before a human looks, but not for life-threatening situations. What scares him most is a system that hands a problem to a human who is reading or asleep and has seconds to respond. Fridman finds that human-machine problem appealing because it is unsolved; Stroustrup says he was only stating the problem. He adds one fact: "all of this AI stuff is on top of c++".

His proudest achievement is, obviously, C++, which he puts down to a few good ideas, a lot of hard work and a bit of luck. He has tried to get away from it and gets dragged back, because that is where his work has the most impact. What keeps him going is seeing what people build with it, from telescopes to car factories to the Mars rovers.

Conclusion

This episode is a clear tour of how one of the world's most widely used languages thinks. Stroustrup's argument is consistent throughout: build your own types, express ideas directly, find errors before the code runs, and never pay for an abstraction you could have written more cheaply by hand. He treats reliability as a property of whole systems, values competition between compilers, and defends the slow, consensus-driven standards process as the least bad option. He is skeptical of fuzziness where lives are at stake, though he notes that the AI field runs on his language. For programmers it is a rich look at the reasoning behind familiar features; for everyone else it is a thoughtful conversation about craftsmanship and why philosophy matters in engineering.

This is a summary of "Bjarne Stroustrup: C++" from Lex Fridman Podcast, giving you the GIST so you can decide if you want the REST. Listen to the full episode.