Transcript for Bjarne Stroustrup: C++

It was my second year in university, first year of computer science, and it was an alcohol 60. I calculated the shape of superlips and then connected points on the perimeter creating star patterns. It was with a wedding on a paper printer and that was in college. I learned to program the second year in university.

I think I'll call it 60 and after that I remember I remember Snowboard I remember Fortran didn't fall in love with that. I remember Pascal didn't fall in love with that. It all got in the way of me. And then I just covered a simpler and that was much more fun. And from there, I went to my group, microcode.

I went through a lot of languages and then I spent a significant time in a simpler and microcode. That was sort of the first really profitable things and I paid for my master's actually. And then I discovered similar, which was absolutely great. similar. Simular was the extension of Albert 60, done primarily for simulation, but basically they invented octetorian to programming at inheritance and runtime polymorphism when they were while they were doing it. And that was the language that taught me that you could have the sort of the problems of a program grow with size of the program rather than with the square of the size of the program. That is, you can actually modularize very nicely. And that was a surprise to me. It was also a surprise to me that a stricter type system than Pascal's was helpful, whereas Pascal's type system got in my way all the time. So you need a strong type system to organize your code well, which has to be extensive or inflexible.

Basically Pascal was sort of the simplest language that Nicholas, we had could define that sort of the needs of Nicholas, we had at the time. And it has sort of a highly more tone to it that is if you can say it in Pascal, it's good and if you can't, it's not so good whereas Similar, a lot is basically to build your own type system. So, instead of trying to fit yourself into Nicklaus Wiesz's world, Christian Newgoer's language and all you have done is language allowed you to build your own. So, it's sort of close to the original idea of you build a domain-specific language. As a matter of fact, what you build is a set of types and relations among types that allow you to express something that's suitable for an application.

So they invented it. Every language that uses the word class for type is a descent in a similar. Directly, indirectly. Christian Newgo and all your hand dial were mathematicians and they didn't think in terms of types, but they understood sets and classes of elements and so they caught their types classes and basically in C++, as in similar classes, they used a defined type

I can try. The most sort of interesting and major improvement of programming languages was Fortran, the first Fortran. Because before that, all code was written for specific machine and each specific machine had a language, a simple language or a cross-emplore or some extension of that idea. But you're writing for specific machine in the language of that machine. Bakas and his team at IBM built a language that would allow you to write what you really wanted. That is, you could write it in a language that was natural for people. Now, these people happen to be engineers and physicists, so the language that came out was somewhat unusual for the rest of the world. But basically, they said formula translation because they wanted to have the mathematical formulas translated into the machine. And as a side effect, they got portability because now they are writing in the terms that the humans used and the way humans thought. And then they had a program that translated it into the machines' needs. And that was new, and that was great. And it's something to remember. We want to raise the language to the human level, but we don't want to lose the efficiency.

That was the first step. And of course, they were very particular kind of humans. Business people were different, so they got co-born instead, et cetera, et cetera. And similar came out, no, let's not go to similar yet. Let's go to alcohol. Fortran didn't have at the time the notions of Not a precise notion of type, not a precise notion of scope, not a set of translation phases that was what we have today, lexical syntax, cement, it was sort of a bit of a model in the early days, but hey, they're just on the big breakthrough in the history of programming, right? So it can't criticize them for not having gotten all the technical details, right? So we got alcohol. That was very pretty. And most people in commos and science considered it useless because it was not flexible enough and it wasn't efficient enough and et cetera, et cetera. But that was the breakthrough from the technical point of view. And then similar came along to make that idea more flexible and you could define your own types. And that's where I got very interested. Christian Newgo, who's a main idea man behind Simula. That was late 60s. This was late 60s. What's the visiting professor in Os? And so I learned objectoring and programming by sitting around and Well, in theory, discussing with, with, with, with, uh, Christ's Nugle, but Christ wants to get started and then full flow is very hard to get a word in each way. It's where you're just listening. So, um, it was great. I learned it from there.

It was not obvious and many people have tried to do something like that and most people didn't come up with something as wonderful as similar. Lots of people got their PhDs and made their careers out of forgetting about similar or never knowing it. For me, the key idea was basically I could get my own types. And that's the idea that goes further into C++, where I can get better types and more flexible types and more efficient types. But it's still the fundamental idea. When I was a writer program, I wanted to write it with my types. That is appropriate to my problem. And under the constraints that I'm under, with hardware software, environment, et cetera. And that's the key idea. People picked up on the class hierarchy, it's in the virtual functions and the inheritance. And that was only part of it. It was an interesting and major part and still a major part and a lot of graphic stuff. But it was not the most fundamental. It was when you wanted to relate one type to another. You don't want them to be independent. The classic example is that you don't actually want to write city simulation with vehicles, where you say, well, if it's a bicycle, write the code for turning a bicycle to the left, if it's a normal car, turn right a normal car wave, if it's a fire engine, turn right the fire, and then wait at out at out at about, you get these big case statements and bunches of if statements such. Instead, you tell the base class that's the vehicle I'm saying, turn left the way you want to. And this is actually a real example. They used it to simulate and optimize the emergency services for somewhere in Norway back in the 60s. So this was one of the early examples for why you needed inheritance and you needed runtime polymorphism because you wanted to handle this set of vehicles in a manageable way. You can't just rewrite your code each time and you kind of vehicle comes along.

If it were to tell the history in that way, obviously, I'm better telling the part of the history that the support I'm on as opposed to or the path.

But this is not one of my favorite languages. It's obviously important. It's obviously interesting. Lots of people write code in it. And then they rewrite it into CSC++ when they want to go to production. It's in the world I'm at, which constrained by performance, reliability, issues, deployability, cost of hardware. I don't like things to be too dynamic. It is really hard to write a piece of code that's perfectly flexible that you can also deploy on a small computer. And that you can also put in, say, a telephone switch in Bogota. What's the chance? If you get an error and you find yourself in the debugger that the telephone switch in Bogota on late Sunday night has a programmer around. Right. The chance is zero. And so a lot of things, I think, most about kind of thought that flexibility. I'm quite aware that maybe 70, 80% of all code are not under the kind of constraints I'm interested in. But somebody has to do the job I'm doing because you have to get from these high-level flexible languages to the hardware.

I understand why this is popular and I can see the beauty of the ideas and similarly with the small talk. It's just not as relative. Thank you. It's not as relevant in my world. And by the way, I distinguish between those and the functional languages where I go to things like ML and Haskell. Different kinds of languages, they have a different kind of huge in their very interesting. And I actually try to learn from all the languages I encounter to see what is there that would make working on the kind of problems I'm interested in with the kind of constraints that I'm interested in. What can actually be done better? Because we can surely do better than we do today.

This is a very hard question to answer. So, about languages, you should know languages. I recommend you about 25 or thereabouts when I did C++. It was easy on those days because the languages were smaller and you didn't have to learn a whole programming environment in search to do it. You could learn the language quite easily and it's good to learn so many languages.

So I picked five out of a hat. You know, five out of a hat. Obviously, the important thing that the number is not one. That's right. It's like, I don't like, I mean, if you're a monoglar, you are likely to think that your own culture is the only one's periods of everybody else's. A good learning of a foreign language and a foreign culture is important. It helps you think and be a better person. With programming languages, you become a better programmer, better designer with the second language. Now, once you've got two, the way to five is not that long. It's the second one that's most important. And then when I had to pick five, I sort of thinking what kinds of languages are there. Well, there's a really low level stuff. It's actually good to know machine code. Most of you still, sorry to you today, you didn't do that. The C++ optimizers write better machine code than I do. But I don't think I could appreciate them if I actually didn't understand machine code and machine architecture. At least in my position, I have to understand a bit of it because you mess up the cache and you're off in performance by a factor of 100. Right? It shouldn't be that if you are interested in either performance or the size of the computer you have to deploy. So I would go as a simpler. I used to mention C, but these days going low level is not actually what gives you the performance. It is to express your ideas so cleanly that you can think about it and the optimizer can understand what you're up to. My favorite way of optimizing these days is to throw it out the clever bits and see if it's still run fast. And sometimes it runs faster. So I need the abstraction mechanisms or something like C++ to great compact type performance code. There was a beautiful keynote by Jason Turner at the CPP kind of couple of years ago where he decided he was going to program Pong on a Motorola 60 800 I think it was and he says well this is relevant because it looks like a microcontroller It has specialized hardware, it has not met very much memory and it's relatively slow. And so he shows and real time how he writes punk, starting with fairly straightforward, low level stuff, improving his abstractions and what he's doing is writing C++ and it translates into into 86 assembler which you can do with playing and you can see it in real time it's the compile explorer which you can use on the web and then here a little program that translated 86 assembler into What a roller, as simple. And so he types and you can see this thing in real time. Well, you can see it in real time. And even if you can't read the assembly code, you can just see it his code gets better. The code, the assembly gets more roller. He increases the abstraction level, uses C++ 11 as a word better. This code gets cleaner, it gets easier maintained than the code shrinks. And he keeps shrinking. I could not in any reasonable amount of time, right? That is simpler as good as the compiler generated from really quite nice modern C++. And I'll go as far as to say that the thing that looked like C was significantly uglier and smaller when it became, and larger when it became machine code. So the abstraction that can be optimized, I'm important.

I can't show a large code base in a one hour talk and have it fit on the screen.

So at my two languages would be machine code and C plus plus. And then I think you can learn a lot from the functional languages. So pick, pick has GluyML. I don't care which I think actually you learn the same lessons of the expressing, especially a mathematical notion, really clearly, and having the type system that's really strict. And then you should probably have a language for sort of quickly turning out something. You could pick JavaScript, you could pick Python, you could pick Ruby, really make a JavaScript in general.

Let's say this way. When you build a tool, you do not know how it's going to be used. You try to improve the tool by looking at how it's being used and when people cut their fingers or from trying to stop that from happening. But really, you have no control over how something is used. So I'm very happy and proud of some of the things he plus plus being used at. And some of the things I wish people wouldn't do Bitcoin mining being my favorite example uses as much energy as Switzerland. and mostly serves criminals. But back to the languages, I actually think that having JavaScript run in the browser was an enabling thing for a lot of things. Yes, you could have done it better, but people were trying to do it better and they were using more principles, language designs, but they just couldn't do it right and the non-professional programmers are right or lots of that code just couldn't understand them. So it did an amazing job for what it was. It's not the prettiest language and I don't think it ever will be the prettiest language, but that's not the bigots here.

Efficiency and reliability.

I really want my telephone calls to get through and I want the quality of what I am talking coming out at the other end. The other end might be in London or wherever. So, and you don't want the system to be crashing. If you're doing a bank, you must crash, that might be your bank account, that isn't trouble. There's different constraints, like in games, it doesn't matter too much if there's a crash, nobody dies and nobody gets ruined. But I'm interested in the combination of performance. partly because of sort of speed of things being done, part of being able to do things that is necessary to have reliability of larger systems. If you spend all your time interpreting a simple function call, you are not going to have enough time to do proper signal processing to get the telephone calls to sound right. Either that or you have to have 10 times as many computers and you can't afford your phone anymore. It's a ridiculous idea in the modern world because we've solved all of those problems.

But you have to think about efficiency, not just speed, but as an enable of two important things. And one of the things that enables is reliability, is dependability. When I press the pedal, the brake pedal of the car, it does not actually connect it directly to anything but a computer. That computer better work.

First of all, safety, like performance and like security. This is systems property. People tend to look at one part of a system at a time and saying something like, this is secure. That's all right. I don't need to do that. Yeah, that piece of code is secure. I'll buy your operator. If you want to have reliability, if you want to have performance, if you want to have security, you have to look at the whole system.

I'm dealing with one part of the system and I want my part to be really good, but I know it's not the whole system. Furthermore, if making an individual part perfect, may actually not be the best way of getting the highest degree of reliability and performance in search. There's people who say, C++ type say, not type say, if you can break it. Sure, I can break anything that runs on a computer. I may not go through your type system. If I wanted to break into your computer, I'll probably try a secure injection.

Well, let's get back to something we can talk about and actually make some progress on. We can talk at C++ programs and we can try and make sure they crash this often. The way you do that is largely by simplification. The first step is to simplify the code, have less code, have code that are less likely to go wrong. It's not by runtime testing everything. It is not by big test frameworks that you are using. Yes, we do that also. But the first step is actually to make sure that when you want to express something, you can express it directly in code rather than going through endless loops and convolutions in your head before it gets down on the code. That if the way you are thinking about a problem is not in the code. There is a missing piece that's just in your head. And the code you can see what it does, but it cannot see what you thought about it, unless you have expressed things directly. When you express things directly, you can maintain it. It's easier to find errors, it's easier to make modifications, it's actually easier to test it, and learn beholder runs faster. and therefore you can use a smaller number of computers, which means there's less hardware that can possibly break. So I think the key here is simplification, but it has to be to use the Einstein quote as simple as possible and no simpler. That's a blur. There are other areas with underconstrained, where you can be simpler than you can be in C++, but in the domain I'm dealing with That's the simplification I'm off.

An experienced developer can do it code and see if it smells. I am mixed metaphors deliberately. The point is that It is hard to generate something that is really obviously clean and can be appreciated. But you can usually recognize when you haven't reached that point. And so if I have never looked at the 150 code, so I wouldn't know. But I know what I ought to be looking for. There I'll be looking for some tricks that correlate with bugs and elsewhere. I have tried to formulate rules for what good code looks like and the current version of that is called the C++ Core Guidelines. One thing people should remember is there's what you can do in a language and what you should do. In a language you have lots of things that is necessary in some context, but not in others, things that exist just because there's 30-year-old code out there and you can't get rid of it. But you can't have rules, it says, when you create it, try and follow these rules. This does not create good programs by themselves, but it limits the damage of mistakes, it limits the possibilities of mistakes, and basically we are trying to say what is it that a good programmer does? At the fairly simple level of where you use the language and how you use it. I can put all the rules for chistening and marble. It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo. That is, there's something else to write a good program. Just that is something else to create an important work of art. That is, there's some kind of inspiration on the standing gift. But we can approach the sort of technical, the craftsmanship level of it. The famous painters, the famous cultures, was among other things, superb craftsmanship. They could express their ideas using their tools very well. And so these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well. for a really good piece of code, you need a spark of inspiration. And you can't, I think, regulate that. You cannot say that I'll take a picture only, I'll buy your picture only if you're at least then go. There are other things you can regulate, but not the inspiration.

Yes, it's easier to recognize ugly than to recognize beauty in code. And for the reason is that sometimes beauty comes from something that's innovative and unusual and you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common. And you can have static checkers and dynamic checkers that find. at large number of the most common mistakes. You can catch a lot of sloppiness mechanically. I'm a great fan of static analysis in particular because you can check for not just the language rules but for the usage of language rules. And I think we will see much more static analysis in the coming decade. Can you describe what static analysis is? You represent a piece of code so that you can write a program that goes over that representation and look for things that are right and not right. So for instance, you can analyze a program to see if resources are leaked. That's one of my favorite problems. It's not actually all that hard in modern C++, but you can do it. If you're writing in the C level, you have to have a malloc and a free. And they have to match. If you have them in a single function, You can usually do it very easily, if there's a mallet here, there should be a free there. On the other hand, in-between can be true and complete code and then it becomes impossible. If you pass that pointer to the memory out of a function and then want to make sure that the free is done somewhere else. Now it gets really difficult. And so for static analysis, you can run through a program and you can try and figure out if there's any leaks. And what you will properly find is that you will find some leaks and you'll find quite a few places where your analysis can't be complete. It might depend on runtime, it might depend on the cleverness of your analyzer. And it might take a long time, some of these programs run for a long time. But if you combine such analysis, with a set of rules such as how people could use it. You can actually see why the rules are violated. And that stops you from getting into the impossible complexities. You don't want to solve the whole thing problem.

Yes, so basically you need a set of rules for how you use the language, then you need a static analysis that catches your mistakes when you violate the rules or when your code ends up doing things that is shouldn't, despite the rules because there's the language rules, you can go further. And again, it's back to my idea that I'd much rather find errors before I start running the code. If nothing else, once the code runs, if it catches an error at run times, I have to have an error handler. And one of the hardest things to write in code is the error handling code, because you know something went wrong. Do you know really exactly what went wrong? usually not. How can you recover when you don't know what the problem was? You can't be 100% sure what the problem was in many, many cases. And this is part of it. So yes, we need good languages, good type systems. We need rules for how to use them. We need static analysis. And the ultimate for static analysis is course program proof, but that still doesn't scale into the kind of systems we deploy. then we start needing testing and the rest of the stuff.

That's a good question. I could probably have a year's course just trying to answer it. Yes, there's a tension between efficiency and abstraction, but You also get the interesting situation that you get the best efficiency out of the best abstraction. And my main tool for efficiency for performance actually is abstraction. So let's go back to how C++ got there. You said it was optiatory in the programming language. I actually never said that. It's always quoted, but I never did. I said C++ supports object-oriented programming, but it's nine other techniques. And that's important because I think that the best solution to most complex interesting problems require ideas and techniques from things that has been called object oriented, data abstraction, function, or traditional C-style code, all of the above. And so when else, the signing C++, I soon realized I couldn't just add features. If you just add what looks pretty or what people ask for or what you think is good, one by one you're not going to get a coherent whole. What you need is a set of guidelines that that the guy's your decisions should this feature be in or should this feature be out? How should a feature be modified before it can go in and search? And there's in the book I wrote about that that sign evolution of C++ is a whole bunch of rules like that. Most of them are not language technical. They're things like, don't violate static type system, because I like static type system. For the obvious reason that I like things to be reliable on reasonable amounts of hardware. But one of these rules is a serial or a principal. They will kind of put a serial or a principal. It basically says that if you have an abstraction, it should not cost anything compared to write the equivalent code at a lower level. So if I have a matrix multiply, It should be written in such a way that you could not drop to the sea level of extraction and use arrays and pointers and search and run faster. and so people have written such matrix multiplications and they've actually gotten code that ran faster and foretran because once you had the right abstraction you can eliminate you can eliminate temperatures and you can do a loop fusion and other good stuff like that that's quite hard to buy hand in a lower level language and there's some really nice examples of that And the key here is that that matrix multiplication, the matrix abstraction, allows you to write code that's simple and easy. You can do that in any language. But with C++, it has the features, so that you can also have this thing run faster than if you hand code it. Now, people have given that lecture many times, I and others, and a very common question after the talk where you have demonstrated that you're going to perform portrait and for dense matrix multiplication, people come up and says, yeah, but they'll see plus plus. If I rewrote your code and see how much faster would run, the answer is much slower. This happened the first time actually back in the ages with a friend of mine called dogmakaroi who demonstrated exactly this effect. And so the principal is you should give programmers the tools so that the abstractions can follow the zero-wide principle. Furthermore, when you put in a language feature and C++ or a standard library feature, you try to meet this. It doesn't mean it's absolutely optimal, but it means if you hand code it with the usual facilities in the language in C++ in C, you should not be able to better it. Usually you can do better if you use embedded as simpler for machine code, for some of the details to utilize part of a computer that the compiler doesn't know about. But you should get to that point before you beat to the abstraction.

And not all. You go for programming technique, program language features, and implementation techniques.

It takes some experience, it takes some practice and sometimes you get it wrong, but after a while you sort of get it right. I don't write compilers anymore, but Brian Kerney and pointed out that one of the reasons C++ succeeded was some of the craftsmanship I put into the early compilers. And of course I did the languages sign, of course I wrote a fair amount of code using this kind of stuff. And I think most of the successes involves progress and all three areas together. A small group of people can do that. Two, three people can work together to do something like that. It's ideal if it's one person that has all the skills necessary. But nobody has all the skills necessary in all the fields where C++ is used. So if you want to approach my ideal in a concurrent programming, You need to know about algorithms or current programming. You need to know the trigger of lock free programming. You need to know something about the compiler techniques. And then you have to know some of the program here. Sorry, the application areas where this is. Like some forms of graphics or some forms of what we call a web server and kind of stuff. And that's very hard to get into a single hit, but small groups can do it too.

When I designed C++, most languages have multiple implementations. Because if you want an IPM, if you run on a son, if you want a Motorola, there's just many, many companies in each have their own compilation structure, their old compilers. It was just fairly common to those many of them. And I wrote C front assuming that other people were right, compilers were C++, if I was successful. And furthermore, I wanted to utilize all the backend infrastructures that were available. I soon realized that my users were using 25 different linkers. I couldn't write my own linker. Yes, I could, but I couldn't write 25 linkers and also get any work done on the language. And so it came from a world where there was many linkers, many optimizers, many compiler frontends, Not to start, but operate many operating systems. So whole world was not an 86 and Linux box or something. Whatever is the standard today in the old days they said a set of X. So basically, I assume there would be lots of compilers. It was not a decision that there should be many compilers. It was just a fact. That's the way the world is. And yes, many compilers emerged. And today there's at least four front ends, Clang, GCC, Microsoft and EDG, it is the same group. They supply a lot of the independence organizations and the embedded systems industry. And there's lots and lots of backgrounds. We have to think about how many dozen backgrounds there are. Because different machines have different things. Especially in the embedded world, the machines are very different. The architectures are very different. And so having a single implementation was never an option. Now, I also happen to dislike monarch cultures. Monocultures. They are dangerous. Because whoever owns the monoculture can go stale and there's no competition and there's no incentive to innovate. There's a lot of incentive to put barriers in the way of change. Because, hey, we own the world and it's a very comfortable world for us and who are you to mess with that. So I really am very happy that there's four front ends for C++. Clank's great, but GCC was great, but then it got somewhat stale. Clank came along, and GCC is much better now. Competition might go soft as much better now. So at least a low number of front ends puts a lot of pressure on standards compliance and also on performance and error messages and compile time speed or this good stuff that we want.

Well, playing and the LLVM is more or less written from scratch.

There has been attempts to write new C++ compilers and some of them has been used and some of them has been absorbed into others and such. Yeah, it'll happen.

It's first get a principle on aim in place. C++ is for people who want to use hardware really well. and then manage the complexity of doing that through abstraction. And so the first facility you have is a way of manipulating the machines at a fairly low level. That looks very much like C. It has loops, it has variables, it has pointers, like machine addresses, it can access memory directly, it can allocate stuff in the absolute minimum of space needed on the machine. There's a machine facing part of C++, which is roughly equivalent to C. I said C++ could beat C and it can, doesn't mean I dislike C. If I dislike C, I wouldn't have built on it. Furthermore, after Denis Ritchie, I'm probably the major contributors to modern sea. And well, I had lunch with Dennis most days for 16 years and we never had a harsh word between us. So these sea versus sea plus plus fights are for people who don't quite understand what's going on. Then the other part is the abstraction. And the key is the class, which is a user-defined type. And my idea for the class is that you should be able to build a type that's just like the built-in types. In the way you use them, in the way you declare them, in the way you get the memory, and you can do just as well. So, in C++ is an int, as in C. You should be able to build an abstraction a class. which we can call capital int that you can use exactly like an integer and run just as fast as an integer. They are the idea right there and of course you probably don't want to use the int itself but it has happened. People have wanted integers that were ranged checks so you couldn't overflow on such. Especially for very safety critical applications like the fuel injection for a marine diesel engine for the largest ships. This is a real example, by the way. This has been done. They built themselves an integer that was just like integer, except that could not overflow. If there was an overflow, you went into the air handling. And then you built more interesting types. You can build a matrix, which you need to do graphics, or you could build a gnome for a video game.

So what people found was that you don't actually know how do I see this. A lot of types are related. That is, the vehicles, all vehicles are related. Bicycles, cars, fire engines, tanks. They have some things in common and some things are differ. And you would like to have the common things common and having the differences specific. And when you didn't want to know about the differences, like just turned left. You don't have to worry about it. That's how you get the traditional object oriented programming coming out of similar adopted by small talk and C++ and all the other languages. The other kind of obvious similarity between types comes when you have something like a vector. Fortune gave us a vector called a ray of doubles. But the minute you have a vector of doubles, you want a vector of double precision doubles and for short doubles, for graphics and why should you have not have a vector of integers while you are at it or a vector of vectors and a vector of vectors of chess pieces, now we have a board, right? This is, you express the commonality as the idea of a vector and the variations come through parameterization. And so here we get the two fundamental ways of abstracting of having similarities of types in C++. There's the inheritance and there's a parameterization. There's the object oriented programming and there's a generic programming.

You can do meta programming also. I didn't go there and then that explanation. We'll try to be very basic, but go back on to the implementation. If you couldn't implement this efficiently If you couldn't use it so that it became efficient, it has no place since he plus plus because it will violate the zero or head principle. So when I had to get up to you during programming inheritance. I took the idea of virtual functions from similar, virtual functions, this is similar term, classes are similar term. If you ever use those words, say thanks to a question you go and all you handle. And I did the simplest implementation I knew of. which was basically a jump table. So if you get the virtual function table, the function goes in, it does an interaction through a table and get the right function. That's how you pick the right thing there. And I thought that was trivial. It's close to up to more. It's end-use obvious. It turned out the simulator had a more complicated way of doing it, and therefore slower. And it turns out that most languages have something that's a little bit more complicated. Sometimes, more flexible, but you pay for it. And one of the strengths of C++ was that you could actually do this object or any other stuff. And your overhead compared to ordinary functions there's no interactions. It's not within 5, 10, 25%. Just the core. It's down there. It's not true. And that means you can afford to use it. Furthermore, in C++ you have the distinction between a virtual function and an unvirtual function. If you don't want any overhead, if you don't need the interaction that gives you the flexibility and object during the programming, just don't ask for it. So the idea is that you only use virtual functions if you actually need the flexibility. So it's not zero or head, but it's zero or head compared to any other way of achieving the flexibility. Now, also parameterization. Basically, the compiler looks at at the template, say the vector, and it looks at the parameter, and then combines the two and generates a piece of code that is exactly as if you were written a vector of that specific type. So that's the minimal overhead. If you have many template parameters, you can actually combine code that the compiler couldn't usually see at the same time. And therefore, get code that is faster than if you had handwritten the stuff. On the issue of very, very clever.

That's right. And so in furthermore, it gives all the information it's gotten, which is the template, the parameter, and the context of use, It combines the three and generates good code.

Yes, debugging can be truly horrid. Come back to this because I have a solution. Anyway, debugging was ugly. The code generated by C++ has always been ugly because there's these inherent optimizations. A modern C++ compiler has front end middle end and back end optimizations. Even C front back in 83 had front end and back end optimizations. I actually took the code generated an internal representation, managed that representation to generate good code. So people says, it's not a compiler, it generates C. The reason it generated C was I wanted to use C's code generators that was really good at back end optimizations. But I needed a front end optimizations, and therefore the C I generated was optimized C. The way a really good up hand crafted optimizer human could generate it, and it was not meant for humans. It was the output of a program, and it's much worse today. And with templates, it gets much worse still. So it's hard to combine simple debugging with symbol with the optimal code because the idea is to drag in information from different parts of the code to generate good code machine code. And that's not readable. So what people often do for debugging is they turn the optimizer off. And so you get code that when something in your source code looks like a function core, it is a function core. When the optimizer is turned on, it may disappear. The function core, it may inline. And so one of the things you can do is you can actually get code that is smaller than the function called because you eliminate the function preamble and return and there's just the operation there. One of the key things when I did templates was I wanted to make sure that if you have a say a sort algorithm and you give it a sorting criteria. If that sorting criteria is simply comparing things with less than, the code generated should be the less than. Not a indirect function call to a comparison object, which is what it is in the source code. But we really want down to the single instruction. But anyway, turn off the optimizer and you can debug the first level of debugging can be done and I always do without the optimisation on. Because then I can see what's going on.

Let me try and explain. Yes. So yes, it wasn't there ten years ago. We have had versions of it that actually work. for the last four or five years. It was designed by Gaby does raise true sarten and me. We were professors and postdocs and Texas at the time. the implementation by InterSodden has been available for that time and it is part of C++20 and the standard library that uses it. So this is becoming really very real. It's available in Clang and GCC for a couple of years, and I believe Microsoft is soon going to do it. Expect all of C++ 20 to be available, so in all the major compilers in 20. But this kind of stuff is available now. I'm just saying that because otherwise people might think I was talking about science fiction. And so what I'm going to say is really concrete, you can write it today. And there's production uses of it. So the basic idea is that when you have a generic component like a sort function, the sort function will require at least two parameters. One, a data structure with a given type and a comparison criteria. And these things are related, but obviously you can't compare things if you don't know what the type of things you compare. And so you want to be able to say, I'm going to sort something and it is to be sortable. What does it mean to be sortable? You look it up in the standard. It has to have, it has to be a sequence where the beginner and end. There has to be random access to that sequence, and there has to be the element types, has to be comparable. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. By the operator. Yes, I have begin an end. Are you a random exit sequence? Yes, I have a subscripting and plus Is your element type something that has a less than? Yes, I have a less than it's and so basically that's the system and so instead of saying I will take a parameter of any type it'll say I'll take something that's horrible And it's well defined. And so you say, OK, you can sort to less than, I don't want less than. I want greater than or something I invent. So you have two parameters, the sortable thing and the compassion criteria. And the compassion criteria will say, well, you can write and say, it should operate on the element type and it has the compassion operations. So that's simply the fundamental thing. It's compile time predicates. Do you have the properties I need? So it specifies the requirements of the code on the parameters that it gets. It's very similar to types actually.

The word concept was used by Alex Stefanoff who is sort of the father of generic programming in the context of C++. There's other places that use that word, but the way we call generic programming is Alex's. And he called them concepts because he said they are the sort of the fundamental concepts of an area. So they should be called concepts. And we've had concepts all in the time. If you look at the K&R book, I'll see, C has arithmetic types, and it has integral types. It says so in the book. And then it lists what they are and they have certain properties. The difference to me is that we can actually write a concept that will ask a type. Are you an integral type? Do you have the properties necessary to be an integral type? Do you have plus minus, divide and such?

Back in 87 are thereabouts. 97. Well, 1987 are thereabouts. When I was designing templates, obviously I wanted to express the notion of what is required by a template of its arguments. And so I looked at this. And basically for templates, I wanted three properties. I wanted to be very flexible. It had to be able to express things I couldn't imagine because I know I can't imagine everything and I've been suffering from languages attached to constrain you to only do what your the designer thought good didn't want to do that. Secondly, it had to run faster as fast or faster than hand-written code. So basically, if I have a vector of t and I take a vector of char, it should run as fast as you build a vector of char yourself without improvisation. Secondly, I wanted to be able to express the constraints of Of the arguments, I have proper type checking of the interfaces. And neither I know anybody else at the time knew how to get all three. And I thought, for C++, I must have the two first. Otherwise, it's not C++. And it bothered me for a couple of decades that I couldn't solve the third one. I mean, I was the one that put function argument type checking into C. I know the value of good interfaces. I didn't invent that idea. It's very common. But I did it. And I wanted to do the same for templates, of course, and I could. So it bothered me. Then we tried again 2000 of 2000 and 3. I started analyzing the problem, explained, possible solutions. There was not a complete design. A group in University of Indiana, an old friend of mine. They started a project at Indiana. we thought we could get a good system of concepts in another two or three years. that would have made C++ 11 to C++ 06 or 07. Well, it turns out that I think we got a lot of the fundamental ideas wrong. They were too conventional. They didn't quite fit C++ in my opinion. didn't serve implicit conversions very well. It didn't serve mixed type arithmetic, mixed type computation computations very well. A lot of stuff came out of the functional community and it that community didn't deal with multiple types in the same way as the plus plus does had more constraints on what you could express and didn't have the draconian performance requirements and basically we tried, we tried very hard, we had some successes but it just in the end wasn't didn't compile fast enough was too hard to use and didn't run fast enough unless you had optimizers that was beyond the state of the art. They still are. So we had to do something else. Basically it was the idea that A set of parameters has defined the set of operations and you go through an interaction table just like for virtual functions. Then you try to optimize the interaction away to get performance. And we just couldn't do all of that. But get back to the standardization. We are standardizing C++ under ISO rules, which are very open process. People come in, there's no requirements for education or experience.

What's the discussion? I'll try and explain that. So sometime in early 1989, Two people, one from IBM, one from HP to end of my office, and told me I would like to standardize C++. This was a new idea to me, and I pointed out that it wasn't finished yet, and it wasn't ready for formal standardization and such, and they say, no, be honest, you haven't gotten it. You really want to do this. Our organizations depend on C++. We cannot depend on something that's owned by another corporation that might be a competitor. Of course, we could rely on you. But you might get run over by a boss. We really need to get this out new. It has to be standardized under former rules. And we are going to standardize it under ISO rules. And you really want to be part of it because basically otherwise we'll do it ourselves. And we know you can do it better. So through a combination of arm twisting and flattery, it got started. So in late, in late 1809, there was a meeting in DC at the, actually, no, it was not ISO, then it was NC, the American National Standard doing We met there, we were lectured on the rules of how to do an NC standard. There was about 25 of us there, which apparently was a new record for that kind of meeting. And some of the old C guys that have been standard IDC was there, so we got some expertise in. So the way this works is that it's an open process. Anybody can sign up if they pay the minimal fee, which is about $1,000, there's less than a little bit more now. And I think it's $128,000. It's not going to kill you. And we have three meetings a year. This is fairly standard. We tried two meetings a year for a couple of years that didn't work too well. So three meetings, three, one week meetings a year. And you meet and you have technical discussions and then you bring proposals forward for votes. The votes are done one person per one vote per organization. So you can't have say IBM come in with 10 people and dominate things that's not allowed.

Right. Well, I think most people would agree it's better than if I decided it or it better than if a single organization like H&T decides.

Yes, they, they're the standardization is not pleasant. It's, it's, it's, it's horrifying. It's like the democracy. But we, exactly, as Churchill says, democracy is the worst way except for or the others, right? And it's, I would say, the same performance standardization. But anyway, so we meet and we, we have these votes. and that the sermons, what the standard is. A couple of years later we extended this so it became worldwide. We have standard organizations that are active in currently 15 to 20 countries and another 15 to 20 are sort of looking and voting based on the rest of the work on it. And we meet three times a year. Next week, I'll be in Cologne, Germany, spending a week doing standardization. And we will vote out the committee draft, or C++20, which goes to the national standards committees for comments. and requests for changes and improvements, then we do that in the second set of votes where hopefully everybody votes in favor. This has happened several times. First time we finished, we started in the first technical meeting was in 1990. The last was in 1998. We voted it out. That was the standard that people used until 11, or it would pass 11. And it was an international standard. All the countries voted in favour. It took longer with 11. mentioned why but all the nations voted in favour and we work on the basis of consensus that is we do not want something that passes 6040 because then we're good in getting a dialects and opponents and people are playing too much. They won't complain too much, but basically it has no real effect. The standards has been obeyed. They have been working to make it easier to use many compilers, many computers, and all of that kind of stuff. And so the first, the traditional with ISO standards to take 10 years, we did the first 108 brilliant. And we thought we were going to do the next one and six because now we're good at it. Right. It took 13.

I thought we would get, I thought it would get six seven or eight. The confidence of youth. Yeah, it's right. Well, the point is that this was sort of like a second system effect. That is, we now knew how to do it. And so we're going to do it much better. And we've got more ambitious ambitious. And it took longer. Furthermore, there is this tendency because it's a 10 year cycle. Oh, each doesn't matter. Just before you're about to ship somebody has a bright idea. And so we really, really must get that in. We did that successfully with the STL. We got the standard library that gives us all the STL stuff. That basically I think it saved C++. It was beautiful. And then people tried it with other things and it didn't work so well. They got things in but it wasn't as dramatic and it took longer and longer and longer. So after C++11 which was a huge improvement and what basically what most people are using today we decided ever again. And so how do you avoid those slips? And the answer is that you ship more often so that if you if you if you have a slip on a 10 year cycle By the time you know it's a slip, there's 11 years to get it. Now with a three year cycle, there is about three, four years till you get it. The delay between feature freees and shipping. So you always get one or two years more. And so we shipped 14 on time. We shipped 17 on time. And we shipped, we will ship 20 on time. It'll have, and furthermore, this gives a predictability that allows the implements, the compiler implements, the library implements, so they have a target and they deliver on it. 11 took two years for most compilers who were good enough. 14, most compilers were actually getting pretty good in 14. 17, everybody shipped in 17. We are going to have at least almost everybody shipped almost everything in 20. And I know this because they're shipping in 19, predictably this is good delivery on time is good. And so yeah, that's great.

I have written two papers for the History of Programming Languages Conference, which basically asked me so to questions. And I'm writing a third one which I will deliver at the History of Programming Languages Conference in London next year. So I've been thinking about that, and there is one clear answer. Constructors and destructors. The way a constructor can establish the environment for the use of the type for an object. And the constructor that cleans up any messes at the end of it. That is the key to C++. That's why we don't have to use garbage connection. That's how we can get predictable performance. That's how you can get the minimal overhead in many, many cases and have really clean types. It's the idea of construct the destructor pairs. Sometimes it comes out under the name R-A-I-I resource acquisition is initialization, which is the idea that you grab resources and the constructor and release them in destructor. It's also the best example of why I shouldn't be in advertising. I get the best idea and I call it resource acquisition is initialization. Not the greatest naming I've ever heard.

That's right. By the way, philosophy is important. You can't do good languages sign without philosophy because what you are determining is what people can express and how. This is very important. By the way, constructors, destructors came into C++ in 1709. In about the second week of my work with what was then called C++, it is a fundamental idea. Next comes the fact that you need to control copying, because once you control, as you said, birth and death, you have to control taking copies, which is another way of creating an object. And finally, you have to be able to move things around. So you get to move operations. And that's the set of key operations you can define on a C++ type.

Yes.

If you remember the statements, I have some trouble remembering it, but I know the origin of that idea.

Well, I think that languages should be designed not by clobbering language features together. doing slightly different versions of somebody else's ideas, but through the creation of a set of principles, rules, of thumbs, whatever you call them. I made them for C++, and we're trying to cheat people in the standards committee about these rules, because a lot of people come in and says, I've got a great idea. Let's put it in the language. And then you have to ask, why does it fit in the language? Why does it fit in this language? It may fit in in all language, and not here, or it may fit here, and not in the other language. So you have to work from a set of principles, and you have to develop that set of principles. And one example that I sometimes remember is I was sitting down with some of the designers of common lists. And we are talking about languages and language features and, obviously, we didn't agree about anything. Because, well, this is not C++, and I servers too many parentheses. But, suddenly we started making progress. I said, I had this problem, and I developed it according to these ideas and this is what why we had that problem different problem and we developed it the same kind of principles and so we worked through large chunks of C++ and large chunks of common list and figure out we actually had similar sets of principles of how to do it but the constraints on our designs were very different and the aims for the usage was very different. But there was commonality in the way you reason about language features and the fundamental principles you were trying to do.

Let's remember sort of modern physics. I think started with Galileo in the 1300s, so they've had 700 years to get going. Modern computing started in about 49. We've got 70 years. They have 10 times. And furthermore, they are not as bothered with people using physics the way we are worried about programming is done by humans. So each have problems and constraints the others have but we are very immature compared to physics. So I would look at sort of the philosophical level and look for fundamental principles like You don't leak resources, you shouldn't. You don't take errors at a runtime that you don't need to. don't violate some kind of type system. There's many kinds of type systems, but when you have one, you don't break it, et cetera, et cetera. There will be quite a few, and it will not be the same for all languages. But I think if we step back at some kind of philosophical level, we would be able to agree on sets of principles that applied to sets of problem areas. And within an area of use, by a C++ case, what used to be called systems programming, the area between the hardware and the the the the fluffy parts of the system. You might very well see your conversions. So these days you see rust having adopted RAI and some time accuses me for having borrowed it 20 years before they discovered it. But we're seeing some kind of conversion convergence here instead of relying on Garb's collection all the time. The Garb's collection languages are doing things like the Dispose patterns and such that imitates some of the construction destruction stuff and they're trying not to use the garbage collection all the time and things like that so there's that there that's a conversion But I think we have to step back to the philosophical level agree on principles and then we'll see some conversions Convergences and it will be application domain specific

I think it's a different kind of world and it is forci and in my domain I don't like forcianess. That is people say things like they want everybody to be able to program. But I don't want everybody to program my aeroplane controls or the car controls. I want that to be done by engineers. I want that to be done with people that are specifically educated and trained for building things and it is not for everybody. Similarly, a language like C++ is not for everybody. It is generated to be a sharp and effective tool for professionals, basically, and definitely for people who aim at some kind of precision. You don't have people doing calculations without understanding math. right counting on your fingers not going to cut it if you want to fly to the move and so there are areas where and 84% Accuracy rate, 16% falls positive rate. It's perfectly acceptable and where people will probably get more and more than 70. You said 98%, what I have seen is more like 84 and by really a lot of blood sweatin tears, you can get up to 92 and a half. Right. So this is fine if it is a pre-screening stuff before the human look at it. It is not good enough for life-threatening situations. And so there's lots of areas where the fascinists is perfectly acceptable and good and better than humans, cheaper than humans. But it's not the kind of engineering stuff I'm mostly interested in. I worry a bit about machine learning in the context of cars. You know much more about this than I do, I worry too. But I'm sort of an amateur here. I've read some of the papers, but I've not ever done it. And the idea scares me the most. is the one I have heard, and I don't know how common it is, that you have this AI system, machine learning, all of these trained neural nets. And when there's something as too complicated, they ask the human for help. But the human is reading a book or a sleep. And he has 30 seconds or three seconds to figure out what the problem was that the AI system could handle and do the right thing. This is scary. I mean, how do you do the coddle war between the machine and the human?

It is. And now it's stating a problem, not that it's emotional.

Let's just get one effect in. all of this AI stuff is on top of us. So that's one reason I have to keep it whether I out or what's going on in that field. But I will never become an expert in that area. But it's a good example of how you separate different areas of applications and you have to have different tools, different principles. And then they interact, no major system today is written in one language. And there are good reasons for that.

It's obvious I've spent a lot of time with C++ and there's a combination of a few good ideas, a lot of hard work and a bit of luck. I've tried to get away from it a few times, but I get dragged in again, partly because I'm most effective in this area, and partly because what I do has much more impact if I do it in the context of C++. I have four and a half million people that pick it up tomorrow, if I get something right. If I did it in another field, I would have to start learning, then I have to build it, and then I'll see if anybody wants to use it. One of the things that has kept me going for all of these years is one of the good things that people do with it and the interesting things they do with it and also I get to see a lot of interesting stuff and talk to a lot of interesting people. If it has just been statements on paper on a screen, I don't think I could have kept going. But I get to see the telescopes up on Marna Kier and I actually went and see how Ford built cars and got to JPL and see how they do the Mars followers. There's so much cool stuff going on, and most of the cool stuff is done by pretty nice people, and sometimes in very nice places, Cambridge, Sofia, Antibulis, Silicon Valley. There's more to it than just code. What code is central?

Yeah, thank you. And we'll make it even better.