The Story of C++: The World's Most Consequential Programming Language | The Official Story

My idea was very simple. A low-level language  to manipulate hardware and something called   Simula. A lot of people did not think that C++  was right. I look at C++ and I find it scary.   It underlies many of the biggest systems in the  world. If you make a small incompatible change,   you can annoy a couple of hundred thousand people.  C++ is controlled by a committee. C++ feels like   a new language. And they may look at C++ and  they say why. C++ is more than 40 years old. The world was very different from  today. In a way, a much simpler world,   in many ways a more exciting world. There's a  lot of stuff that did not exist and was just   beginning. We just simply cannot write all the  software that needs to be written. Colorization,   syntax highlighting, code navigation,  statement completion, refactorings. None   of that stuff existed back then. Some machines  only had like lineoriented editors, you know,   so if you want to modify something in a line,  you had to retype the whole line. It was just   really primitive. A lot of people programmed  in BASIC, but to do anything really advanced,   you had to program in assembly language. And  that assembly language is different for every   different kind of chip that each computer had.  Eventually computers evolved to what we have now.   This sequence of bytes. With an 18-bit address  the system can accommodate 256k bytes. There was   a need for larger and more complex programs. So  new languages appeared and in that milieu came   C++. Hello, I'm Bjarne Stroustrup. As a language  that promised great abstraction on top of a very   efficient bed set by by the C language. C++ did  not become as this one perfect thing coming out   of Bjarne's mind. It started as a very small thing  called C with Classes. At Bell Labs, about 50% of   the people are actually producing software. Bjarne  probably arrived in roughly 1979 or 80. I don't   I don't know what the queen is doing there, but  this is a bunch of PhD students in Cambridge.   I was at Cambridge and there was some contact with  Bell Labs. Some of the people from the computer   lab in Cambridge had gone there. And one was  back, at some point he said, "Well, if you need a   job next year, give us a buzz". So, I did. I flew  over to the States. I was met by Sandy Fraser. And   Sandy said, "Well, sit down, Bjarne. I've got some  bad news. We don't have any jobs". I just crossed   the Atlantic. Anyway, I gave a talk. Then they  changed their mind. And so I was there for the   next 24 years. Bell Labs was part of AT&T. At the  time, AT&T was a very large company, probably the   largest company in the country. Almost a million  people work for Bell at some 27,000 different   locations across the country. Three out of four  phones in the country are Bell. And so that meant   they had an essentially guaranteed revenue stream.  They knew how much money they were going to have   and they peeled off a little tiny slice of that  and used that to fund Bell Labs whose job was to   do things to improve telephone service. Its job  is to design and develop the products, systems,   and services to keep communications purring. I was  astonished when I came to the United States. You   could call from New York to California and there  was absolutely no noise on the line. Because there   were so many people they could take a very very  broad view of what it meant to improve telephone   service. So anything that somebody wanted to  work on, arguably that was fine. A lot of the   textbooks are written by people from there, they  built the C language, the Unix operating system,   a lot of map drawing software, a lot of graphics  software, chips that later became digital cameras,   everything was going on there. It was the place  to be, right, if you wanted to do anything in   computing, I felt I had to do something reasonably  spectacular because that was what other people had   been doing. And so I decided I was going to build  a distributed system based on Unix. I set off   trying to figure out how to separate the various  services of the kernel into separate modules and   to think about how users could talk to each other  through this kind of stuff. I realized I couldn't   write the code I wanted because I needed to be  able to manipulate the hardware. You have to   write device drivers, network interfaces. You  have to implement memory managers, processes,   things like that. You needed a low-level language.  Along the way, in the course of the Unix system   development, Dennis Richie created the C language.  It came out of the department at Bell Labs I was   in. Dennis Ritchie and Brian Kernighan were down  the corridor. So C was the obvious one to pick.   It lets you avoid the details of the machine  when you want to, but when you need to,   you can control everything. It was very well  designed for system programming kinds of things,   like writing the tools that themselves are used  by programmers. C was a very great language   which fully described the machine. One thing  that C didn't do was make it really easy to   control what was going on in a program as a  program got big. We developed software that   was unbelievably big in terms of the number of  users or the performance demands on it. You know,   everybody in the country is picking up the bone.  That's an AT&T program that you were talking to.   C was not in some ways an ideal tool for that.  For a distributed system, you really really   have to be able to say this piece of software  talks to that piece of software over there.   How does it talk to the other one? What protocols  do you use? And where is it? You can't just have   a a rat's nest of pointers into memory because  they will probably not share memory. So I needed   a high level language to be able to say this is a  module, this is a communication channel and such. In Aarhus and Cambridge, I'd used Simula, the  original object-oriented programming language,   and I really liked it. It had strong type safety.  It had the ability to build your own types,   classes. It had class hierarchies. And so that  gives you a way to take something that could be   potentially very big amorphous unstructured thing  and put a lot more order and structure on it. It   was also far too slow and used too many resources,  too much memory. So I decided I was going to put   the basic functionality from Simula into C. So  that was why what I did was called C with Classes. I spent the next almost 40 years trying to get to  the point where C++ can do everything that Simula   and C could do. That quest is probably what made  C++ a success because that was always a challenge. Here we have an old picture  of Bjarne and Kristen Nygaard.   Does it say Uppsala something? I don't  know. If you have a digital version of it,   then you probably could. I have a digital  version somewhere. Yeah. Yeah. Yeah. Yeah. I didn't know you knew SNOBOL. Yes. Yes.  Hardly anybody knows that language. Oh,   this was it. This was it. This is actually a paper carbon thing put up  at a conference because Bjarne didn't attend   in person. So they had some booths presenting C++  and then they had put this one up. You could go   over there and they could take a picture of you  and then they would uh make this thing. Yeah,   it's a cardboard copy of me. And up here  I have several of Bjarne's books also.   He used to send me a copy whenever he wrote a  book, but recently he hasn't done it. Oh dear. I built C with Classes as a pre-processor to C,   so that I could write the code I wanted. It was  sort of a success. other people started using it. Bjarne Stroustrup was working literally down  the hall from me and I knew vaguely that he   was working on something that was trying to  make C a more abstract language to program in.   So I started learning that and talking to him  about things he was working on in that area   and eventually we wound up working quite  closely together for a number of years. So, this is the Bell Labs building at Murray Hill,  um, where Bjarne and I worked for quite a while,   and now it's in the process of being cleared out,  but it's where a lot of the early C++ work was   done. And there were a bunch of real interesting  characters. You put a lot of highly intelligent   people together in one place, and all kinds of  things happen, some of which you can control, and   others of which you can't. I realized one day that  C with Classes just wasn't a significant enough   jump from C to be viable. That it was a medium  kind of success and it would never be anymore. I thought I had just two choices. I could drop  C with Classes or I could make it much better.   So I spent a year building a compiler and  improving the language the way you could   only do if you have a compiler. So originally  Bjarne just wrote CFront. Instead of having a   traditional backend that compiled down to  machine code, it compiled to C code. So if   somebody wanted to use C++, they didn't have to  buy into a whole new way of doing business. They   didn't have to buy into a whole infrastructure  of other stuff. They didn't have to write new   libraries. All of that was completely available  because C++ was just translated to C. That was   done in 83. And it's a real compiler. It  did lexical analysis, syntax analysis,   type checking, generating a tree representation  and then did optimizations on that tree. A lot of the input to the design  of C with Classes, and later C++,   came from people dealing with systems programming,  dealing with distributed systems, dealing... I   guess one thing that is mildly interesting is the  question where did the name C++ come from. Cfront:   not very useful and that's an implementation, C  with classes: a bit dated. So I asked my friends   to make suggestions and I got a list of about  20-25 suggested names and then I sort of liked   C++. It was bit weird as a name but makes  semantic sense because the ++ operator is   part of the C programming language. It basically  means increment and so C++ is an increment on C.   It really should have been  called ++C for semantic reasons,   but I took pity on people doing indexes  and referring to it, so it became C++. AT&T's famous Bell Labs in New Jersey, home  of countless technological innovations,   but mostly in the field of communications. For up  until last year, AT&T was the phone company. But   now with deregulation and divestiture, AT&T is  free to move into other ventures. And one of its   first and biggest new ventures is the move into  computers. AT&T decided that they were going to be   in the software business. And this was, I think,  one of the truly dumb ideas of the company, but   that's okay. Today, AT&T offers an entire family  of computers based on leading edge technology.   One of the things they were going to do was to  sell a C++ compiler. And in the days we're talking   about things like compilers were piggybacked along  with hardware. You got your compiler from IBM,   you got your compiler from HP, you got your  compiler from Sun, you would get your AT&T   hardware compiler from AT&T. There were a  few companies that were actually genuinely   interested in and paid for C++ compiler and there  was a development group which worked on a call it   an industrial strength or production quality C++  compiler. That didn't work too well because they   couldn't actually deliver a good compiler. There  was only 14 of them. But I got peace and quiet to   do my work. The hardware didn't sell well enough.  So, a lot of that software ended up not being ever   commercially viable. And that was what allowed  me to basically give away early implementations   of C++. They weren't free. You had to pay for the  tape it was on. And if you had a commercial use   of it, they wanted some money, too, but not very  much. I'd like to tell a bit about C++, why the   language looks like it does, and present some of  the main techniques that the language was designed   to support. I was giving a talk for Bell Labs for  a movie. They wanted me to to to read out from   a prompter and a third of the way into the talk,  the prompter broke down. But I really didn't like   it. So I carried on blind for the next two thirds.  And each time I had to think about what to say. I   grabbed up and pulled the bird to give me time to  think about what to say next. And so that video   became known as the goose video. And this is it.  At that time I was doing the documentation. I was   doing the compiler. I was doing the language  implementation and I was the help desk. Having all of these balls in  the air, at the same time,   led to significant improvements. Bjarne  designed the language to make programming   more pleasant for the prof- the serious  programmer. I always thought it was   professional. I went and looked it up. It's in  the preface to his first edition of the book. C++ allows you to think abstractly about the  problem that you're trying to solve. You don't   have to think about what's the computer doing  all the time. And you get performance that is   commensurate with, not identical but commensurate  with, languages like C. It really did make   programming more fun because you could get more  done more quickly. As CFront became more popular,   it became necessary to have a user interface  organization so that Bjarne didn't have to   send out compilers to everyone and fix every  bug that got reported and deal with everything   himself. It wasn't getting any investment  by the way. No? No. On language proper or on   the compiler there were, you know, maybe five  people. Not a major investment for AT&T. No,   it was a very small effort. Originally, it was  literally one person. Bjarne was everything. We   should have had a bigger team, but we never  did cause I think AT&T just really didn't   know what they were doing. And at the time we  were all, why don't they give us the staff we   need? In retrospect, as a sort of more mature,  not in the middle of it, they were all so lost   themselves. They're just figuring out how to be  in the competitive world. And they didn't do a   very good job of it. Actually, AT&T did give  me some money once to do some organization,   $5,000 to be used over 3 years for popularizing  a general purpose programming language.   doesn't make any sense. I gave a party  at the first C++ conference. That was it. When I think back over our years of C++, I always  thought it would be successful because people had   this response to C++ that made it seem like  they wanted to use this language. And it just   was a matter of growing as the community grew  and adding new applications as libraries were   made available. It wasn't an overnight success.  Yeah, it was not an overnight success. And I   remember Bjarne once said, "Being an overnight  success takes decades". Right. Right. Andy and   Barbara did something that really good developers  rarely did in those days. They tested. It was a   buggy product for a long time. We were making a  release. 2.0 was a huge release. It was intended   to fix some of the long-standing reliability  and, you know, just plain old bug issues that the   compiler had, but it was really going to be the  commercial release. After CFront 2.0 was shipped,   I discovered that there was a bug in  how it handled multiple inheritance. So, we had this horrible problem that there was  a major feature that we had promised. Come on.   There we go. That we were delivering for the  first time and was broken in a way that if it   got out into the field, it would never be possible  to fix it. Compatibility in a programming language   is crucially important. Once people have existing  code, they don't want to have to change the code   just because you found you wanted to change  something in the language. So we used to joke   about compatibility was the C word because it was  dominant. This was just a completely horrendous   state of affairs. Totally unacceptable. We were  able to scramble a fix in a few days. Our software   distributed at the time out of a tape library.  We sent them a tape. They duplicated the tape   and then they distributed it to the customers.  But then we had to deal with the problem of what   today is called slipstreaming. Every once in a  while, someone will ship a system that's just   completely broken and they'll come out with a new  one and give it the same release number and now   all of a sudden someone files a bug report. You  ask which version they're running and they say,   "Oh, we're running version 2.0." And you ask, "Was  this version 2.0 or version 2.0? The one shipped   before such and such a date or the one shipped  after. Well, how do I tell?". Well, of course, a   tape has a label so that you can tell one release  from another release. Well, we couldn't call it   2.0.1 because that would be egg on our faces,  we couldn't even get the first release out. So,   instead of shipping version 2.0, we shipped  version 2.0.0, which we all affectionately   referred to as 2.Oh.Oh. That was probably one  of the tensest technical problems that we came   up on because if that had gotten out there then I  don't know what we what we would have done. Uh oh. C++ had kind of a bifurcated existence  within AT&T's overall corporate world.   A huge part of the support for C++ came from  internal development groups. And in fact,   a huge reason C++ was ever given the resources,  minimal as they were, was because management   understood that it would make programmers  inside AT&T much more productive themselves.   They'd write better code faster with smaller  teams. What's not to like? But a programming   language is never going to be successful  if it's captive to a single corporation.   Programmers wouldn't come in knowing  the language. We would be the only ones   writing the software itself, developing  libraries, all kinds of overheads. So,   it had to be external as well as internal.  People was starting using it outside, but   it was quite small. This is well before the web  existed, but there was this thing called Usenet. Usenet is a sort of a glorified bulk email  system. There was a whole category of groups for   programming languages comp.lang.c, comp.lang.c++,  comp.lang.fortran etc. So that's certainly one way   in which information got around. There was a huge  community of computer magazines at the time. There   was in particular one called Byte magazine which,  I mean, it was literally the size of a phone book. That was the Bible. that was the  source of knowledge. And C++ was   in the magazines. We would see that and  were like, we ought to try that sometime. What I have here is an issue of the Danish PC  World magazine from February of 1989. Here's this   article with Bjarne and I. I look like I'm fresh  out of high school, which is not half untrue,   uh I think I was 28 years old. One great thing  that Bjarne has done back then in the late 80s was   to give talks at any company and any organization  that would have him and he relentlessly worked on   proselytising the language. That was a very  successful campaign on his side. We saw this   use of C++ going up like that. And the thing I'm  somewhat proud of was there was no advertising   campaign. No, no, no sugar daddy trying to push  this out in the world. It just spread. The fact   that there was this notion that you had data  together with functions and a whole new way of   thinking about programs and programming. All of  that was enabled by C++ to be honest. And back   in the 90s, it was so much emulation and so much  energy and so much enthusiasm about the language.   Writing C++ applications. The design and evolution  of C++. C with classes and later with C++. C++,   C++, C++, C++, C++ code, C++. The downside  is that C++ was all over the place. There   was different implementations. There's different  standards. Things were really incompatible. There   were multiple implementations of of C++, right?  Many in the early times. Borland wanted one,   Microsoft wanted one, IBM wanted one,  Sun wanted one and they just built it.   Each vendor started implementing their idea of  templates in particular and they were pretty   divergent. They worked in different ways and  they had different strengths and weaknesses,   different trade-offs because of design choices,  but they weren't compatible. Every company would   say, "I will make it better." and things  will diverge. So if you write code for one,   it wouldn't compile on the other, there will  be terrible, terrible situation and eventually   language will collapse. Obviously there's a strong  desire for there to be compatibility between them. One day, a couple of people turn up in my  office and say they represent IBM, HP and Sun,   which are the three biggest computer manufacturers  and software deliverers in the world at the time.   They basically said, "Bjarne, you want to  standardize C++ under the ANSI rules." The   American National Standard that later became  ISO. A standard is a contract between a person   writing C++ code and an implementation of C++.  So when you write a certain piece of code,   you have a guarantee that it will do whatever the  contract ie. standard says. Obviously, I said,   "No, I can't do that. It's too early. I'm doing  all of these experiments and it's not ready. No,   Bjarne, you don't get it. You're going to do that  because otherwise we will do it and you know we're   going to mess up." Oh. And this went on for about  an hour and basically twisting my arm. Ow. Ow. Ow.   And they're saying things like, "Of course, we  trust you, but we can't trust AT&T. Sometimes   we compete with AT&T." Yes, he was forced, but  it was something which is actually very good for   the language and for him and for the world. The  standards are not necessarily good or correct,   but they're standards. It's why do we need  traffic laws? Traffic laws are very often   idiotic but we have to obey them otherwise we  will die. And so in the end, I said, yes okay   I'll help standardize C++ under ANSI rules  just give me one year before we start that   because I have to write the document that  was the foundation of the standardization. Bjarne shipped the Annotated Reference Manual,  what we call the ARM. This was sort of the input   into the standardization effort which were to add  templates, exceptions and and namespaces, things   like that. And shortly thereafter, there was  an ISO standards committee established. Clearly   standardization is is not easy. People have  to agree and it's especially difficult because   the language is still evolving. At the time  the standards committee was almost manageable.   There was only about 100-120 people involved from  all over the world and all the major companies.   This is a collection of pretty much random  people. Many of people who represent countries   just nominate themselves. The guy who represented  Australia also represented New Zealand, because he   wrote them a letter saying I represent Australia,  I have to travel there anyways. I could represent   you guys. And they said, "Oh, yeah, fine, good.  We'll have representatives there." So, he had two   voices. He could outvote United States. I believe  it was Winston Churchill saying that democracy is   the worst way to organize a country, except  for all the others. There's value in having a   consensus, especially when it's something that now  multiple vendors have to agree on and implement. The standards committee was happily going on. And then along comes this fire  branch named Alexander Stepanov. A dozen of us were at a tapas restaurant. Not  a topless restaurant, a tapas restaurant. Alex   gestures to one of the servers and says, "I would  like four bottles of red wine, please." Stella,   come. "One for all these people and the other  three for me". It cracked up everybody at the   table. That memory really represents Alex  for me. Just a a guy of immense enthusiasm   and verve. The STL, the Standard Template  Library was one of these major inventions   from Alex Stepanov. C++ did not yet have a  standard library before STL. Everybody had their   own array class and their own like list and their  own trees and containers and ways to do algorithms   and ways to do things and whatnot. They  were competing at this level of Nirvana,   right? And they're all comparable to each other  and it it was unclear which is better. And STL   came at like 10,000 meters and everybody here  was we actually we can't compete because we're   in a different not in a different category in  different game. Okay? Much inferior. I realized   that algorithms are affiliated somehow with  mathematical theories. His thing was to design   runtime libraries that would make it possible  to reason formally about data structures in   programs. The central idea of STL is to write  algorithms which will work on all applicable   data structures and assure that every data  structure could populate any other data structure. We talked at some point about what he had  accomplished and what this library looked   like and I thought this is something that's  completely revolutionary. Maybe we should be   rethinking what we're going to do. And  I spoke to a few people about that and   was told we have a timetable. It's really  too late. We can't do anything about it.   So what I thought was, well, the one thing I  can do is to make sure that Alex gets a fair   hearing. I know we have a timetable, but I  want you to hear what this guy has to say.   So I gave a talk entitled The Science of C++  Programming. I don't think anybody actually   understood what I was saying, but it was  very well received. The committee said,   "We're way too late in the cycle. This is way too  big a proposal. Look at Look at this. It's wow.   This is pretty good stuff. We really need this".  He gave such an electrifying presentation. It was   just so brilliant. I got a standing ovation once  in my lifetime. He's a splendid rabble rouser   when he's into some idea. He can explain it very  well. And then Andrew sent me a message saying,   "Why don't you submit a proposal for standard  library in C++?" I answered, "Andy, you're crazy."   Because I thought that the chances of it being  successful was zero. But my collaborator Meng   Lee convinced me that instead of wasting my life  gossiping around, I would do much better if I try. Amazingly enough, it was not rejected offhand.  And at that point, I have to say that Bjarne,   who still didn't quite understand what I was  trying to do, but he became convinced that it   was a very promising direction. I could use the  same algorithm for reducing n elements together   into one. And then I realized one very, very  simple thing. The fact is that both plus and   times and min and max are associative. It looked  really weird, I thought. But over the years,   I built up a list of criteria for what would  make a good foundational library. And when I   checked this weird stuff that I got from Alex,  it checked I think 11 out of 12 of my points. No   other library design I'd seen could do that.  And he started working with me very closely. My contribution was partly to  curb over-enthusiasm from Alex,   partly to provide the language facilities that  allowed him to do what he wanted to do. To great   degree this part was a collaboration of Bjarne  as a language designer and me as a algorithms   and data structures guy. And then convincing the  committee took a lot of discussion and examples.   We resubmitted the revised proposal. We  didn't believe it would succeed because   all the powerful companies such as Microsoft,  at that time the dominant company in software,   were very opposed to it. The committee  was convinced it was too complicated   and too difficult to implement. I have to give  great credit to Bjarne. People would say, "Oh,   I want such and such function." And he would tell  me, "Oh, put such and such function there." and   he was very successful and I don't think that  STL would become a success without his support. They voted like, I think 80% of the  committee suddenly voted for it. Of course,   Microsoft didn't and other major players  in the library world voted against,   but they were a minority and STL became part of  the standard. When I first saw the STL in 1994,   it blew my mind. It was order in chaos. It was  rigor in a mess. The STL came and established   the one way to define algorithms, the one way  to define containers, the one way.. And it was   superior in so many ways and so absolutely  visibly, undeniably, essentially everybody's   like well we better get with the program. The  reception of STL was quite enthusiastic. It's   not that people knew what to do with it nor did  they quite understood how it worked but it was   enthusiastic. It was new. It was very unusual  at that time. Oh, I think that it has had at   least as much of an effect on how people program  as the existence of C++ itself. I immediately   thought this is huge for C++. This is going to  carry C++ into the next millennium. And it did. Let's see if I can find it. The words that we came  up with were Studebaker and Vivisectionist. And   so the idea is you try to get those words into the  discussion and you get extra points if you can get   them both into the same paragraph without people  suspecting. And Bjarne said, "Well, let's see if   we can get those into the standard, you'll find  those there". And not to be outdone, I said, let's   see if I can get a limerick into the description.  And it's in here somewhere. Let me see if I can   find it. It would be page two, one. When writing  a specialization, be careful about its location   or to make it compile will be such a trial as to  kindle its self-immolation. Studaker Studebaker   and Vivisectionist. Those were the code words. Those were the words that we had to try to get into the standard somewhere. Nobody independently noticed it that you know of did they? Not that I know of. - Who's reading that? - It's really buried. It is really buried. C++ got standardized in November 1997. Where we  added several major fundamental features: name   spaces, exceptions, templates and the Standard  Template Library. LLVM was really fortunate to   start after that. What we could do is we could say  okay well this is the language as it's supposed to   be now, we didn't have the compatibility problems,  we didn't have to migrate old code, we could just   use the new features and use the language as it  was intended to be used. The people who came to   me and said they wanted standardization were  very right. I think it was a huge contributor   to the success of the language, no standardization  would have meant the language would have forever   been like the wild west, serious companies  would not have adopted it for for their use. CERN is an international organization funded  by its member states and C++ has been in use   here at CERN from at least the early '90s. In  high energy physics software and computing,   which is the field I'm mostly expert of, C++  was a real paradigm shift. Before the language   was Fortran and it did quite of a good job. I  mean the results are there to to testify this,   but when C++ was on the rise, I think at the  beginning of the '90s, then people realized that   the language really offered many assets. And lots  of libraries and existing code was ported to C++,   and even reinvented for C++ because the paradigms  behind the two languages are totally different. They have data analysis software,  process control software and   visualization software and all of that  plays straight into C++ strengths. It was spreading by itself. Some company tries it,   then the next company tries it.  By, say, 2000 it was everywhere In game development a lot of people were  aware of C++. There's already video cards now,   taking care of like that low-level stuff, so it  kind of pulls people from C and assembly up to C++   and APIs. There was like a focus change there. So  I run the game on the PC and develop it in Unreal.   Everything else is always in Mac OS. C++ is really  great for games because of how you can organize   everything in your game. And C++ does a lot more  than that. But in gamedev, people kind of restrict   themselves to that. So they have full control  over the amount of time that's being spent,   you know, per cycle. You have to have all the  cycles you can. Don't jump into the runtime. It was used early on surprisingly in the financial  industry. Wall Street was just getting into doing   program trading and having computerized support  for the traders. Rewind to the to late '90s, early   2000s. What does trading look like? You imagine  like sort of pit traders yelling at each other,   having a human in the loop clicking a button  to ensure a trade gets executed. It was very   inefficient. Some economists think the days of  face-to-face trading are numbered. It's known as   highfrequency trading and it was the web culture  taking over what the stock exchanges had done. So,   HRT was founded with the idea of like, okay,  there there's really some automation that can   happen here. Little differences in performance  can make big differences in economic viability   and therefore performance matters in many cases  more than you might think. Latency is really   important in trading. Microsconds matter in this  space and C++ is a language that lets you achieve   that latency without really needing to micro  optimize every line of code. I'll use a quote   from my friend Scott Meyers: C++ is for demanding  programming problems. I still have abstraction,   but I can make full use of hardware. And it turns  out that lights up a lot of different industries. It's described as nothing short of breathtaking,  a points drop never before seen on the US market.   2000 came, the dot com crash, and with it a lot  of the tech companies and the tech industry,   but also there was the growth of Java.  This week on the computer chronicles,   the secrets of Java. Today we're going to find  out why Java, the software programming language,   is such a big deal. Java came very heavily  marketed by Sun Microsystems as the language of   the future and the language of the internet. What  will be possible tomorrow? You decide, because   Java is everywhere. There was executives from Sun,  that was going around saying Java will kill C++,   absolutely kill C++ in 2 years. I remember I had  managers who were like I'm not sure what it is   exactly but we got to get into this Java stuff,  because it's awesome and everybody loves it and   you know that kind of stuff. Java is an explicit  reaction to the complexity of C++, the perceived   complexity at least. And so Java was an attempt  to get some of the same benefits that you get   particularly from object-oriented programming, but  in a form that was not so complicated. That was   not favorable for C++. And that combination  of events ignited or started, if you wish,   the C++ winter of the early 2000s. It was not  just stagnation that happened around 2000-2005.   It was.. decline. There was one more factor that  contributed which was the computers were getting   faster at an exponential rate. Computers started  temporarily being more powerful than the software   being run especially on singlethreaded code. Right  now it's hard to imagine that you would have a   processor that doubles the frequency every couple  of years but that was the case back then. And we   just thought, "Oh yeah, computing is just going to  be getting getting faster and faster indefinitely.   We better write bloated operating systems, and  stuff like that, to soak up the power". Like   this was actually a way some people thought.  Most people who design programming languages,   and especially back then, say: performance doesn't  matter. Machines are getting so fast. We'll just   wait a year and then it'll be fast enough. So  this combination of factors led to an sort of   an exuberance of inefficient programming  languages that played out poorly for C++. At that time, at Microsoft, we really  had two distinct groups of programmers.   We had the C++ programmers and that was all  about power and expressiveness. And then we   had an enormous cohort of Visual Basic programmers  which was a very different crowd you know because   we were talking about rapid application  development. You had like a form designer   where you could just drag and drop buttons and  text boxes and a lot of enterprise software was   being built with that. But when it came time to  deploy it you kind of wanted better performance.   So we were seeing this phenomenon of people  writing the app twice. First they prototyped   it in Visual Basic and then when it came time  to actually deploy it they would go rewrite   it with a different set of programmers in C++  with a different framework, you know like for   your windowing system and it was not a super  efficient way of getting to your software. So there was this sort of latent desire to have  a language that had the ease of use of Visual   Basic but the power and expressiveness of C++,  and that's what we set out to build with C#. There was no shortage of people telling me that I  should be afraid. I can't really count the number   of times I hear comments like, "Uh, oh, you mean  C++ is still being used?" Or, "Why would you want   to use C++?" A lot of this talk of C++ is dying  a slow death". "I'm famously not a huge fan of   C++". "We got Java, which is basically just a  better C++". "Is C++ dying"? Everyone wants it   to be a war. It was never a war, I don't think.  People think that every language designer wants   their programming language to be the the one  and only. To me, that seemed a very strange,   weird, and arrogant view. Programming languages in  general, they are tools that allow us programmers,   developers to express our ideas in a way that  machines can execute. So understandably people get   strong opinions about how you're telling them to  express their ideas. It does become religious for   a lot of people, yes. I never had this idea that  C++ should be the only language or that it could   be the best language for everybody and everything.  I don't think any language can do that.   Every language that is successful in  the world today has its place and is   there for a reason and is affinitized  with a certain kind of programming. Yes,   there's a bit of overlap between C++ and C#, but  it's not all that large. And so it isn't really a   war. It's more of a complimentary situation. You  know, we serve different communities. And sure,   you could try to write your enterprise apps in  C++ and have your enterprise programmers worry   about memory management and and dangling  pointers or whatever. Or you could try   to write operating systems, low-level embedded  systems in C#, but they're poor fits for that.   There's a right place for for everything.  And well, most Java compilers are C++, so... 2004 something abruptly came to an end which is  the frequency scaling of processors. Around that   time I started hearing rumblings from senior  architects at work at Microsoft who were   noticing hardware starting to slow down. There's  diminishing returns. They're not able to ramp up   the instruction level parallelism as much anymore.  They're starting to hit the performance per watt   limits of a single core. For the first time in 50  years, which is the whole history of computing,   mainstream hardware is no longer a Von Newman  machine. Everything is changing underneath us,   and a lot of people I think are still ignoring  the impact of that. Everything is pointing to   that the world is going parallel. And  I started realizing this doesn't seem   to be something I read about in the magazine.  I should probably write something about this. If you wanted to have your programs run faster,  you couldn't just wait for a year and have the   hardware save you. Which meant C++ was again a  good offer in town for an efficient programming   language. That and that C++ was now good  enough to be used in embedded systems.   There's many more embedded systems than there  are sort of computers with screens like that.   I mean we have two of them sitting  right there. So after 2004 there was   an increase in adoption of C++ but there  was an odd factor, which in my opinion,   contributed to the stagnation of the language  during that time, which was the leadership of   C++ was complacent. And I wrote a email  that became famous of sorts which title   was "C++ multi-threading: is the standardization  committee listening" and it was about multiple   threads because multiple CPUs were coming out and  threading was a way to make programs go faster,   but C++ had nothing about threading at the  time. Didn't even mention it in the standard. We wanted to deal with concurrency and we  wanted to adopt something that was rather   similar to Java's model. It got de facto vetoed  by IBM and Sun because they pointed out that if   we ran that way, their Java implementations would  half in speed because they couldn't use all the   interesting, dirty tricks they were doing with  C++. We actually had to work for another 2 years   coming up with something that was more advanced,  more complicated. You need to have the tools that   allow developers to write very quickly, to express  ideas, to get their stuff done. And for a long   time, C++ didn't have that kind of tooling. Herb  was the one who said, you know, we got to create   a new standard, address multi-threading, address  these issues in the language, and that changed   everything. Andre, hey, how you doing? Are you all  ready for tonight? I will. Oh, good. I was born   ready. I know you were. I know you were. Hey, good  to see you. So, looking forward to your keynote,   by the way. Thank you. Hey, Matt. Good to  see you. ISO calls the role that I've had the   convenor. The Convenor. The role of the convenor  is to convene meetings, say when and where we're   going to meet. It's administrative. And to get  consensus. Consensus does not mean unanimity.   It means everybody has been heard and then the  committee makes a decision that everybody can   live with. And so in 2002 we started work on C++0X  because it was intended to ship in like 07-08-09,   somewhere around there. Currently the goal  is that x is not hex, that we're going to   be done next year in 2008. It took 13 years  because when you get close to the release,   people say this feature is so important, you  must delay the standard to get this feature in.   And then you delay the standard and then somebody  else comes with a new facility that really should   be pushed. Herb really pushed C++ from complacency  to literally to where it is today. I just started   talking to the the main subgroup chairs and  said like why are we delaying? The community is   wondering if we're ever going to ship a standard  again because we already are several years over.   We don't need to wait another two years. Aren't  we ready to ship this now? And enough people said,   "You know what? Yeah, I guess we're ready to ship  this now." Herb's a great guy. You need different   kind of people to do different things. For  starters he's a much better organizer than I am.   One of the things that Herb did was to also  popularize the work that the committee is   doing. When C++11 did ship, a few years  later than we thought, but then did ship,   it was at a great moment in time because at the  same time as the standard made C++ much easier   to use and safer than it had been before,  there was a renewed realization of getting   the most out of our hardware, which is what C++  is good at. That was a real renaissance moment. C++11 is completely different. Yeah, they  share syntax, but the way you think about   problems is very different. With 13 years  from the first to the second standard,   there's a lot of new stuff coming in. We had  move semantics. We had concurrency, which was   work by Hans Boehm and and his friends.  That was the first language, you know,   in the C family that formally said something  about threading. If you only took those two,   it's already big. At the time here at CERN, we  were evolving our data processing frameworks   that relied on event parallelism into something  that was more suited for the multicore CPUs that   were appearing on the market and became the  the facto standard, and having the obligation   to rethink our way of processing data with  parallelism at its foundation was easier   thanks to the tools that C++ provided out of the  box to us. Things like auto, range-based for loop,   smart pointers. That lambda was cool when you  added that, but the garbage collection was not   cool when you added that. It also started the  whole constexpr thing, which is a way of getting   certain kinds of evaluation done at compile  time, in a way that's easily expressable in   the language. These are all things that were like  a major refreshing upgrade where it's still C++,   but man, it feels like I'm writing a new language.  Maybe I should dust off my C++ coding skills again   and take a look at it again and put that C# in  the drawer for a while. You use the right tool   for the right job. After that, we had lots of  discussions and I spent about two years trying   to convince the committee, you know, we really  should go to timebased releases. Referred to as   the train model. The train leaves the station  at this time. If you don't make that train,   you don't stop the train. You wait for the next  train to leave the station. That way, the whole   industry knows we're going to release and we never  go dark again or they wonder if we're ever going   to release a standard again. If I'd had my way, we  would have shipped every two years. The committee   said, "No, that's too often. Let's do every three  years." And I was happy to take that as a win. If you're still stuck in 98 either mindset  or compilers, upgrade. It's the best way of   getting ready for the future is actually at least  get to the present. C++14 was a minor kind of bug   fixes release. It basically put in place the  things we couldn't get into C++11. And today,   I'm going to be talking about C++ 17. These are  the 26 features we're going to be talking about   today. On one hand, I think the C++17 was like  a really high peak in terms of the capabilities   they enabled but ever since then they've been  adding more features. So let's have a look at the   agenda for today. There's quite a lot. So I'll  be giving an overview of all the new language   and standard library features coming with C++23.  There's a huge community and a huge committee of   people that are adding new things to C++. And so  one of the big questions C++ has to wrestle with   today is like where does it end? The ways the  C++ has evolved was by essentially like we have   this language we add something on top of what's  what's existing and that's your new armor that   you're going to roll with right and on top of  that there's more and more and more and more.   How did you manage to add this many things to  the language and 99% of them are critically   broken? It's almost like a winning streak. Well,  I guess it's a losing streak. C++ is absolutely   atrocious. First of all, there's like 20 different  ways to initialize a variable. It's an infinite   Gordion knot of unfathomable complexity. C++  was always a fairly complex language and it has   only gotten more complex over time. And this is  not unknown. And that I think is the challenge,   right? The standards committee now is a  organization with lots of people. Last   time I checked there was 527 members. How you  get 527 members to agree on something, I don't   know. We have as many committees and committee  chairs as we had members when we started. And   this worries me. "I had one person describe  the committee as the Real Housewives of C++". "Do you agree with that?". Whenever you  get lots of people discussing things that   they're very passionate about,  you're going to get a lot of... conflict. I think if we didn't have any drama  that we wouldn't have people that actually care   about what they're doing. One of the problems  with committees is that you have a tragedy of   the comets. It's very easy, relatively speaking,  for people to add things. And so, it's not that   any one of these ideas is bad, but adding more  and more and more and more and more conceptually   is bad. You kind of have to find a balance between  having too many opinions and also having opinions   that represent the community. Well, we do the  best that we can really. I think we're constantly   trying to bring in more knowledge, more people,  more experience, but yeah, with that you simply   get more people and it becomes even harder to  agree on any given thing. I'm fairly optimistic   still. There's a lot of really smart people  working on C++. I think that the intentions are   good, but this is one of the challenges that the  C++ community struggles with. In a lot of ways, it   becomes a game of knowing when to say no. There's  no shortage of things you could add to a language.   But one thing you learn as a language designer,  you can add, but you can never take away. Welcome to a session that I did not  know I was going to give until I   foolishly volunteered about a week  ago. Any improvement that you make   in a language like C++ has an outsize  impact on the world, an outsize benefit   to our society and civilization because so  much of our infrastructure is built on C++. We can go and have a look at some of the stuff  they're building, because one of the reasons   I go is that to see what people do with the  language, and everything here has C++ somewhere,   quite often well hidden underneath everything  else, that includes JavaScript and Python and   things like that. I was asked recently  about where C++ was used. The simplest   and most accurate answer is roughly everywhere.  It touches most people on Earth or at least half   of the people on Earth every day. "Would you want  to try the VR or?". "Um sure". It's in your camera   there. It's in the electricity generation,  wind turbines, rice cookers, bowling alleys,   Hollywood movies, cars, finance. It's all over  the place. So, wow. So, it's going to uh it's   going to be a different world right now. Oh, I  see. The steering wheel is in the wrong place.   On with the touchcreen if you want to. Last time  I tried this, I got burned by Smaug. Okay. You   have to interact with with people, you can't  do language design language development just   in isolation if you do it in isolation that's how  you come to solve the wrong problems and that's   useless or worse. To give a sense of the scale  of HRT's C++ footprint, we currently have over   a million lines of C++ code in our codebase across  15,000 files. Our repository has had about 84,000   commits just this year, 2025 alone, across around  800 developers that are actively contributing. For games, nowadays, C++ is kind of divided by the  ecosystem that you're working in. So, right now,   there's a lot of different game engines, and  the game engines are basically what dictate the   language that programmers are using. There's  Unity, which is C#, and then there's Unreal,   which is C++. And if you're making anything like  Call of Duty or anything that is like high frame   rate, super fast graphics, you're using C++  no matter what. It's for speed. That's why. A   lot of people are interested in contracts, but  there are two groups with very strong opinions   about it. C++ is very relevant to Nvidia, is  very relevant to accelerated computing. Even   though Python is the language that is experienced  at the surface of most of these applications,   what happens is that the very second you build  your Python program is going to tap into these   enormously optimized CUDA libraries that are  going to carry the burden of computation. So in   an interesting way, C++ powers the entire AI and  high performance computing milieu. What are the   fastest growing programming languages? Rust and  C++. C++ has climbed from 9.4 million developers   in 2022 to 16.3 uh in 2025. It is because we  have enduring demand for languages that are   good at performance per watt. What is certain is  that C++ found its set of use cases where it's   excellent and hard to beat. It's probably the most  widely available programming language anywhere. As the challenges in our industry  and our environment change over time,   all languages have to adapt. One thing that I see as a danger to C++ is  the lack of funding. From what I'm seeing,   a lot of the big players are moving away from  C++ into AI. It means that we're going to have   even less funding. So, I think that's one of the  issues and we need to somehow pull in people with   the money to come and give it to C++ in one  way, shape, or form. I would argue that right   now we're talking about the second winter of  C++ because there's a safety issue that's very   important right now. It's a real serious problem.  I really don't want my brakes not to work when I   press it. If I had a car. There has been a push  during the pandemic from various governments and   regulatory bodies to move away from C++ because  it didn't produce memory safety by default. It is the single most important problem that  we need to address effectively. A huge amount   of work has been done and is ongoing. We have  been hardening our software in C++ 26. It's   motivated us to where we've actually gone and  done important things such as: uninitialized   variables are no longer undefined behavior. That  entire source of security vulnerabilities is gone.   If you build with the C++26 standard library,  you have an option for bound safety for all   the common types in the standard library.  String, span, vector, all those things.   I think AI is going to influence a lot what we  think about safety in languages and generally   what we think and how we think about using  programming languages. Of course, there's   a lot of opinions but right now I can "safely"  say nobody knows what's going to happen. So on   Saturday, the world changed and we are going  to look back on that day, this past weekend,   for the next few decades, as a pivotal turning  point for C++. C++26 looks like a Christmas   tree. It has bunch of things a lot of people to be  excited about. Something called static reflection   is going to make some major improvements. You  can write program code that can see program   code. Reflection is by far the most impactful  single feature we have ever standardized. It's more of like a foot in the door than a  than a full-fledged feature. But in my opinion,   people are going to do amazing things with  it. It seems like a really powerful paradigm   that we think will go a long way once the  features are fully rolled out. Our problems   and our understanding of those problems  naturally change over time. And as long as   a language is a good solution to problems that  are faced by real programmers in in real code,   the language will live and the language will  grow to meet the needs of the programmers. Knowing the language as I do, I would say  that there's going to be a way in which the   language is going to again evolve and change  and improve and do better. But that's only up   to the people who are involved in the language.  Gabby explains the code by equations and I do   data flow diagrams. So we definitely think  very differently and that's one of the   really productive aspects of it. The thing  that I love the most about collaborating   with Bjarne - whichever way it goes, whether  we succeed or fail, I learn something. There are no other people like Bjarne in my  opinion. Nobody who could spend literally   his life. Such commitment is not known. I  very much hope that Bjarne would be more   recognized than he is right now. I can only  admire his devotion to the project. I mean,   what has he been involved for more than 40 years  now and he's still the benevolent dictator for   life, right? That's an incredible run. He  proved you can do efficient abstraction   at scale in the same way horizontally in  portable code. And we are all benefiting   from that because we wouldn't have so  much of the technology we have today if   we didn't have a way to write much larger  efficient software than we could with C. What keeps me going is the interest in  the applications and talking to the people   who built them. I've launched this  thing on the world and I feel I'm   obliged to help make it better,  more appropriate and help users. And the world changes and what  developers and students know   changes and so you have to do some  more. That's what keeps me going. That's right.