Latest / Strachey Lectures / Strachey Lecture: The Continuing Evolution of C++

Transcript

Strachey Lecture: The Continuing Evolution of C++ · Strachey Lectures

• 0:00
  So I said, okay.
• 0:18
  I'm going to tell you a little bit about C++. And most such talks either about what language is or how you use it.
• 0:29
  This I'm trying to make a talk about how the language became to be what it is and
• 0:34
  is the key evolution from the early days up till about three years from now.
• 0:39
  And if I get a bit boring, you can look at the pictures.
• 0:44
  Essentially all of the pictures have something or other to do with C++.
• 0:49
  Like, what do you think? Those turbines have been programmed in and so that's it.
• 0:55
  I am going to go a little bit into what is C++, his role in the world.
• 1:00
  What is what did I intended to be and what what what is it now?
• 1:07
  Then I'm going to give a code example. I really feel like a total fraud if I talk about programming and software development without showing code.
• 1:16
  I mean, if you see a presentation about software development without code, I start to worry and then I'm going to talk about the reason evolution.
• 1:24
  A lot of the talk has to do with what has happened in the last, uh, minus ten plus three years, something like that.
• 1:33
  And my, my thesis here is that the value of programming language is the quality of the applications.
• 1:40
  What matters is what interesting things you do with it.
• 1:44
  That is my measure of success, not the how clever code I can fit into it.
• 1:50
  You were column published format this this is this is very much a practical exercise trying to to do something good in the world.
• 2:00
  Of course, you don't control what people are using the language for and some of the things you might not like.
• 2:06
  But these are the things I consider somewhat cool.
• 2:11
  And I am not going to enter into language wars.
• 2:15
  I am I try not to be rude about C++ applications.
• 2:20
  So that said, you are not going to drag me into that and there's lots of interesting stuff here.
• 2:29
  So what I've been doing since my PhD days is distributed systems and I'm still very interested in that doing it.
• 2:38
  There is my one of my notions of a distributed system.
• 2:42
  It's a distributed system with wheels and a lot of C++ turns up in places where
• 2:48
  you would never think about it and you will never see it if it works right.
• 2:52
  It's if you notice, it's C++ is probably because something went wrong.
• 2:57
  The point here is that nobody understands all of this.
• 3:01
  Nobody can understand in any depth all the applications that I was just flicking through a few pictures of, neither do I.
• 3:10
  However, the purpose of the exercise, as far as I'm concerned, is to help people that are building these things.
• 3:16
  Therefore, if I build something that can only do what I can imagine, I failed.
• 3:22
  You have to do things I couldn't possibly imagine. The group here has more ideas, more needs than I could imagine, and that's part of the point.
• 3:32
  So what actually matters? The answer is lots of things.
• 3:37
  And one theme here is that we need stability and evolution.
• 3:45
  We need a language to evolve, our toolset to evolve so that it can handle new things.
• 3:51
  The world is changing. We're changing, the challenges are changing, and the language has to do it.
• 3:56
  On the other hand, you've always seen languages that are really cool for about five years.
• 4:02
  Then their design gets a promotion and it dies. We can't have that, not for things that lasts for decades.
• 4:11
  A lot of the things in my pictures have the interesting property that they were written ten, 15, 20 years ago.
• 4:17
  They are still being developed and changed. You have to handle that span.
• 4:22
  That's really hard and obviously there's enough in this kind of stuff to talk for days.
• 4:28
  I have one hour. I'd like to point out that the best being the best at one or two things is not sufficient.
• 4:36
  I mean, that's how you can write a really nice paper. I'm nothing against academic papers.
• 4:41
  I read a lot of them. I have written a fair number of them, but that is not the end product for tool.
• 4:47
  Building a tool is good enough if it is good enough for everything that somebody's using it.
• 4:55
  Needs. Now you have to remember that no language is good enough for everybody and for everything.
• 5:02
  But if you should use a chore, it should be good enough.
• 5:06
  At what? At every aspect of what you are doing, not just being the best at something.
• 5:12
  And so let's go back and see what the world was like when when I started photography was mostly black and white.
• 5:20
  Seems that is a large computer.
• 5:25
  It's a PDP 1170. It allows a programmer to have 250 K of memory and it runs with only almost a megahertz.
• 5:37
  Only almost. And this is Dennis Ritchie and Ken Thompson working on it.
• 5:45
  Notice the highly advanced IO system. That was what the world looked like.
• 5:51
  And there's lots of things we didn't have function prototypes.
• 5:55
  I hadn't invented them yet, so I didn't have it. And it was the state of the art in aesthetic development.
• 6:03
  Yes. Lots of languages has functions, document checking and conversion, but C did this all kinds of stuff.
• 6:11
  PDP levels were cool. 90/100. They didn't even have one.
• 6:15
  That's a teletype. One of the points is that everybody knew that object oriented was useless.
• 6:25
  This is almost right because 99% of people didn't know what object oriented was,
• 6:31
  never heard of it, and of the ones that knew about it, knew it wouldn't work.
• 6:35
  It was too slow to spatial purpose and too difficult for ordinary mortals to use.
• 6:41
  And I tried to convince somebody and says, If you want a virtual function, you haven't done your analysis right.
• 6:47
  I mean, you want to call a function. You don't know which one it is.
• 6:52
  It's absurd. So there were some obstacles to overcome.
• 6:57
  I point this out because in retrospect, a lot of this looks trivial and easy, so I probably won't convince you, but it wasn't easy.
• 7:07
  So here's sort of a history chart as it relates to C++.
• 7:12
  Here is a line of development where the purpose of the exercise is to extract every single byte.
• 7:19
  Every single cycle out of the machine starts with a simpler machine code, go through BGP on C and then to C++.
• 7:29
  And up here we have the great improvement in programming, the greatest in history,
• 7:35
  which is basically somebody figured out that we should have human oriented things, application specific.
• 7:43
  Concepts in a language so that we can talk about our programs in the vocabulary we use when we design things,
• 7:51
  as opposed to looking at the machine all the time. That's Fortran.
• 7:54
  And as soon as people had Fortran business people wanted one.
• 7:58
  They got COBOL and everybody wanted one.
• 8:00
  And very soon we had about 20 of them and had the net effect that everybody could write in a specific domain, much more pleasant than assembler.
• 8:11
  However, they couldn't talk to each other. The terminology was different.
• 8:15
  The data formats were different. They couldn't even exchange data.
• 8:20
  So Simula here came about together with object oriented programming as an attempt to say, Why put application specific?
• 8:31
  Concept into a programming language.
• 8:33
  Why don't we instead give the programmers the ability to design their own abstractions, their own concepts, their own types?
• 8:42
  And that's how we got object oriented programming.
• 8:44
  And if you write in any programming language that calls a Type A class, you can say thanks to a question.
• 8:50
  You go there because that's where it came from. Computer science was very new.
• 8:56
  He was trained as a mathematician. He knew what classes was.
• 9:00
  He did not know what types were. And so I needed something that could handle abstraction and could handle hardware.
• 9:07
  And that's why I built C++ by allowing abstraction mechanisms to be used there.
• 9:13
  And lots of interesting things happened after that.
• 9:17
  Now, C++ is, as far as I'm concerned there, so that I don't have to choose between elegance and efficiency.
• 9:26
  When I do things well, they are elegant and efficient.
• 9:30
  That is when you express things really well, really clear, really logically consistent.
• 9:37
  Hopefully the optimiser goes and generates a really good code.
• 9:41
  That's the idea. And sometimes we get it. Don't get it all the time and we can do even better.
• 9:47
  But that's the idea. And we do that by defining lightweight abstractions, not big, heavy, complicated abstractions.
• 9:54
  They are relatively easy, and you can do them in any language.
• 9:57
  But if you want a point and a matrix and a complex number, it gets really quite difficult.
• 10:04
  And that's where the challenges are. And so she has been developed as language for resource constrained applications.
• 10:11
  There's lots of applications that you saw on those pictures and lots of the stuff that I worked on.
• 10:17
  Well, starting in the eighties and still today,
• 10:20
  where you could do much better if you had twice as much memory or twice as many processors or twice as fast processors.
• 10:28
  But you don't. Those server farms cost 60 million USD, and if your code is half the speed of what it should be.
• 10:38
  You need to buy two and you have to power them up and run them and maintain them and all of this kind of stuff.
• 10:44
  So this is where resource constraints matters, and that means C++ is deep,
• 10:50
  deep in our software infrastructure because that's where you have the constraints of performance and reliability and all the other good stuff.
• 11:01
  And C++ offers a direct map to hardware and a zero warhead abstraction.
• 11:06
  Those are those two lines on the history chart. And again, no language is perfect for everything and everybody.
• 11:13
  And I don't know how many of you have have read the Dragon book.
• 11:18
  It's a classical textbook in about how to build compilers.
• 11:22
  It shows the knight armed with the weapons of computer science, defeating the dragon of complexity.
• 11:31
  Sometimes the dragon wins. We haven't reached perfection.
• 11:36
  We can do much better. So here's what I mean by a direct map to hardware.
• 11:41
  The primitive operations map to instructions on the set.
• 11:45
  If you add two integers, it's the integer edge operation.
• 11:49
  Seems simple, but a lot of languages don't do it. Memory is just a sequence of objects.
• 11:58
  You quite often bytes and you have addresses that can show which by the which object you are talking about.
• 12:05
  That's it. It's a brilliantly simple abstraction that any stretch you made you can compose object the simple concatenation.
• 12:13
  Like if you take some of the same type and put them next to each other, you get an array.
• 12:18
  If you put things that are different types together, you can get structs and classes and things like that.
• 12:25
  And if you need to refer to something that's elsewhere, you have pointers that are simply, simply machine addresses and sweet and sour sauce.
• 12:36
  So basically, this is the real secret of C in C++.
• 12:41
  It's really simple. It's really easy to map to the hardware.
• 12:45
  It's compact. It's efficient. Okay, so down by the hardware,
• 12:50
  life is actually rather unpleasant because there's not much help and you don't really want to work with bytes and and words and such all the time and,
• 12:59
  and raw pointers and such. So we want to abstract from it.
• 13:03
  And so the basic idea of C++ is that it should allow you to build your own types, and they should follow what I call the zero or head principle.
• 13:13
  What you don't use, you don't pay people and what you do use.
• 13:16
  You shouldn't be able to encode any better.
• 13:18
  So if I'm providing a notion of a class, you should not be able to hand code it with pointers and structs and stuff like that does anything better.
• 13:30
  And there's lots of examples here. And finally, sometimes we don't actually need to generate any code.
• 13:36
  We just compute the answer at compile time. That's getting more and more popular.
• 13:41
  So here it's abstractions all the way down. We start with our high level abstractions and they build on low level abstractions.
• 13:48
  They build on the language which builds on the on the basic machine model.
• 13:53
  And the machine model is also an abstraction. Of course, there is much more to the machine architecture than that.
• 14:03
  That's caches and all kinds of stuff like that.
• 14:06
  This is an abstraction. This is Dennis's abstraction. It's a good one.
• 14:10
  I borrowed it. And you go down, you get to the hardware.
• 14:14
  And what do you find? No. An entire machine does not execute 86 instructions directly.
• 14:19
  It translated six instructions into a much nicer instruction set, which it can optimise and execute better.
• 14:26
  It's abstractions all the way down into turtles, and you always have to abstract from concrete examples.
• 14:34
  There are people who think abstraction is another word for bloat.
• 14:40
  This is not the case. If you do it right, you abstract from concrete examples, maintaining performance all the way up.
• 14:48
  And you have to keep simple things simple. Because sometimes when you abstract things so that it can do everything, you can do nothing.
• 14:56
  Simply you want simple things to be simple. These are sort of design principles that I've worked with over the years.
• 15:02
  And then there's this question of naming How did C++ get to be core C++?
• 15:07
  Well, there wasn't a language here called CPU. It initially stood for Cambridge programming language,
• 15:13
  then they ran out of money and combined with Imperial and then was combined programming language.
• 15:20
  And then it was too complicated. They couldn't build it and it died, except they built a simple thing.
• 15:26
  And Richards built a similar thing called Basic Spiel we had at M.I.T. actually.
• 15:31
  And then it became B for a short while. And C was Dennis's work that made it efficient and better for poor hardware use.
• 15:38
  And then she ran classes, as it was called, for about three years till I was told I couldn't call it see the classes because
• 15:46
  some people were calling C old C and that was supposed to be rude to Dennis.
• 15:50
  I was not rude to Danish. I had lunch with him most days and never set up.
• 15:56
  We never had a hash word between us and then I tried to call it c,
• 16:01
  c c 84 that never flew because the people from the C committee came and said, Well, please don't do that, John.
• 16:09
  It would really be embarrassing if a superset or C 85, the standard C would be a a a subset of C 85.
• 16:22
  Anyway, they didn't finish till 89, but anyway, that was not so.
• 16:26
  I had a competition for calling it. Something and C++ one.
• 16:32
  As I said, we knew plus plus C was semantically better, but that was too much of a joke.
• 16:38
  So. What is straight you doing up there?
• 16:44
  The answer was he was the main designer of Kpl and it didn't matter Willow's Cambridge or combined because everybody knew it stood for Christopher.
• 16:54
  So that's. You still got it there? Uh oh.
• 16:57
  I should point out that's Maryhill Hill, where I worked and where I designed C++ right over there.
• 17:03
  And that's Cambridge part of it. So what features do C++ offer?
• 17:11
  Well, we had a competition a couple of years ago for what is your favourite C++ feature?
• 17:17
  And when Roger suggests that in Curly, we all backed off, that that can't be beat.
• 17:23
  That's it. That's where all the magic happens. So one of the things that distinguishes C++ over the years is this model.
• 17:32
  You make objects with constructors. And if you don't say anything else in a scope and the end of the scope,
• 17:40
  the destructor fires doing the magic, cleaning up the messes, closing up what should be closed up.
• 17:46
  That that's the really key. And I looked at my notes and it's a real call, C++.
• 17:52
  It came in in the first two weeks of development back in 79, together with classes,
• 17:59
  member functions, information, hiding function declarations and other stuff like that.
• 18:07
  And basically, that is the key to a lot of what we are doing today.
• 18:11
  The standard library uses it. Error handling is depending critically on it.
• 18:16
  So what is it? Here's a type A user defined type A class.
• 18:22
  It has two parts, the public interface and the implementation.
• 18:25
  So basically this is one level of abstraction and that is a low level of abstraction on which it is built.
• 18:31
  And you work that up and down all the way.
• 18:34
  And I have given it this an element type, and it is you can construct this one by a list of initialises of its element type.
• 18:43
  And here is the cleanup function. That's where you release the memory do so.
• 18:48
  Here we can use it. I take a vector of doubles with some well-known constants and I take a vector strings with some well-known language designers.
• 18:56
  I would like to point out I've been using this slide for years.
• 19:00
  I did not put it in to Greenshoe this this is this is this is the way I do it.
• 19:05
  And basically we get to the end, curly, here it goes and cleans up everything that was created by the objects in that scope.
• 19:14
  And that's a very powerful abstraction mechanism. So we use it for just about everything.
• 19:20
  In the C++ standard library, there's vectors, lists, maps, hash tables, strings and such.
• 19:29
  They, they are all working on this model.
• 19:31
  You acquire resources when you when you, when you create a variable and you release it again at the end of the scope.
• 19:40
  And this is these are things that we acquire. It's not just memory.
• 19:44
  There's things like thread handles, file handles, buffer capacities for for streams, locks.
• 19:51
  And when we have smart pointers, we do use counts and things like that.
• 19:55
  This means that if you can't just fire up a garbage collector and collect all the memory, not only would that give you longer resource retention,
• 20:06
  because instead of cleaning up the mess, you leave the mess for somebody else to clean up later.
• 20:11
  Therefore, the resource is held on for much longer.
• 20:15
  Some experiments shows on average twice anyway, and this works recursively.
• 20:20
  So if I have something like a catch it, which holds a five handle and a lock and such, and a vector of records that contains it all works recursively.
• 20:31
  It works all the way. Okay, so let's take a more concrete example.
• 20:38
  Semi concrete, that's a gadget I created with some initialise and I get a pointer out there.
• 20:45
  This is the way we wrote code in the in the eighties.
• 20:51
  This is the way they wrote code and Simula in the sixties.
• 20:54
  There's nothing new here and we've seen too much of it.
• 20:57
  But anyway, this is what we do. We don't actually know what this one does.
• 21:01
  It's constructor grabs all the resources necessary for working well and now it's ready to use.
• 21:08
  And we go down here and if this X is there, we throw something.
• 21:12
  If X is that we return. And when we finished we delete the the the object again.
• 21:20
  I mean we acquire using a new we delete it we release versus using delete.
• 21:28
  However, as you see, sometimes we don't get there.
• 21:32
  So people scream we want garbage collection because this is easy to forget.
• 21:36
  It's easy to get wrong is particularly if we.
• 21:39
  We don't get there. If we return, we don't get there. So there's leaks.
• 21:43
  And so it comes that you don't really want news sitting out there naked and you don't
• 21:49
  want the leaks being there naked because they correlate very strongly with bugs.
• 21:54
  So we want to get rid of it. There's an easy way of getting rid of it is that instead of having the gadget made by New,
• 22:02
  we have a function in the standard library called Make sure it makes an object of that type with that initialise and
• 22:08
  return a SharePoint to a SharePoint as a counter pointer when the last SharePoint as shown object is destroyed.
• 22:16
  The use count has gone to zero. It destroys an object it owned and therefore we will have to get it destroyed there, there and there.
• 22:29
  And the problem goes away.
• 22:31
  Except that now we have SharePoint us and we have use count and this violates the zero head principle because we have to access that use
• 22:43
  count updating and release it in a multi-threaded environment that is actually a costly operation because it has to be synchronised.
• 22:52
  And anyway, I, I don't want to create garbage.
• 22:56
  I can't see any garbage here that needs to be collected.
• 23:00
  I can't see anything there. Require use part. I have one pointer.
• 23:05
  And it goes away. Why do I have to count?
• 23:09
  Zero, one, zero? No, we can do better.
• 23:13
  Actually, the simpler code is there.
• 23:16
  You just take a local variable, control it and you use it, and the destructor would be called there, the end there.
• 23:22
  Because when you go out of scope, the destructor is caught. Problem solved and the code is shorter.
• 23:28
  And so don't use new in general code because they belong in resource management code.
• 23:39
  So if I see a delete in your code, I assume there's a bug that you have too few too many deletes.
• 23:45
  And if I see a new I know you need a delete somewhere, so I assume there's a bug in your code.
• 23:50
  So this is much simpler and if you really need pointers that needs to be counted.
• 23:55
  You don't know about ownership. Yeah, SharePoint is there. It's actually quite useful, but people all use it.
• 24:01
  So this leaves us with one problem that is quite often we make a big object,
• 24:06
  so lots of data and then we wanted to get out of the function that did it, get back to whoever requested it.
• 24:13
  And this is what people use pointers for and they use free store, also known as dynamic memory or heap.
• 24:20
  They used to that and then they send a pointer back and they'll have all the problems back again.
• 24:24
  So we need to avoid that. So here I make the gadget from here, return it.
• 24:29
  And conventionally when we churn something, that's a copy.
• 24:34
  So basically here I call F and here we copy the and the G out to g g.
• 24:42
  Now, I must point out that only a computer scientist could have thought of that.
• 24:46
  So to get this one from here to there, you make a copy.
• 24:51
  Over the end, you destroy your original. No baby.
• 24:56
  About 4 to 6 months old. No. Here it is.
• 24:59
  Now it's over there. Now it's back again. They can figure it out.
• 25:03
  So we just have to make sure that that's what we do. So here is G.
• 25:07
  It's a gadget. And if it's a big thing, like a matrix, a vector, a collection of stuff,
• 25:14
  if the stuff will be over here somewhere on the on the free store and this is a handle to it.
• 25:20
  So all we need to do is to copy the handle into g, g and the handle is this more?
• 25:26
  If this was a matrix, it would probably be two words. If it's a vector, it's three words.
• 25:31
  And then we cut the connection to the first gadget so the destructor doesn't get to throw away the good stuff and problem solved.
• 25:39
  And so the cost of getting a megabyte of stuff out if you do it like this is, well,
• 25:47
  2 to 4 memory assignments and now you no longer have to worry about pointers and memory management or share pointers and all of this stuff.
• 25:57
  This completes the control of the lifecycle of, of, of, of objects.
• 26:03
  Now, some of us have been doing this since the nineties, but it's only became systematic and guaranteed that it could be done in.
• 26:13
  The and C++ 11. This is the handiwork of a guy called Howard Hint that found out how to to formalise that so that's easily done now.
• 26:25
  Also, I'd like to talk about evolution to point out that I have never claimed C++ is an object oriented language.
• 26:33
  It never was just an object oriented language is never meant to be just an object oriented language.
• 26:39
  I don't think everything should be in class hierarchies or any of that stuff.
• 26:44
  So she prefers not object oriented, is just object oriented for any definition of object oriented.
• 26:51
  For starters, we need to deal with this direct mapping to hardware when hardware tends to be messy.
• 26:57
  So we have to do things that that doesn't behave like objects in a real way.
• 27:02
  They actually real world objects. And you have to obey their curious and somewhat perverse semantics.
• 27:11
  So we deal with this. Furthermore, we want value semantics for some things.
• 27:16
  So A, B, A becomes B means that they have the same value and modification of the one doesn't fix the other.
• 27:24
  This is what we do for integers, for complex numbers, for points, for vectors, etc.
• 27:29
  So that's that, that's that model has always been in C++ and it's one of the things we do.
• 27:35
  Also, I want to say square root of two, not two dot squared.
• 27:41
  I really think this is the nicest notation. This is the nicest notation and such.
• 27:45
  And I don't want to have two versions of a of things.
• 27:49
  If I, if I add a floating point number to an integer.
• 27:54
  I don't want the integer class to have something that takes floating point numbers
• 27:59
  and the floating point number in class takes something that takes integers.
• 28:02
  I want the old fashioned 300 years old notations that furthermore, generic programming was always part of the C++ plan.
• 28:13
  So that's doesn't fit with the object oriented thing.
• 28:19
  So these days, the control of C++ is by an ISO standard committee.
• 28:26
  And the way that happened was that representatives from HP and Sun turned up
• 28:32
  in my office and explained to me that I wanted to standardise C++ with ISO.
• 28:39
  And I said, Well, it's not ready, it's not finished, it's through a project.
• 28:42
  And they sort of twisted my arm out and in the end I said yes.
• 28:47
  The argument was that you could not have a language, major language, supported by controlled by a single company.
• 28:57
  Everybody believed that in those days it has been proven untrue.
• 29:01
  People are using Java and C-sharp, even though they are owned and operated by an individual company that might be your competitor.
• 29:10
  Anyway, at the time, nobody believes that could be done. They had not thought about the advertising campaigns that could do it.
• 29:16
  And the other argument was rather blunt Well, we will not trust you as your employer, and we will, of course, trust you.
• 29:29
  But you could get run over by a bus. End of quote.
• 29:34
  So I agree to standardisation. There's many kinds of standardisation and the ISO standardisation here is sort of the gold standard of standardisation.
• 29:44
  It's thorough, it's open, and they have some rules.
• 29:47
  And so we get long term stability, which is a feature, an important feature to many of the major users.
• 29:54
  It's vendor neutral. It's really hard to sort of jargon or the C++ definition so that it favours my company rather than yours and such.
• 30:03
  And danger is designed by a committee is horrible.
• 30:07
  Stagnation could happen if people decided not to do major things because they couldn't agree on which major things to do.
• 30:15
  There is divergent direction of design.
• 30:18
  If you get sufficient number of people, they can't agree on anything and they have a tendency of or elaborating any individual feature.
• 30:25
  You can see that in C++ in places. I'm not going to go into detail.
• 30:30
  I'm just going to show you the picture of the committee. So this is what it looked like.
• 30:36
  Then it became set. Then it became that. And this was earlier this year.
• 30:44
  How do you get that group of people to agree of anything?
• 30:48
  They come from different countries. Different industries, have different philosophies, have different education.
• 30:54
  This is really, really hard. And I, I reckon this is a picture of my major problem with C++ today.
• 31:02
  It is amazing that we have succeeded as far as we do.
• 31:06
  But let's see. I'm going to talk the rest of time how we got from well about there till 20 years from now to three years from now.
• 31:16
  So that's evolution. We got a new standard in 11.
• 31:20
  The first one was in 98, then 14 and 17 C++ level was a major improvement.
• 31:28
  This was what we had learnt over the previous decade and a bit.
• 31:32
  Standards usually come every ten years. We actually took 13, which was one of the reasons we decided we can't keep on doing this.
• 31:39
  So we decided we were going to go on a three year cycle and actually deliver what we had to deliver.
• 31:48
  There's lots of new features in 11, lots of simplification.
• 31:51
  One of the ways I'm working is that there's a language we can't take things away because of stability.
• 31:57
  How can you make it simpler to use?
• 31:59
  And the answer is have features that are simpler to use than the general ones and then have rules for how to use them.
• 32:09
  Well, now people say, why don't you just throw away the old stuff?
• 32:13
  Well, half of the pictures I had in the first two slides were break.
• 32:17
  And people everybody wants two more features. And by the way, the language is too big.
• 32:23
  You should make it smaller and don't break my code.
• 32:28
  These are the sort of the hard constraints on evolution and we have technical specifications and such.
• 32:36
  Now we have three major implementation implementers of C++ playing Jesus, C and Microsoft.
• 32:45
  And by the way, they shipped essentially all of C++ 17 this year.
• 32:53
  And the standard hasn't been signed off in Geneva yet.
• 32:57
  The technical guys have done it and the technical guys have delivered the compilers.
• 33:02
  A lot of you will be using them already. We are delivering on time.
• 33:06
  This is spectacular. I mean, remember, we deliver on time.
• 33:13
  Not as much as I would like, but we delivered. So C++, 11, ten years of experience.
• 33:19
  Long list. You can look up the list. Wikipedia has some CGP references, lots of places.
• 33:25
  I am not going to go into details. Going through the slide in any detail will take a day.
• 33:31
  So we're not going to do that. I'm just going to show one example here of C++ 11.
• 33:37
  So here I'm going to say the old problem in a container C I want to find all the elements that has the value.
• 33:44
  V And what I'm going to do is I'm going to return a point of each of those elements.
• 33:51
  And let's see an example here we have a string. A string is container of characters.
• 33:56
  Mary had a little lamb here. And so for each pointer that comes out of find our as a result by giving it M and looking for the A's,
• 34:06
  I'm going to see if the pointer really points to A if it doesn't do something seriously wrong.
• 34:12
  Okay. So, so in other words, I want this to test whether that wasn't me.
• 34:17
  That was me. That was me and that was me. The way we do it is we start a vector of pointers to elements.
• 34:27
  In this case, the value type of C is character char and for each X in C sees the values, right?
• 34:37
  If it is, push the pointer to the end of the result vector and return the vector.
• 34:44
  Now, if this had been a C++ 98 program, we would have had a serious performance bug there because I mean,
• 34:53
  a vector for elements is not that expensive to to pass.
• 34:58
  However, I might have given it a megabyte of data and returned a million pointers and even modern hardware can feel copying a million pointers.
• 35:07
  However, modern vectors do not copy.
• 35:13
  They move. So that is dirt cheap. So the difference between C++ 11 and C++ 98, here is what you don't see.
• 35:23
  You don't see any pointers. You don't see any locations.
• 35:26
  You don't see any range checks. It's all gone away.
• 35:30
  It's done implicitly in places, and it's done efficiently.
• 35:35
  So that's what's different. So for 14, we finished 11.
• 35:40
  So the point here is that when you have a large project before the end of the project, before the shipping date, you have a feature freeze.
• 35:48
  And while the feature freeze happens, you learn things and you can't do anything about it.
• 35:54
  So for us, the end of the feature freeze is about a year before you ship the standards.
• 35:59
  After having a major release, you start using it and you learn things you hadn't guessed.
• 36:06
  You do. And so the idea is after three years we have had the feature freeze.
• 36:12
  We have learned what the effect of the the use of the features are, and we can fix it in time before the next feature each.
• 36:21
  And that's how we got C++ 14. It completes 11.
• 36:25
  That was all planned and it has lots of little things.
• 36:29
  There's this year, for instance, the graphical people really wanted binary constants, so we gave them binary constants.
• 36:38
  The OBI means it's a, it's a bit pattern.
• 36:43
  Then we found that people can't read this stuff and you see what that is.
• 36:48
  Okay. Then we gave people digit separators which are just for the humans reading the code.
• 36:55
  We're always interested in things that simplify things by making bugs more, less likely.
• 37:00
  And that's what this does. Lots of things here. Remember, we are still maintaining compatibility and stability.
• 37:06
  Yes, we would like to get rid of some of the old crud, but we can't.
• 37:10
  We've tried. So one of the things we've been doing in the Lake Framework, we had a lot of requests for being able to do more at compile time.
• 37:23
  So a lot of people do the following.
• 37:27
  They have some code and they need a value in there.
• 37:30
  So they go to a tool to pat on the side and they calculate it, or they use the calculator and they get a value and they put it into their code.
• 37:38
  Then you wait a couple of years and it's now the wrong value and you have a magic cast in your code and you have bugs.
• 37:45
  So we had requests potentially from the embedded systems industry for doing better things at compile time.
• 37:50
  They also sometimes want to put constants into run, and C++ wasn't good enough for that.
• 37:56
  Actually, I think it was, but they didn't agree. So here is an example.
• 38:02
  Somebody in the Japanese embedded embedded systems industry wanted an integer square root function to be executed at compile time.
• 38:11
  So when we do that, we say that we want to have it so that it can be calculated at compile time.
• 38:18
  Then we write the simplest algorithm we can find. This will be executed at compile time.
• 38:23
  The compiler executes it to be able to do this trick.
• 38:28
  The function has to be pure in the sense that it cannot have side effects and it cannot operate on any data that is in its arguments.
• 38:37
  If somebody likes nice mathematical functions, just just require their context.
• 38:41
  But that takes care of that problem. Furthermore, it allows the compiler to squirrel away the information necessary to do this.
• 38:50
  And if it did, if for every function you couldn't compile a really big program.
• 38:55
  So it's important that we have to say it. So we can now take the square root of nine and take it square with a one, two, three, four.
• 39:03
  And we don't have to use a do pattern.
• 39:06
  We don't have to do strange things with macros to do it. Now C++ supposed to do the basic stuff and then to handle abstractions.
• 39:14
  So let's see, we can do compiler time abstractions. Here's a little abstraction.
• 39:19
  It's a weekday of June 21st, 2016.
• 39:23
  This is an example of use of my favourite data library.
• 39:27
  This is is very nice. And it writes Tuesday.
• 39:31
  We can do that at compile time. Let's take a static assert, which is an assert that is evaluated at compile time to see if it works.
• 39:39
  So I'm saying that the weekday of June, the 21st, 2016 is a Tuesday.
• 39:46
  And it is. So this assertion does not fire.
• 39:50
  But if if I had been wrong, it would have given me a compile time era so we can actually do nontrivial computations at compile time.
• 39:59
  By the way, this library is more efficient than anything else you've done for data.
• 40:03
  So it's not this has not become elegant by being inefficient.
• 40:08
  So 17 should have been a major release. The idea was to pick up the intel idea of tick tock, tick tock, major release minorities made enemies.
• 40:17
  And C++ isn't 17 isn't. So if you hear me grumbling about the standards committee and slow rate of evolution of C++ and the many little features.
• 40:30
  This is what I mean. This should have been great. It's only okay.
• 40:34
  That is a little bit for everybody.
• 40:38
  I think everybody will find something they like. The problem is that there are.
• 40:45
  Maybe 80 different features. And if you like two of them, you still might have to understand the other.
• 40:52
  The rest of them.
• 40:53
  There's a nice parallelism library that's a variable type that's useful, some way of dealing with with with marginal return values and such.
• 41:03
  This this is good. This good. But it's not great. So let's see, where do we go from here?
• 41:09
  And we need a guiding philosophy for kind of this.
• 41:12
  We can't just say, is this feature good?
• 41:15
  Let's take it. Is this feature good? No, let's not take it. What are the criteria?
• 41:20
  What are the direction for where we are going?
• 41:23
  So basically my aims include complete type and resource safety as fast or faster than anything else, good on modern hardware,
• 41:31
  whatever modern hardware is going to become, and significantly faster compilation even though we are doing better checking.
• 41:40
  I don't think that's a modesty it and basically dream no little dreams.
• 41:47
  That's his slogan. And the best is the enemy of good.
• 41:50
  That's his slogan. I can't just dream. We're going to build something.
• 41:54
  It's going to be useful. I want this to be useful in 2020 and I want the prototypes to be usable next year.
• 42:03
  So we're going to do that. That's an engineer, right? So make C++ a much better tool for building demanding applications.
• 42:10
  That is the ultimate aim. And these are the sort of more specific aims.
• 42:15
  The challenge is I try to set the committee with the science.
• 42:20
  So my philosophy is a lot of what philosophy philosophers are anyway.
• 42:25
  So it is actually the only way of maintaining our direction and to have a coherent language.
• 42:31
  This is absolutely essential and it's more a language is more than a collection of features and individual
• 42:38
  feature can be great and just be a distraction in the context of a tape system and all the features.
• 42:44
  We must do better. We must have a balance of features and basically we don't want to have a habit and the design rules are mostly non-technical,
• 42:54
  and this is where it's hard to get through to the geeks.
• 42:57
  I actually wrote up some design criteria in the early days, and here's from a book I wrote about it The Design Evolution of C++.
• 43:04
  If you want to know about the early evolution of C++, you can read that book.
• 43:08
  And I wrote two papers for the History of Programming Languages Conference, which you'll find on my publication page that also describes evolution.
• 43:17
  It's all of these features I'm skipping over fast here because I only got an hour, but basically.
• 43:24
  Drive by real problems. I think theory is great for solving a problem once you have decided that it needs to be solved.
• 43:33
  I think theory is a lousy guide to what should be done and so don't have a stripe quest for perfection.
• 43:41
  If I can come up with a 99% solution, I'm not going to wait two years, three years, a decade for the last percent.
• 43:50
  And so there's things like this. You can read this for details.
• 43:54
  And I'd like to point out two of the things documented in 94.
• 43:59
  And actually, you could probably document them for for AG for all before no implicit violation of aesthetic type system.
• 44:10
  Now, this surprises people who I used to see and such and even parts of C++.
• 44:15
  But there's a difference between ideals and what you can get.
• 44:20
  I'm going to get this one sooner or later, but I haven't got to get any straight, she said.
• 44:26
  C++ is a strongly type programming language with weak enforcement very weak.
• 44:34
  But the underlying system is the same, except possibly for some conversions that go both ways.
• 44:40
  And anyway, I really want to eliminate the pre-processor.
• 44:45
  So still trying to do that is really hard. There's people got a million lines of code and says, You're telling me to get rid of the macros?
• 44:54
  Yeah, I'm telling you to get rid of the macros. And they, they, they, they laugh.
• 44:58
  But I actually think we're going to get rid of the macros in something like the Windows kernel.
• 45:06
  It's probably the worst macro [INAUDIBLE] on earth and that is why they have decided they
• 45:11
  actually agree with me because that [INAUDIBLE] is what they have been living in for a while.
• 45:16
  We are going to make progress. But remember this was early things. We are still working on it.
• 45:21
  So what do we want? I want a major release in 20.
• 45:24
  C++ 20. I want my definition of major.
• 45:28
  Is it something that changes the way you think about programming, the way you think about building systems?
• 45:33
  That's the definition of major. Minor is everything else.
• 45:37
  And what can we get? I like science fiction, but I don't like to talk science fiction.
• 45:44
  Everything on this slide actually has been implemented somewhere.
• 45:51
  So it's all very mired science fiction. And by the way, that is a show of slides.
• 45:57
  I really was very I thought it was very cool when I learned that Douglas Adams were programming in C++.
• 46:05
  And so this this this this video game was written in C++.
• 46:09
  So I want concepts, which basically is constraint generics.
• 46:14
  I want modules faster and more hygienic compilations, code change contract.
• 46:22
  I didn't know if, but when I wrote the slide, but last week I was told that the implementation has started in a university in Spain.
• 46:33
  Static reflection there's a problem. We have three designs, three with implementations.
• 46:41
  And now you have to have the community to decide which one to have.
• 46:44
  And I really, really want them not to have the union of those three designs.
• 46:50
  So that's that's what that question mark was for networking.
• 46:53
  We have a really nice networking library close to optimal in many ways in widespread production use, better parallel algorithms, better futures.
• 47:02
  We have the model of promises and futures for for sending information from
• 47:07
  one thread to another without having explicit locking and all of that stuff.
• 47:13
  We have it and it should be much better because there are some design errors in the C++ 11
• 47:18
  design and I want a new standard library with the concepts here so that we get proper teaching.
• 47:26
  Let's see how we do it.
• 47:30
  If you go back and look at my very early papers from 81 or thereabouts, you'll see I want an object oriented programming as pioneered by Simula,
• 47:39
  and I want that generic programming because basically I wanted a vector of cheese, which was something I could specify.
• 47:48
  As a parameter. And once you have vectors of cheese, you want a sort of cheese.
• 47:55
  What sort of victim of cheese? Where you have parameters for data structures, you have parameters for algorithms, for functions you need both.
• 48:03
  Okay. So I conjectured that you could use macros for that.
• 48:08
  That did not scale. Macros for generics.
• 48:12
  It works for about two people and not much more, and it's one maintainable.
• 48:18
  So in 87 I made a design of templates.
• 48:21
  I wanted extremely general and flexible. I always want that.
• 48:25
  I want zero overhead. I always want that.
• 48:28
  So basically, I wanted something that could do more than I imagined and could compete with crazy and other basic facilities there.
• 48:37
  And of course, I wanted well defined specify well specified interfaces because that's good and that's what we always want.
• 48:44
  And two out of three ain't bad. I could not do that.
• 48:49
  I don't think anybody in the Middle Ages could do all three.
• 48:54
  If you look at all the languages that has things like that, they don't have all three.
• 48:59
  So we can now do it. The way we do it is let's see.
• 49:05
  The problem was that we got compile time duck typing and it gets very, very complicated and horrendous error messages you get wrong.
• 49:14
  And it was very, very successful because of its nice features, flexibility, performance, etc.
• 49:20
  We are trying to attract address this complexity by providing context for functions, functions that can be evaluated a compiler time.
• 49:29
  So we do made a programming that is not to implement a programming.
• 49:32
  If the result of a compile time computation is a value like seven, you want to call a function to get it.
• 49:40
  And we want to specify interfaces. So here is an example of something using concept.
• 49:46
  I want to sort something and I want to sort anything that's sortable this there's a
• 49:50
  definition of what sortable somewhere you can look it up in the menu in the standard.
• 49:55
  It's something that has is a sequence with a beginning and the end.
• 49:58
  And it has elements. It has a lesson operator.
• 50:02
  And it has random access to the elements.
• 50:05
  That's it. So anyway, if I have one of those, I can sort it as it happens in the standard.
• 50:12
  You can't sort a list this way because the list doesn't have random access to which elements.
• 50:18
  So the way you do it is you just copy the list into a vector sorted and copy it back again.
• 50:25
  That's usually the most efficient way of, of, of, of doing a sort of a list.
• 50:31
  Now I can then say sort of actor and it says those make time.
• 50:36
  All the properties required for should be sortable.
• 50:39
  Yep. So we can call it. We can sort the list.
• 50:43
  Does the list have all the properties that is required to be sortable?
• 50:48
  No. Let's try this one. And the answer is yes.
• 50:51
  And we just do it. And notice I am not saying that a sequence is less than sortable or something like that.
• 50:58
  I'm just trying to see what works. And this is very simple over all loading rule.
• 51:03
  If you match one thing, that's it. If you matched two things.
• 51:07
  If the one is a subset of the other, you pick the largest end of rules.
• 51:13
  So that works nicely, and you can specify your requirements like this.
• 51:18
  A sequence. It requires that the type has an iterator that has a beginning and the end they have an iterator and
• 51:24
  those generators are actually iterator is not just called generators in the story and concepts.
• 51:31
  Sortable means that it's a sequence with random access with the order of value type.
• 51:36
  I was just what I said this is of English so that that works by the way it's shipping in adjacency six point and higher or to seven.
• 51:48
  So this is not really science fiction modules is another thing we're working on.
• 51:54
  Compilation just takes too long. C++, we have to include model.
• 51:58
  It includes all the text, you get a whole lot of text, then the compiler deals with it.
• 52:03
  Compilers are superb at compiling a lot of text, but it still takes forever.
• 52:09
  So we want to do better. We want to define modules here.
• 52:13
  I'm defining a module called the map and. And the map printer.
• 52:17
  To implement that I need airstreams, i need containers and I want to use namespace city.
• 52:24
  Notice I'm saying import not uh, what you call to include and these export something.
• 52:32
  The idea is that when you include you get what is exported and the module itself is a semi compiled construct that is self-contained,
• 52:43
  semi compiled once and then expanded where necessary and that is very significantly faster than includes.
• 52:52
  I have seen real live examples that compiles ten times faster.
• 52:56
  So we're going four factors here. If I get five times, I will be happy.
• 53:01
  If I get ten times, I'll get even happier. If you give me 40%, I'll be sad.
• 53:08
  This is this is ambitious. And so here I am going to export a template that prints maps.
• 53:15
  It takes a sequence, and the sequence has to have printable value type, the key types and a printable value type.
• 53:24
  And then I do for all key value appears in print them out.
• 53:30
  Now I want this to work. And she proposed 20. This works today.
• 53:34
  It's called Structured Bindings. It's part of C++ 17.
• 53:39
  This works in the Microsoft implementation, and the concept works in TCC.
• 53:46
  When I first wrote this slide, this worked only in plan and see why I want a standard.
• 53:52
  I want all three in all platforms I'm using standards are really useful.
• 53:58
  So how do we go through to evolve? The language is getting bigger and more complicated and the users are more busy than ever.
• 54:06
  So what I want to do is to answer the question, How would you like your code to look like in five years time?
• 54:12
  And if you think very much like today, I think you're on ambitious.
• 54:16
  You should we can do much better.
• 54:18
  So I'm doing it tagging with a sort of a drug cocktail through language design, coding rules, a library and some static analysis.
• 54:26
  And I'm after type and resource safety and I want to eliminate all complex techniques
• 54:31
  by analysing complexity and throwing things out if they correlate with bugs.
• 54:37
  And so basically, this is the Holy Grail I'm after.
• 54:41
  There's a project called the C++ Core Guidelines, which is a joint project.
• 54:46
  You can find the current guidelines on GitHub.
• 54:50
  It's a joint project between Morgan Stanley, Microsoft.
• 54:55
  Red Hat, Facebook and a lot of others, which you can look up in the contribution list on GitHub.
• 55:01
  I encourage you to note Microsoft and Red Hat.
• 55:06
  There's not many joint projects between those two organisations.
• 55:10
  I think we have seen progress here anyway.
• 55:13
  So what I want. It uses the guidelines and then has a small support library.
• 55:19
  By small I mean about a dozen abstraction, similar ones.
• 55:22
  And I want static analysis that is work in progress so I can write type and resource safe C++,
• 55:29
  but I want it guaranteed and we are working on those guarantees.
• 55:33
  But basically no leaks, no memory corruption, no garbage collector by the simple trick of not having any garbage, no limitations on express ability.
• 55:44
  I don't want things safe by making sure you don't say anything interesting.
• 55:49
  We need still C++, no performance degradation, so we can't just test things at runtime.
• 55:56
  Still ISO C++. I don't want to design a new programming language.
• 56:00
  It takes forever to build. It takes forever to get deployed.
• 56:05
  Basically, the minimum penalty for designing a programming language that works is ten years of manual labour,
• 56:13
  meaning you have to work on the manual for ten years. And I wanted to enforce it.
• 56:21
  And so basically, I want to get rid of code like this here is innocent looking quote unquote with a delete in it.
• 56:27
  There's a new Aquila function and I use it. This is disaster.
• 56:32
  Because by the time you get down there, the object doesn't exist anymore.
• 56:37
  So this one either reads some memory, which is not the object.
• 56:40
  That is just the point I used to point to. It may actually write your favourite data structure and you have the most mysterious bugs you get.
• 56:48
  The problem with dangling pointers in their use is you can't see them.
• 56:53
  That's why I chose this picture of a nightmare. Never let a point out lived object is point to easy to see how to scale.
• 57:00
  I mean, density said it's been there forever.
• 57:04
  Okay, so once you get rid of that one, that's all about unions cost.
• 57:10
  Not a point of view references. We can do all of that.
• 57:14
  This, this this monster is less dangerous. You can see him and you can drain.
• 57:19
  Drain his pond and your home. Okay.
• 57:25
  Just to show this is not science fiction. There is a printout from the from from Visual Studio last year.
• 57:32
  I have a track there that contains two pointers.
• 57:36
  I make one of them here and the other the analyser objects because I'm throwing away the information that there was a new once it's up here,
• 57:47
  the information is gone. Therefore, we have a potential leak and it will not like it.
• 57:52
  So we are deploying this kind of stuff now and basically there's a lot of challenges left.
• 57:58
  I didn't say C++ was a perfect language. Never have. I doubt I ever will.
• 58:03
  There's lots of challenges left. The world is changing.
• 58:07
  We must do better. I mean, our civilisation depends on.
• 58:13
  Software. I mean, if if our software really broke, we will end up starving.
• 58:20
  This is not an exaggeration. It's it's we have to do better than what we are doing.
• 58:25
  And it has to be done on an industrial scale. And staying coherent is hard.
• 58:32
  And so I reached my my limit here. And we have time for a few questions.