CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and Future"

I was thinking about what I was going to talk about at this conference as a key note speaker. And I looked at the program, and decided that there was an awful lot of nice, good, detail stuff. Language things, library stuff and such, so I shouldn't do that. So, I am trying to talk about something more general, bigger ideas, and so I'm talking about the evolution. And I'm trying to look back and see why on earth does this happen? I mean C++ has been declared dead at least ten times every year, for the last about 35, right? So, let's look at it and why it didn't die in the crib, or after that. And then, I'm going to look a little bit about standardization and see what are the opportunities and the dangers now. And then, I'm going to try and answer the question, where are we going? Where should we be going? How can we sustain what we have been doing so far and make it better? And then, this gets too philosophical, right? Then I have some concrete stuff about what we can do today, and that's how I'm going to end. But first we start with philosophy. There's a couple of philosophers, and there's a tension between ideas, and principles, and practicalities. And this has been going on for at least 2,500 years and it hasn't stopped yet. But this is one of the tensions that we're going to talk about. And I am not going to give you long lists of features, other people will be doing this, you don't have to, if that's what you want you'll get it. And I can't give you really cool stuff, go to the people at ship libraries and such, and talk to some of the compile inventors. Cool stuff is shipping, it's just not what I'm talking about. And then, again, going back, why did C++ succeed? What can we do? And I've heard many theories, my least favorite is being lucky. How do you stay lucky for 35 years? It takes hard work. And furthermore, yeah, one thing to point out, when I talk about C++, I'm taking a very C++ centric view. I could give a totally different talk about the industry, and where C++ fit, and all of that kind of stuff. That's not what I'm doing, I'm very C++ centric. If you want to criticize me for it, fine, but remember I know that too, and this is just lack of time. Okay, so let's look at philosophers. Here's a good, dream no little dreams. In other words, what are we really trying to do? What's a big picture? What is the thing that sustains us, sustains C++ over decades, as opposed to days, weeks, months, years? Basically, my aim, and I hope many other aims are, simply to do things much better. And to do things much better in software development you have to think differently, you have to construct your code differently. Just doing what we've always done, but slightly better, it's not going to get us there. It's going to get us the next project shipped, it's going to get us to the next year, but it's not going to sustain the language and the community for decades. So, I would like type and resource safe, without any adjectives or other worries. I want the code, I have to read, to be simpler and clearer, easier to understand. This is important, I mean that's what you spent most of our time doing it. You should be looking at code that isn't finished or has bugs in it, and clarity, simplicity is really, really valid and the language in the libraries can help there. That's what we want to do. And of course this C++ has to be as fast as faster, than anything else. If you want slow code, you can get it, there's benefits sometimes to have slow code. You can have tools that allow you to write it sooner and such. But anyway, as fast and simpler than anything else, and it has to be good at modern hardware. One of the strengths of C++, as I'll repeat a few times here, is it actually has mapped really nicely to hardware. Hardware is getting weirder. There are more pipelines, there's more forms of concurrency, there's more strangeness inside the compilers and optimizers. C++ is supposed to be good at that stuff, let's keep it being good at that stuff. And then, compile times, nobody really like long compile times, let's get much faster about this. And remember, in these things I'm not talking percent. If you give me 10% I'll be very unhappy, if you give me ten times, I'll get happy. But that's not easy, here we have an expert on difficulties, Niccolò Machiavelli, the famous historian of the Roman Republic, patriot, and politician. There's nothing more difficult to carry out, nor more doubtful of success, no more dangerous to handle, than to initiate a new order of things. In other words, don't rock the boat, it's dangerous for you. Don't try and make things that are really new, don't try and make things that are significantly different. And if you look at this, and of course that is what I'm trying to do, it's also what Machiavelli was trying to do. He wrote a book trying to convince people to do it, and people convinced that he was wrong because he explains things the way they were, as opposed to the things that people pretended they were. I quoted that in the third edition, and here's a continuation, the problem is it's dangerous because you make enemies of everybody who loves status quo. And people who would like something new tend to be lukewarm, because it isn't there yet. They can't use it on their next project, they can't use it next year, and so there's an imbalance here. And so, my conclusion is, developers love minor changes that helps with current problems. And they don't really, people had a vested interest in the status quo stronger, okay. Then also remember, the best is the enemy of the good. We can't just sit around and wait for perfection. No, that doesn't get us to perfection, for starters, we don't learn anything. There's no feedback loops in trying to perfect, you have to move further. So, we're going to talk a little bit about what concrete practical steps we can take now, that's the last quarter of the talk. And then, of course, we can't do it alone, and I'll point out that a lot of people have helped. There's just a few names there, if I had put everybody who needed thanks on this slide, I would have to use an 8 point font, and you couldn't have seen a single name. There's always these tradeoffs. Okay, let's look at C++, here's a graph, some of the numbers are real, but it's hard to get numbers. In particular, the bottom and the top and some of the flex points are real. What I had to do is some interpellation, especially around the 2002 plus minus column, the rest is pretty good. So let's see, I mean, we had a commercial released in 85. That's a long time ago, why did we have exponential growth? I measured it as doubling every 7.5 months for 11 years, and then I couldn't count that high anymore. Numbers got too big, my sources were not good enough, and then obviously, there was a slowdown. And we've got a really serious slowdown just after 2000, and then it resumed. I mean, we have pretty good numbers for the last three, four, five years, and there's no doubt we're on an upward curve. So, if I can explain this slide, I can actually get some guidance about what we should do to sustain it. What people would like, what would actually help people, so let's go back to the roots. Where does C++ come from? Some of you may have seen this slide, the past doesn't change very often, and so there are two sources of C++'s strength. The bottomline there starts with, try and squeeze every cycle, every bite out of the hardware. It starts with assembler, David Wheeler there is one of first people who claimed to have built a compiler. He certainly wrote the very first program on a slow program computer. And he was my thesis advisor, so he gave me a lot of information. BCPL, C we know about that, and. The problem is, that most of the time we're not actually manipulating hardware. Some of us are, and C and C++ is good at it, should be good at it, it's designed to be. But there's another line of thought here which is abstraction. Back us there, and his team invented Fortran, which was the most significant improvement in programming sofa, they lifted the language from the hardware up to something that was more suitable for humans. Very particular kinds of humans, engineers and scientists, but they had a language that then could be mapped to different computers, and you can get portability and all kinds of good things. They didn't mean to, they just meant to give a language that would be good for scientists and engineers. But once scientists and engineers have got it, everybody wanted one too. So, you've got 200 more languages that specialize for different things, Cobol for business people and such. And now, he had a filthy mess. 200 languages, and they couldn't talk together. You want to gather some data? You put it on a record. Cobol's really good at that. Then you want to run some statistical analysis on it? Fortran is really good at that. Fortran doesn't speak to Cobol. And there's many particular solutions to that kind of problems. But the general solution came with and Simula. Object oriented programming. Basically, instead of giving people an abstraction that's suitable for a particular kind of user, you have a generalization, so that you can build your own types. Your own class hierarchies, if you have related types. And that's a brilliant idea. And so, when I had a problem at Bell Labs, I said, why can't I have both? I want to use every ounce of the hardware, but I want to abstract away from it when I don't have to be bothered with it. And that's the true root of C++, and the first feature coming into it was classes, with constructors and destructors, and things like that. And a lot of things come from there. So, there are the two intellectual roots of C++, which I suggest it's a good idea to stick to. So, C++ in two lines. Not 1300 or 1400 pages, but if you really want to get the basic of it, that's where it is. Direct map to hardware came originally from C, and for future, we need facilities for dealing with the hardware that's now coming out. We can't just program against a 1990s computers, which is what we do when you misuse a current computer, and we need zero-overhead abstraction. We need to abstract, but I don't want to pay for it. Simula showed us the value of abstraction. Where I came in is I wanted it at no cost. And that's where you get, you get this from classes, you get an inheritance, you get a generic programming with templates and such, and for the future, I want type and resource safety with concepts, modules, and better concurrency support. So, that's C++ in two lines, and let's get a little bit concrete. You have to choose your level of distraction when you deal with C++. Here's a very trivial symbol example. I want to read some strings into a lecture. I can do it on the top, I can do it at the bottom. There wasn't room for the all flow checks, so sorry. I'm having two slides on, two examples on one slide. To give an example, I would prefer the top, and I'll prefer the top to run at least as fast as the bottom. For many, many application areas, that is possible. So, you can start with what you can do, and then you can improve it. And the aim should be that the higher level, the clearer, the type safe thing where you don't have to worry too much about the overflow and things like that. The distinction is fluid, you have a choice, but I would like to push people toward a more elegant solution. You also have to ask what matters. A lot of the things we talk about don't actually matter in the big picture. For software development, first of all, that's what matters, not who can have the cutest little example in an article. What actually matters for actually building things? Stability, important. There's a lot of 20 year old code out there, and evolution, there's a lot of new problems coming on, we must do that. We have tool chains, we have teaching and learning. There's lots of people, I get mail every week from people asking questions that relates only to Turbo C++ 4.0. This is sad. We have to improve teaching and learning. I always mention that, and it's really hard, there's so much inertia out there. There has to be a technical community, none of us write a program in isolation. We depend on the advice of others, the support of others, the tools from others, the ideas from others. We have to build that community, this conferences is part of that. I want concise expression of ideas. I actually want to be able to read your code and vice versa. If it's a mess of bits and bytes, often I can't. Coherent language, complete language, compact data structures that are out of date, lots of libraries. These are the things that are important, as opposed to language technique, or little details that also has to be right, but they have to support this. And one of the important thing to make note is that there at the bottom, a language must be good enough for everything you're doing in your project. If it totally fails at one thing, it totally fails. So, being the world's best at one or two things is not sufficient. You have to be really good at some things, preferably lots of things, but you mustn't totally fail anywhere. So, that's good. And it's really hard to do because you don't know what's important to people. There's far too many people to know what they want and what they need. I mean, we got 4.4, 4.5 million C++ programmers I mean, even if I was a mind reader, I couldn't read that many minds. So, this is difficult. But don't get obsessed with details. There are times to be obsessed with details when you finish one little corner of a project. But sometimes, you have to look at the picture. So, a language needs good fundamental features. That's important. And a good language is not just a set of good features. You have to have them fit together, and all framework has to be comprehensible and effective. You have to be able to use language features in a combination. You have to be able to have real compilers, generate good code from them, and things like that. And 90% of the work of getting something new into a language is integration. People always come, they sent this email, put this into C++, it's cool. Even if it is cool, even if I agree. Well, the first 10% is to write the proposal. And the next 90% is to figure out where it was wrong, and why it didn't fit in, and get everything to work together. But the discussions tend to be an individual feature, especially until they can't be tried out until they can be seen in context of the standard, or of a tutorial. We need to spend more time looking at individual problems, individual features in the context in which they are used. I mean, this kind of design issues. So, let's look. I tried to articulate rules of thumb, I've done that several times, in the design evolution of C++. But here's a list I found from 2003. Stability and compatibility, yep, you want new features, but you don't want me to break your code. Libraries are good, because we can deploy them today, rather than waiting until all of your compilers have been updated. There are many project for which you can't get away from, say Gcc4.3, and it doesn't matter what the standout committee does to improve the language, if you still have to use a ten year old compiler. So, we really have to help people getting off those compilers. But we have to make sure what libraries is one of the things that helps us. Generality, the point is we have hardware. We have extraction. We need over generalities, rather than language features to solve these particular problems. And support those experts and novices. I've been going on like this for a long time. I gave a keynote here called make simple things simple. And experts tend to want really important, clever, highly performing, sometimes specialize things. Think about the poor novices, think about yourself, who's a novice, doing the other 90% of what you're doing when you can't do your speciality. Great libraries help, they increase type safety, improve performance, and ability to work directly with hardware. Fit into the real world. [BLANK AUDIO] Academic papers are nice, but you really want to help people building real systems. And again there, change the way people think. That is where the order of magnitude improvements are lurking. Okay, and this has been going on forever. Let's see, simple things simple. In the dark ages we wrote a loop like that. Declare a variable, then give a start condition, a maximum and then increment. That's fine, except sometimes you misuse the loop variable. So found a way. Just take a loop variable into the loop things, so we can see where it is, if you don't need the value afterwards, of course. And in 2011 made another improvement. Why actually mention the loop variable? I just want to go through that contain on arrays or something, for when I want to do that, which is 90% of the time, we can just write the range for loop. So basically the assumption here is, the 2011 thing does 90% of the cases, the 83 thing does 90% of the rest of the cases, and then you are back to being able to do absolutely everything, including all the bugs you don't like. So hence, the last line there, which shows that if you can do anything, you probably will. Those are real bugs found in real programs. So when we go on about the language and think about what to do, how to improve it, there's a lot of design decisions that should be made. They're only a few of the design decisions that are really key, I tried to list them, there's still a lot of them there, but you start from the beginning, you add things on it, based on experience and all of that. Let's see, the key things here is what kind of programming is being enabled by language features? A language feature in isolation is boring, could be seen as intellectually interesting, but I think it's fundamentally boring and it's fundamentally useless. If you only had a loop. So we started in the beginning. The ropes of C++ is in the building of the user defined data types. Constructors, destructors, the weight structures and classes are the same. I decided on C compatibility for good and bad. We've got macros there, that includes trying to get rid of them ever since, but it was a decent start. It allowed me to support a user after six months. It's not a ten year project. The language is a mighty 10 year project, but getting useful result is not. About 84, 85, we could support object oriented programming as well as anybody else. And sort of modern C++ is about 88, 89 when start of standardization. With the exceptions and templates, we can do RAII, we can do a bit of generic programming. And we had to figure out what generic programming really was. The STL helped. Metaprogramming comes along later, it's still too complicated, but we'll deal with that. And now, what are we doing? I'm hoping to see the type and resource safety soon. That is, a new collection of language features, that in combination deliver this kind of type and resource safety, without loss of performance. I have not forgotten this hardware, and we are getting better support for functional programming. We'll see, I put it out at beyond 2020 or thereabouts. Notice that the main decisions comes sort of, in clusters. There's one in the early 80's. And, things are happening up till 88. And, then it takes some time to learn. Things gelled in 11 again, around generic programming, and such. And, we're not there yet, for other things. So basically, one of the things I look at here, see, major changes comes in bursts. You need significant features, and then you need polishing, integration and then you can go from an idea to actually a deployed new way of writing code, a better way of writing code. And they come in bursts and it takes time to get there and then it happens. And most changes aren't major, I mean minor changes can support status quo, but you're still writing code the same old way. Minor changes can be useful ,they can be very comforting, and some minor changes are of course, necessary to support the major ones. But if you want to get to the next level, if you want to get to the next stage, if you want to make significant improvements, not 10%, not 40%. We can argue about two times and three times but usually I think, let's get some factors in there. 10 is a very nice factor and I'll take two. But if we want to do that, then we have, then we need major changes. And we need major changes because we're not in the middle ages. Things are changing all the time. Our problems change, we change, and so the language has to keep up. And major change is unsettling, that is well-known. If somebody comes with a radical new feature, a radical new way of doing things, even if it can co-exist with existing code, which it always can in C++, it is still unsettling. You have to learn new things. You just thought you knew everything. You may very well have known everything about the world as it was five years ago. It's not good enough, so we need to make changes and we have to make decisions. There are close to infinite number of directions you could go in. We can't go in all of them. We can't focus the language if we don't make decisions about going roughly that way as opposed to go roughly that way. And, that's hard to do. So, here is another view of this. I think early C++ finished about 88 or 89. And those are commercial release. And it took people maybe a decade more to actually figure out how to use this, to deploy this, to support this, to get libraries, compilers, analysis tools, the works. And after that there was a slowing, there was a feature drought. We didn't get anything significantly new during this period of time. A lot of work stabilized. STL sort of saved us from really fossilizing. There was a lot of work to be done, and the alternative to C++ was improving. I think we actually didn't do enough, C++ doesn't have a sugar daddy that can give us marketing and the research dollars and development dollars. The standard's committee was working hard on stabilizing things, so we were losing traction and C++ is dead was very popular in the press. But then it always is, but it worked. So I was thinking now, why didn't this send us into a death spiral? Because you can see, I'm complaining, but the numbers are going up. I mean,they're still going up by hundreds of thousands in this area. And I'm complaining? Most people wouldn't complain if they only got another hundred thousand users. Anyway, I think there was a drop later, but the thing that saved us was the CPUs stopped getting faster. You couldn't just ignore performance. You couldn't really ignore the CRO head and the CRO head abstraction anymore. You couldn't ignore the weirdness of the hardware anymore. And that is what I think helped C++. And then 11 came along, C++ 11, which supported features that have been developed and integrated and understood in the previous decade, and we are on an upturn again. And so I would really love to know what's happening to that curve. Are we going into another stabling out, leveling out, and downtrend, or are we going to carry on for a while? I hope we are going to go carry on for a while, but we have to get some things right. We're not going to maintain that curve by doing nothing. We're not going to maintain that curve by doing nothing, we're not going to maintain that curve by doing only tiny things, okay. So, an apology. We need great libraries! The standard is now more than 50% of the standard library. I can't talk about it, just like I can't talk about the industry in general, because I don't have time. I can't talk about libraries. So, apologies, go and see the talks about libraries at this conference, right? Okay, great libraries. So, that's it. So go back. Let's see, what can we do that is significant? And how can we avoid it becoming an intellectual exercise that never ends? That's back to the philosophers, whoops. So when you ask people what's a good extension, if you talk to people about extensions, what is useful, what is needed, what should be done, you get two very distinct answers. Here is the semi-caricatured developer's point of view. I really want something that helps me with my next project or my current project. I want a very specific problem solved because this is what's bothering me, this is what I'm spending all my time on. And really, I don't have time to go and read a book. I don't have time to read an article, I'm busy, busy, busy. Don't tell me anything I don't already understand, just give me a better tool for doing it. And make it isolated, so I don't have to rethink and recheck everything else. And don't break anything, mustn't break anything, this is bad. And it should be in my compiler tomorrow, thank you. That, I hear that often. And there's a picture of sort of a typical developer that's so busy looking at his current problem that he can't see the forest for the trees. This kind of input, this kind of experience, it's genuine experience. We've all have been there, right? It's real, but it's misleading. Very often, people who go on about that lax experience with long term planning, or at least, they've never seen the results of their planning. Aims can very often be set by others. That is, people are trying to finish this project that they have no say in. And they're spending 90% of things that probably nobody should spend time on, because some bozo didn't define the problem right. And you're gonna have very short term evaluation of consequences. That is, did the product ship on time or not? That's the proof of the pudding. From the view of a programming language and the development of programming styles, that is not a good criteria. Deliver on time, focus on the details, and don't screw up. Very important not to screw up. If you have a mortgage, don't screw up. Okay, but this is not the way we can design a language. There's the other extreme here, there's the typical designer, spouting theoretical something or other. And basically, we need to help the user community over the next decade as such. And we have to address fundamental problems because that's where the fundamental improvements are. Change the way people think. I keep going on about that because it's important. Make the language more regular, therefore easier to use. Be theoretical sound, theory is a lousy guide for what to do, but it's an excellent guide for how to do it. Once you have decided what you do, you have to be sound. And improve the reputation of the language. It's not enough that you can do things in a corner, and nobody hears about it. Again, the theory and the literature can be very misleading. Just as misleading as the environment of the developer can be the environment of the designer. There's a lot of focus on novelty, if it isn't new, it can't be published. Who said that what can help us most has to be new? Most things were invented a long time ago, and we have to revise them, we have to engineer them to be useful, that's not often seen there. There's a real focus on being clever. You have to solve complicated problems. If you have a simple problem and you solve it, you don't get much credit, even if that simple problem is something that is the right royal pain in the neck to a few million people. And focus on the amount of features, again, has to be clever. And quite often, if you look at the literature, and you look at theory, I think it basically disdains every programmers. We should do things this complete new way, and just rewrite all your own code, and if the programmers are more than 32, they should be fired anyway, because they don't understand anything. There's some kind of attitude there. Obviously, my conclusion is that we need both, we need to somehow combine the everyday developer experience with a design perspective that spans years and decades. And that's a lot of ands there. And you have to keep a lot of them in your heads at the same time. You have to balance, and this is seriously hard. The C++ community is enormous. It's so easy to be parochial. All of my friends do things this way, it must be good. All of my friends have this problem, it must be solved. All of my friends like this solution, we must choose it. Okay, how many friends we got, 1,000? That's not 1%. It's about a percent of a percent. How many of us talk to 1,000 people regularly about serious things? It's really easy to be parochial, to see only what's going on just around you, or read the same magazine. And get the same kind of stuff that some journalist thought was important. And we have to work within the current C++ implementation and infrastructure because we have to consider transition. And then of course again, we have to get it right, but then we have to be able to teach it right, so that people don't write 1984 style C++. Some of us have been there and done that, some of us do not want to go back, we can do better now. Okay, more examples, I distinguish between major features and minor features. Major features are ones that have potential for major improvements, and minor ones are comforting and can help a little bit. So basically, a major is change the way we think about code. And you can have combinations that are really, really powerful and interesting. I'm not saying you don't need any minor features, that would be ridiculous. But the driver should be the major features. So, we have little separators, digit separators in C++ 11, it's very nice. Okay, we've also got auto. It's sort of borderline major minor. If you just use it to initialize a variable and so they don't have to say double for that x, it's minor. If you use it to eliminate OR typing in generic code, it's getting close to significant about how you write code. And if you get concepts, you can actually make a major, major difference. People always underestimate concepts when they haven't tried them. And so there's this range of things. And one of the problems is that people will spend as much time on the little separators as they will spend on thinking about concepts. As a matter of fact, they might think more about it because it's so much easier to think about how do you separate digits. Do you use an underscore or a dash, should we use white space? So easy, everybody can have an opinion. Everybody can have an opinion on concepts, too. But it actually takes time to have an educated opinion. So it's hard to discuss that. There's isolated versus pervasive impact. We're getting in C++ 17, inline keyword for variables, and this is very nice, from a language technical point of view feature. No new keywords, new grammar impacts, no type system impacts, no impact, and no code. And best of all, it makes it trivial for you trying to reduce global variables in headers. Some people think that's a good thing, I don't. The last thing I need is a new way for you to sneak global variables into my concurrent code. But you are going to get it. And I've read articles that it's really good for you, so be my guest. Another feature that I was trying to get into C++ is connects to genetic programming and such is I want to be able to call a function with a functional syntax or the member syntax, no impact on old code. And it eliminates the need for duplicate functions, have you seen begin and end or x.begin, which one do you want to use, why? Forwarding functions, there is a lot of forwarding functions and binders and such, be eliminated. Here's forwarding function that I found and shrunk to something that fitted on a slide. Basically, it calls foo bar with a functional syntax. I should have used the other syntax in there, foo.bar. But basically, it can simplify the way you write code and the way you design libraries. This one went down in flames Because it was too different, new, and therefore dangerous. You might get the wrong function as if you couldn't get the wrong function today. Okay, let's see, one thing we have to remember is every extension does some harm. There's people that think that you can just get new things and then everything will be happy. No, you need implementation, tool, and learning. That takes time, effort, resources. It outdates learning material, and learning material and compilers in libraries tend to last longer than you'd think, like decades. Remember that Turbo C++ compiler I get questions about? That was 20 years ago. It's still bothering people today. And you can have a poor benefit cost ratio. That is, you can have a feature that helps me. It helps all of my friends. I can demonstrate it helps 100,000 people. How can you say it's not good? Let's see, 100,000 divided by 4.5 million. This could be that you are imposing a burden on the other 90% or more of the users, that doesn't give them any benefit. And it may delay new features that are necessary for other people. It can distract from good implementation of new features. It can distract from the optimization of existing code, of porting to other machines, things like that. There's no free lunch here. And you may actually get features that makes it harder to move in a direction you'd like to move to in a future. Like I want better concurrency, and if you want global variables, they get in the way of each other. Okay, now we also have to remember that if we want absolutely 100% portability or compatibility, back to the dark ages, we have some problems. Sometimes, we have to break it, if so, break it loudly. This is static_assert, good stuff. If you feed that into an old compiler it'll tell you it's not compiling that dialect of C++. Well, use an up to date compiler. Fix the old compiler or use a compatibility switch. There will always be a backward compatibility switch in the compiler. You don't like them, you shouldn't like them, but it's a solution. There's a little change there in the meaning of auto coming up in C++ 17, unless the committee changes it mind. This will break some very rare code that think that y is an initializer list, instead of an integer. Most of that code, it could be a silent change, but how will you use that y without getting an error. If you think it's an initializer list, and the compiler thinks it's an integer. Yeah, there's code, you can construct it. I don't think there's very much of it. So basically, we have to break code sometimes to get modern code looking better, working better. Try to break it loudly, and if not hope it breaks often. Okay, I think we need a direction. That's a major point here. We can't just go in all directions. We need principles, consistency, coherence, completeness, interoperability, zero overhead, good. It's hard to do, harder than it sounds. And we need a process to help us follow those principles. It's really hard with lots of individual decisions. A standards committee for a new standard has to make thousands of individual decisions, and they can't sit around looking at philosophy all the time. But it would be nice if there was some guidance, and you need concrete examples. People are amazingly good at misunderstanding text, especially on general principals and such, so we need something. So, creating and maintaining a direction is quite difficult. Most people want a smaller language with more features. This is hard. It is actually possible to get the effect through generalization, so that there's fewer rules you have to know. Because things work more in general, but it's hard. People want stability, 100% compatibility and with significant improvements. Except for the people that just want to break the whole thing and go and do a revolution. For those, go and do your revolution elsewhere. This is an old language. It's going to be a much older language in the next 40 years. And it's going to be quite good, and we can't break the code. It's our code. It was written by our colleagues and our friends, and it's still be written by our colleagues and friends for the next decade or two. Whoa, this is good trick. And so we want stability and some directions are mutually incompatible. We can't both go that way and that way, and keep things small. We have to make sure these things combine somehow. And the standards committee has no money, no resources beyond the volunteers that do all the work, and have to pay for the privilege of doing all the work. And the more features we add the harder it is to integrate, so the amount of work increases. And then of course there are people who disagree on fundamental philosophies. Do you want implicit things in language? Do you want a very explicit syntax for everything? Do you want it simple so that you may only handle 90% of the cases like the range-for loop? Or do you want everything to be fully comprehensive like the original C for loop? Then there's aesthetics, people disagree about what looks good. And then there's always a discussion about should we do things in the library or in the language. And I think C++ is a victim of its own success. Everybody wants to help. The standards committee is bigger than it ever way, more active than ever was, and I think the individual technical expertise of people in the committee is higher than it ever was. But it's really hard to be coherent. A lot of people come with totally different background, and doesn't appreciate that other people have different backgrounds, different concerns. And a lot people have not internalized the C++ process, where the language is going and why. And then of course there's people who's been there for a long time, spend all the time trying to rehash what we should have done ten years ago. Well that was ten years ago. We can't do much about it today. And so we have a long series of separate decisions quite often done by people who hasn't been in the room with the other decisions. And it's hard to be coherent. And sometimes people come in the last minute and says, we can't do this, this is horrible. And says, we've discussed it for three years. Well I wasn't there, why didn't you tell me? Well, we did tell you, but it drowned in the details, the mass of information. There's more than 100 papers coming for every standards meeting. Not everybody can eat, read all of those and understand it, and contribute. This is hard, and but now it's not really designed by a committee, it's designed by committees. There are subcommittees. There's people that never actually spent time discussing the features together. This is very difficult. Anyway, we should thank the committee. It's done a good job over the years. There is a very tired committee down at the bottom, just after voting out C++14. I think they might be voting up the top slide there. And the final thing is where people do a lot of the real work which is in the working groups, and notice all the computers there. Everybody is sitting there doing their various things in communicating with their friends in other countries and such. If you go into a room in the standards committee, you see 15 people sitting around the table. There's probably 30 people in the room, because they communicate. Okay, one of the examples here, why should complex be in the library and and not in the language? Why should a range-for be mostly in the language and not in the library? There's a whole set of decisions there that actually are not that hard to do. Sorry, not that easy to do. This is a discussion that you can have for every single feature. C++ is powerful enough that most things can be done in a library and especially if you put in a few intrinsics. When you do that, you can sometimes deploy it early, which is good. And you increase the compile time, this can be very bad, so we need to deal with that. Here's a simplification thing showing how things work over the years. So in 98 or thereabouts we started using things like pair. And we have to say a pair of what and initialize it. With 11, we say make pair, and it'll deduce the right types. And we can use auto, so that we don't have to sit and repeat ourselves so much. And in 17, we will be able to have the template documents deduced from the initializer. Cool stuff, so, progress happens at the smart more level. This is the kind of simplification that where we'll help people. It'll also confuse people who read old code and can't understand what the new code is doing or get used to the new code and get confused about what the old code is doing. You can't actually have changed without some cost. A direction, I think we should talk more about the future. It would be nice if people agreed on a list of things we would like to see in five to ten years. And it would be nice if people had an agreement about roughly what we would like for an extender in the three year horizon. We are not having those discussions, we are not having those lists that's bad. Most people don't articulate their aims, I do but often people fall asleep and don't read them. And we should be explicit about this, we should be articulate about it. We can't spend all our time discussing the details. And that's what I feel what we do, and furthermore, the last one is very controversial. I want to integrate things early. I want to see it in the standup document together with the other things, so that we know that things work together or not. Lot of people want to delay things until they're perfect. Remember Voltaire? Best is the enemy of the good. So some philosophy. We will make errors, in language design, like in program design and such. So let's get them made. I'm for early integration, I'm for moving ahead. We know we are going to make mistakes anyways, so let's get used to it. And we should maximize our successes, we shouldn't just minimize failures. Of course we don't want failures, but we are going to make mistakes anyway, so let's make them and fix them. Any change carries risk, including not doing anything. And we have to be confident. I think we're getting too nervous that we might make mistakes. Forgetting, one, we do make mistakes, and two, in the past, most of the time we were able to fix it. Before it was shipped, or before it was significantly impacting the community. Look, if your library writer or compiler writer, it hurts them to back up something. It hurts when something breaks but that's life, and it, if we have to move on, we have to take some chances. And one thing people do a lot, is to confuse familiarity with simplicity. If it looks the way I'm used to it, it's simple, is many people's definition. No it's not, it's familiar. It may be simple You have to go for simplicity especially on major things. So, a problem we have is that we can't actually explain what C++ is. And if we can't characterize what C++ is, how can we explain what it should become. We have to have some kind of agreement what it is. I have my suggestions, it's a language for defining and using light weight abstractions. It's aimed primarily at software infrastructure and resource constrained applications. We have long papers explaining what that means. Who is the language for? Meaning it is not for people who want to do a quick webpage. It's, I use the phrase serious programmers in the first edition of the C++ programming language. It's actually the first sentence of the first edition. I use serious, I edited out professional slightly early because I realized some of the amateurs were better. But people it takes the act of generating good code, or writing good code, or maintaining code that's serious. And that's what C++ is for. It's less for casual programmers, unfortunately. There's a lot of those, they do real good C++ at times, but only if the serious ones get there tools and libraries in such in place. And what would make the language better? We have to specify what it means to be better. You've seen some suggestions in this talk and in writings but we have to be specific to make forward. And so, we can't please everybody we'll maintain the direct map to hardware, the zero-overhead abstraction. Language is primarily industrial. We'll never get it pretty enough for every professor to like it for teaching freshman. I've taught freshman, to thousands of them, can be done. It's not even that hard but you have to do it right. What primarily C++ is there because we can build good systems for people. And then it rewards good programmers. If you are a good programmer you shouldn't be stopped from doing good stuff. We should make it simpler for a good programmer to do good stuff in areas we don't know. In application areas we don't know. In application domains we have never heard of. It's good. It would be really nice if we had a buzz word for saying this. I don't, I'm sorry. And everytime I've tried to find out good words I've learned why I shouldn't be in marketing. >> [LAUGH] >> Now, let's try and look ahead a little bit. My high-level aims was first C++17 and beyond. Now they're just for C++. Let's not put a specific time scale on this. Improve support for large-scale dependable software. Support higher-level concurrency. Everything is getting concurrent, so let's support it well. Simplify the core language use, you can't simplify the core language that can break your code. We can simplify it's use, ranges also when things like that can simplify range for also things like that can simplify your code and then we have to address the major sources of errors that can be through tools. It can be through coding guidelines It can be through language features and libraries. Preserve the fundamental strength. C++ has to remain C++. If you want something that's fundamentally different from C++, go get it. C++ is not for everything and for everybody, we know that. But don't abandon the past. Don't get stuck in the past and awards more feature creep because there's so much stuff there. So there was my top ten list for 17 as presented I think in February last year. And I was very optimistic. I thought we were going to get concepts. I thought modules were so far advanced that It would be a stretch. Goldberg might be able to get it. There was a range library. It was marginally, might get it. Uniform syntax, code things, the shipping networking, it's been shipping, contracts, yeah, stretch goal. SIMD vector and parallel algorithms that is going well. Library, vocabulary type, optional variance string span span, yeah it's going in a magic stack array type because stacks are really useful things and it would be nice to have proper arrays on them. And, well, I learned the hard way it's hard to make predictions. Especially about the future. We only got the two things that are pointed to there and only partially. And all the rest is postponed. That's sad about that. Here's what you actually get and here's a list. And the problem is that all of that basically is in the minor category. A lot of minor improvements can add up to something significant if we, well Most of these will help somebody in some way so there's something for everyone here. I can't imagine any C++ programmer that will not have at least some relief from pain in C++17, that will not be able to write some piece of their code better in C++17. So what I'm concerned about is that we are not moving fast enough and we're focusing on too small things. And let's see a library features, well, it's not a library talk so I'm not going to go into that. We're finally getting the file systems and parallelism kind of stuff. Okay, so what do I think now after the last year or so? For C++20, and hopefully available before 20, I would like everything C++17, and I would like my C++17 list because it still reflects the way I think the language ought to be going. And operator dot, I want smart references, finally. They were about the first extension proposed at the first meet, second meeting of the C++ standards committee back in the dark ages. I think we finally know how to do it. Before comparisons, it was rejected by the standards group. I think they got it wrong. And, beyond that, there are things we need to look into. We could use a packet manager. We could use a standardized representation of C++ source code that we could use for tool building. IPR is something that Gabriel Dos Reis and I did a few years ago. It's a general representation of a language for the superset of C++, fully typed, minimal in all possible ways. It would be lovely if we would get something like that. There's work on static reflection. I would like to see that come in. I've been experimenting with functional programming style pattern matching. So we could finally get safe use of unions and such, part of this idea of making things simpler and making them safer. And high levels of concurrency support, I'm not going to be specific there but I don't want to fiddle with new texts and worrying about data raisers and such. We can do better. And then I feel that we are diluting the effort. We have 100, 200 people in committee. We have 1,000 people in the community that contributes. If we don't watch out, we'll get nothing because we are all over the place. And if you look at this list, I did not expect I'd get everything in 17, but I expected I'll get something, and this is not much. If this has been a project, whether we have a project management and such, we would have shipped a couple of the major things and you would have been busy learning about it and upgrading your code. As it is now, it's harder. It's lack of focus that does it. So, what do we do now? We'd have to get ready. Upgrade to C++14 if you haven't already. Lots of places have upgraded to 11. It's easier to upgrade from 11 to 14. This is good. If you're still stuck in '98, either mindset or compilers, upgrade. It's the best of getting ready for the future, is at least get to the present. Furthermore, your code will run faster. If you compile with a modern compiler, you will be able to run faster because you'll target modern architectures, instead of using the backward compatibility features of your CPUs. Upgrading from an old compiler is a good way of finding bugs and to run faster. And try out the TSs. I mean you can get concepts. Ranges are there to download news. The networking library has been in production use, in many places, for the last five years. It's great. Coroutines are shipping, mostly by Microsoft but I hear there's a Clang implementation also. Try them, you can do some really cool pipelining very, very fast, and you can do it today. Modules, they're coming. There's talks about them at this conference. This is good. And then I'm still working on the core guidelines that we announced last year. They've improved. I'll get to that. Improve them and improve tool support. So let's go over concepts. So technical specification, it's shipping GCC 6.1. The most important thing about concept is that you can improve your specification of your generic code and you can get simpler generic code, like you can do overloading based on concepts rather than writing an. And you can get better error messages and, by the way, compiles faster than the alternatives. And so basically I want to see code that says I want to sort anything that's sortable. And so, if I sort a vector it's sortable. What does sortable mean? Definition is over there somewhere. It is a sequence that is random access with elements you can compare with less than. Okay, translate that into C++. It's four lines and you're done. By the way, you cannot sort the list. Why not? The standard says so. It says that the list is not a random access sequence. And so the error messages will tell you that it's not sortable, and it will tell you that it is not random accessible and it's not random accessible because it doesn't have soft grade plus. There's been some discussions about the quality of the error messages. Some people want more, some people want less. I've forgotten what they're shipping in 6.1. It used to be that there was a switch, so that you can say how much you wanted. I always wanted less, and a certain who wrote that compiler always wanted more. It seems that people these days out in the community usually wants more. They'll get over that. Once you learn to use the concepts and know the concepts, you'll want less. I want that switch back. Concept design can be used in the comments. You can actually design your code around concepts. You could actually design your code and test it out on the Microsoft compiler commented out. No, sorry, not the Microsoft, the clue compiler, and then port it to whichever compiler you're using. Just put a comments in place. And when the other compilers catch up, take the comments away. And you can use the concepts from the ranges, TS. There's a good set. You don't have to start from scratch. Then we are going to get modules. Almost certainly. And this is the way we write code today. We include some files and then we use them. And there's some data I got from Gabriel Dos Reis. There is 176 bytes of text that you wrote to get this little example. It becomes 400 plus kilobyte GCC, just over a megabyte with Clang, or Visual C++. Now, our compilers are very, very clever to actually ever get finished with all of that text. And that was only one file. You're going to include that stuff 100 times and it's going to be bigger. We are simply going to radically decrease the amount of data processed by the compiler. This ought to give significant improvements in compile time. I don't have any numbers unfortunately. To use it, you need better code hygiene. If you have undisciplined macro usage, you're not going to get that much advantage, because if you have old code, and you demand your compiler does the old way of doing things, you're going to get the old performance. So some cleanup would be necessary, but once you've worked this in, get code hygiene, get fast compilation you just import the libraries and then you use them to write a module. It's not rocket science, you can introduce it gradually. Have some stuff that usually includes on the macros, have some stuffs that encapsulate it, have some stuff that doesn't use it any more. And, basically, it's based on two keywords. One for getting things in, and one for saying you want to get it out. There's lots of details, of course. There's at least three talks at this conference that'll tell you about the details, so I'm not going to do it here. I'm just going to say we have to hope for simpler code that compiles faster. And if you compile it with things like concepts, it gets even faster, it gets better error messages, and cleaner code. We're working on a contract, it's simply a proposal now, we're working about it, it's sort of assert on steroids. And it's selectively enabled at runtime, so you can say preconditions, expect latter thing if the queue is not full. Post conditions, it make sure that once you have push something on to the queue it's no longer empty and you can have assertions in your code. So, that simply standardizes what a lot of people are doing with special code on macros and such. And there will be three levels of contracts you can argue whether it should be two, three, or four. Currently it is three. Basically audit, which is big expensive tech checks, default, which is relatively cheap check, checks relatively to the algorithm that's being done. And action, which is basically not checked at compile time. You can write things like that. And we're going to get something called structured binding. This was voted into C++ 17. It's coming in compilers right now. We'll probably be told this week whether it is shipping in Clang. I think it either is or is close. Basically it can give local names to struct members, so when you call something like a map insert that returns a pair, you can break out the pair. The one is an iterator and the other one is a success indicator. And so you can write code like that. One of the things it does, is work nicely with the range for loop things. So you can go through the map and for each element break out the key and the value and do things with it. Very nice, very nice stuff. And then the kicker here is that we design things to work in combination. If we didn't do that every feature would bloat by itself. And there would be tremendous overlap in the language. There's already enough overlap between the features in the language. But these things can work together, so I want to write that code. I import, I O-stream, namespace, I have a map printer, I write some code, it has concepts in it, it has structure bindings in it. I can't do it. Modules are shipping by Microsoft, concepts are shipping by GCC, and structured bindings are shipping in Clang. I will be really happy when I can get all three in all three compilers, because I happen to work in a place that uses all three compilers. I'm an optimist, people can tell me, will I get it next year? I hope so. Okay, again, thanks. We couldn't do it without a lot of people. I shouldn't have said that, I myself am up there, I shouldn't. Okay, that guy there, I'm not thanking. But the others I'm thanking. >> [LAUGH] >> Okay, they've all done hard work to get us to where we are today. And again, if I put in everybody in the font will be too small for you to see it, so I just picked a few that did something. Until now, the other thing we can do is we can work on guidelines for how to write modern C++. How to clean up the old code. I gave the keynote last year on that. If you haven't seen it you can. But basically, we want to guide people towards a better, more effective, more efficient, better style of code. Develop the style and we're aiming at type and resource safe C++, no leaks, no memory corruption, no garbage collector. No limit of expressability, no performance degradation, and in strict ISO C++, tool enforced. I'd hoped to be able to say I could do this at scale, today, I can't. It's not at scale yet. But, there's a lot there, there's a lot that wasn't there last year. So progress is being made. There's the links to the guidelines, they are links to the support library we're using. And we can use all the help we can get. And the aesthetic analysis tool support that has started, you can actually get something out of a few of them. I just wanted more. So the status is we've got 423 rules. Which is, of course, too many rules because people can't remember 423 rules, can't even count that high. On the other hand, the idea is that the tools will help you find where you made a mistake and dump you to the right place in the rules so that you can read what was the rule that you are not supposed to break. Why is it a good rule? Examples, and what can you do instead? And some of that is in place. There's beginning industrial use. Usually an organization subsets and super-sets to fit their specific needs. That's good, that's expected. It said so in the introduction even last year. And there's some starting use in teaching commercially and in academia. So after a year I guess I shouldn't be, I'm impatient, and I wish there was more. But maybe I shouldn't be. The fact that one year later it's getting into academic curricula is pretty good. We wanted better tool support. I thought it would be better. Well, apologies, things happen. We're working on it, and if any of you are tool builders, I encourage you to think about it, look at the guidelines, content, the guideline's editors. You can find us on the GitHub and I'm one of them. So not too hard to find. Herb Sata is the other main name on the paper. And expect more. And again, thanks. We have, I don't know how many contributors. Twelve squared. And lots of issues. I hear about translations into Russian, Portuguese, and Korean. I can't read those languages, so I don't know how up to date they are or how good they are, but somebody is trying. Our general approach to just about anything is sort of the cocktail of approaches. We use low level stuff, like in the GSL, the guideline support library. There's an owner annotation that means nothing. It's an alias. But it tells you it's an owner. So static analysers and humans can understand that you're supposed to delete that thing when you're finished with it. At the higher level, where things are better, you have abstractions that represent ownership. Vectors, unique pointers, map, shared pointers, and stuff like that. And we have support for optional range checking. We go one level up. Span, string_span, not_null, you can express things directly and you can either have the code check it. These libraries functions will actually do checking, or you could have the equivalent done statically. And then we have rule support. There are somethings that just don't do it or just do it this way and you don't get into trouble. That helps and we work. The idea is the applications are built on the abstractions and then you can verify them. As oppose to fiddling around with low level stuff all the time. But sometimes you need the low-level stuff. Herb will talk a bit about that in the last keynote. There's an outline of the guidelines, there's a lot of them. The supporting sections, a lot of them are horribly incomplete, but not all of them. Some of them actually have teeth. And some of them actually have checking that supports them. Here's an example. Do not pass an array as a single pointer. This is an example of one of the rules where we have looked into seeing where the bugs are. And people passing a pointer or peer pointers and an integer that's supposed to tell how many limits there are. This is a bug source. It is a major bug source. Furthermore, it's a source of and other kinds of stuff. And so the rule is there, it's easily checkable, and there's an alternative. You can't just say, people, don't do that. I mean, what do we think it is, kindergarten? You have to give an alternative that is valid, applicable, and equally fast. And span in the GSL is an example of that. There's an example of how to get burned. Somebody thought it was a bright idea to have an array of elements of a derived class, and then pass that to a function that took a base class. There's a double implicit conversion going on there. First it converts the array to a pointer, then it converts the pointer through derive to the pointer to Base and boom if you subscript that stuff. Again, don't do it. The tool will catch it for you. I mean you could say I would never do that. Well I'll tell you some people do that sometimes. Bugs are very often done by people who hasn't been burned yet. And it would be really nice to help them, and that's what we can do. So that's the sort of structure. There's some exceptions if you pass zero terminated strings. That's fine. An enforcement, I believe this actually is available in the implementation by Neil Macintosh in the Microsoft compiler. And here's the example I gave earlier. You can use concepts today. And the recommendation is use concepts for all of your classes today. And, if you don't use a compiler that understand concepts, put comments in front of them. I had a comment just this week about this rule, and says you didn't mean policy types of something? And I said give me an example. And the answer came back says, I tried to write it down and I realized that I needed these concepts. People who hasn't tried this stuff. Under estimated, and if you dont want us to start from scratch go to the ranges TS and find a good set of starting concepts. It'll teach you some good manners and it'll help you get started by specifying the code better. Always initialize an object. I mean, we should do that but there's a lot of clever stuff where people say, I don't want to initialize it yet. And then they forget. Or they write a complicated if something is something initialize it this way, initialize it that way or else you divide that way. Okay, you get it wrong sometimes. It gets too clever. If you don't want a thing initialized yet, don't declare it yet. If you have a complicated initializer, there's ways of doing it. Like if you ever have initialized a variable, a variable with a lambda that did some conditional stuff on it. You can do better. A rule like that gives you suggestions for how to do better. Don't just say don't do it, say why you don't do it, and what you can do instead. And there's a lot of related talks. This is sort of my reason for not giving a language feature talk, apart from feeling that sometimes you have to talk about bigger pictures. There's a lot of talk at this conference. You want to know more about modules? There's modules talk. You want to know more about guidelines? There's guideline talks. Code teams. It's here. Parallel algorithms, which I mentioned, they're here. And this is, undoubtedly, not all the related talks. In some sense every talk at this conference is related, but in a stronger sense it's available there. And so. And here's some kind of summary. C++ is successful. We have to build on what made it successful. To sustain the success and to sustain the many applications that we depend on everyday. And We have to focus on significant changes. We mustn't just spend all of our time on details. First you decide where you go. First you decide what is major. And then you can agonize about the details, not the other way around. And we can't wait for the comedian, the compiler writers to finish everything. We actually have to catch up with what's available now. We have to experiment. Experimentation shows how we can use new features. It may even show you how new features can be improved while they're still in the design and decision stage. And the TS's, especially in the libraries, can be used. Some of them are in production use now. I don't recommend all of them, for production use. But there's no need to wait. There's a lot of stuff that can be done by us this afternoon. This is not just future stuff. Yes, those philosophers on the first slide, but some of it is really concrete. And try the guidelines. If you tried it after last year, you found it was incomplete. You try it now, it's still incomplete but it's better. Significantly better than it was last year. And, yep. By the way, that picture's not of stars, it's a program that pretends to generate stars. So, in case you wonder. And so, I think I have plenty of time for questions now Thank you. [APPLAUSE] I don't know, do we have a system with microphones and such? Yes. Please use the microphones if you're asking questions. >> How much can modules help with template heavy code? >> How much can modules do a template heavy code? Quite a lot, because you can break templates down into something like the IPR, I mentioned the internal program representation. So you'll basically build a typed, abstract dag. Not in the ST but, something more advanced like that. And then a lot of the template work has been done once. And so, only the final instantiation will be done once per set of template arguments as it was meant to be done. So go and ask the people that are doing modules, especially people that do both modules and concepts like Rays. He's down there with a hat. He's the right person to ask, but modules plus templates, especially modules plus templates with concepts, is a very very potent mix. Both for compile time, and for correctness. I want those faster compiles, significantly faster compiles to find more bugs. It's easier to compile faster, you just postpone everything's runtime. [LAUGH] That's not what I want. >> Thank you. >> So, you seemed sort of frustrated with the pace of the 17 standard, that we didn't get a lot of the features that you wanted. And you showed the graph of where it went real fast up and then flattened and then went fast up again and your worried, seemingly. It feels like you are worried about it flattening again and you want to try and forestall that. >> But i wonder if you can give some historical context as to, when we were in the flat portion back in 2005, 2008, did it feel flat? What was the committee doing at that time, that was before a lot of our times? >> Okay, this is a very complicated question to answer because it spans decades and, well, millions of people ,and language features, and industrial connections and everything. But yes I"m very impatient and yes if I'd been dictator of the world you would have had more features today and people in the committee that didn't think this was the right thing will tell you I'm wrong. And I'll tell them they are wrong and that's how we discuss things. >> [LAUGH] >> Hopefully we're still friends after that. At the time, yeah 2002 +/- 3. It did feel as if things were not going as well as it should. The committee was under the false assumption that you couldn't discuss new language features for five years. We actually believe there was an ISO rule for that. There was some kind of IS rules says you couldn't vote them in and change the standard but we were wrong. We were also very tired after the effort of delivering 98. And I think we screwed up. And then fortunately the CPU stopped getting faster and a few other things, and we sort of recovered. And like Stephanoff did us a real good favor by the SGL which created a certain amount of excitement when we needed it badly. So Hit on that before the standard, but of course, after the standard is when you get it available. So, yes, I think we could do better. And yes I think we can do things faster. I don't think any total disasters have happened. And I, just trying to give my contribution to what we can do and why we should do it. And next year and the year after, we will know more and have high hopes. A lot of these things are shipping, that I've been talking about. >> So, C++ has this rich history of features following this pipeline from third-party libraries into the standard library and even into the language itself, for instance, move semantics were in boost before they were in the language. But the path to language is much rockier because the APIs for extending compilers aren't really there, thus you often have these really dirty tricks that people do inside of metaprogramming or inside of all these other things. And it takes a lot longer to get things into the language because of that, and that's really cuz the APIs aren't there. Is this something that the standards committee should be concerned with, or is that something that's on your mind, should those be standardized, and why or why not? >> Let me just ask a counter question before I Try to answer. You said APIs? >> Well, standardized APIs. I mean I can't write a new compiler extension that will work with Microsoft and will work with Clang and- >> Okay, I was just trying to make sure it's right thing. That is a very hard question. Traditionally, platform vendors have insisted they can do things on their platform. And compiler vendors are very keen of not breaking their current user basis code. Furthermore, there's been a concern that if we standardized an ABI, like the Itanium ABI, and said everybody had to use it, we would limit experimentation and performance. So, this has been close to the third rail in discussions and the standards committee, and there has been people who simply wouldn't discuss this. And I don't have high hopes for this. If we could get a group of people together to arrange greater interoperability. You would have to have for starters Clang, GNU, Micrsoft, Intel, and a few others to sit down and agree. And I don't think it'll be the standards committee that can do that. For starters, they wouldn't want 100 people involved in the sign of a standard API. Furthermore different hardware has different things. So you probably could not standardize across architectures. And if you can't standardize across architectures, how can you standardize across architectures that are still changing? So it's a really, really sticky problem, and since I've failed to make progress in that area repeatedly, I'm not going to make any promises. Complain to your compiler vendor, >> [LAUGH] >> Encourage them to do something, maybe not perfect, maybe there could be a compatibility suite or a conversion mechanism in place or something, but don't rely on the standards committee to doing that. >> I would like to comment a little bit on the list that you have for C++ 20 and beyond, and the weirdness of hardware. Because I didn't quite make the connection between how we're gonna support this weirder hardware, as you mentioned. >> The main thing that was missing on that list was specific things about improved concurrency control. That's, I think, we need higher level concurrency models. We may need some work in cache awareness, I don't know. Somebody may look into that. And we may see some work in the standard library, for say, flat containers of various sorts. For using, cash is better. I just didn't want to go into details there. And I think a lot of it is a library issue, which is the main reason I didn't go deeper into it. Libraries with intrinsics. >> In your growth chart, I think there were maybe two hidden things that you didn't point out. That were, maybe there is growth of the communication web and being able to get access to a lot of information, and perhaps maybe some key individuals who have helped project the language forward, over the last couple of years? I mean, notable people who are at this conference. What are the ways to, do you think those are actual factors in the growth of language, and if they are, how do you capture that and make it go forward? >> I didn't quite understand, could you. >> So the idea being if there was sort of a lull in the growth of language and then it sort of took up, was that due to, maybe there are things on the list that you didn't talk about, that I can find information easier. I'm able to use learn about how to use a language better than maybe 2000 and did that help with the language? >> Yeah. >> And also now we've got a lot of people helping. >> It's a complicated issue. The exhaustion of the committee members were important, so was the draining of the community by organizations like Sun that was taking the best compiler writers and putting them on Java. And so was the fact that we had never managed to create a center for the C++ community. We don't have a central website, we don't have a central library exchange, and things like that. We're trying now. The C++ foundation is part of an attempt to deal with this. And then finally there was libraries that was missing, notably a GUI library. There's no standard for it, which we couldn't get, because there was at least five organizations that was members of the standards committee that was of the opinion that their GUI was the best. And we could not move without insulting more than half of the committee And that's not the way you move. There was all the things, we're finally getting a networking library but why don't we have a web access library? It's 10 years late and, Well this happened. It was ten years ago. The question we have to ask is what can we do today. And we're moving too slowly for my taste. I would have liked the SU library to be shipped with 17. As it is, it's production quality and used, so use it anyway. >> Hi, actually you answered a part of my question by talking about concurrency and cash awareness. But my question was more like, you started by saying that C++ has to be true to its two code principles of one, staying closer to the hardware, and second is, providing minimal obstructions on top of it. It's just my opinion that as we are going to C++ 17 and 20, I think the focus has more been on providing those extractions better, whereas the focus is less on being closer to the hardware. And almost to an extent that, there has been a perception that, people say that if you are really focused towards speed, you see. So what's your opinion on that focus? >> There's a lot of impressions out there. And very often they are wrong. I think there is a part of the community and part of the standards community that is very interested in performance. In my day job, I sometimes deal with both high volume data and ultra low latency data. I can count nanoseconds now, I didn't used to be able to. And it's certainly not forgotten. Whether we popularize and spread the word well enough is another matter, and also whether the ideas that come forward are general enough to work with everybody. They'll certainly work with, for instance, integrating FTAs and CPUs and GPUs on the same On the same chip, and we're aware of that. There's at least one cross industry group that are looking into issues like that, that we know about. But I suspect that we're still waiting for some proposals for how to do that, some people are talking about it. I think it's more an impression, an image issue, than it is real. But anything we can do to get more known that we're working in those fields is probably good. I think there are talks at this conference that relates to better use of hardware. I suggest you look into it on the schedule. >> Could you maybe say a couple words about the role of Boost in the past, and then particularly what you envision is a role for organizations like that in the future, as far as contributing to this effort? >> Boost has made an excellent, and important contribution to modern C++ in general, and to the stand in particular. They've tried out a lot of ideas. I would say only a few of them have any chance of getting into The Standard, which, I think is fine because The Standard is what has to be shipped to everybody everywhere. And it has to work together. Boost is doing a good job, but they shouldn't expect more than say, a 10% success rate, if entry into the standard is the measure of success. I don't think it should be. I think usage should be. The other thing is that sometimes, I think, Boost over designs, and becomes a bit expert friendly. And if I would make some suggestions to Boost, nothing I haven't done all ready repeatedly, and actually once at BoostCon, focus a little bit more on simple use. Focus a little bit more on packaging. I would like to have sort of a novice's package of Boost stuff for the essentials, and then the package, and then the experts only package. And I would not have to want to know everything that an expert needs to know to be a novice user, examples like that. But I think Boost is one organization. It is not the only organization, I wish there was more and I wish there was more code there and I wish people would use it more. Without it we would be sunk. >> Thank you. I might say I think you way underestimate your abilities as a marketer. >> Sorry, I am over. I'm being interrupted here. Sorry about it, there is a session for committee tonight. So if you've got committee questions, you go to that. And otherwise catch me in the corridors. That was a hard interrupt. Sorry. Thank you. >> [APPLAUSE]

Channel: CppCon

Views: 83,830

Keywords: CppCon 2016, Computer Science (Field), + C (Programming Language), Programming Language (Software Genre), Application Software (Software Genre), Bash Films, @BashFilms, Conference Video Recording, Event Video Recording, Video Conferencing, Video Services, Bjarne Stroustrup

Id: _wzc7a3McOs

Length: 103min 51sec (6231 seconds)

Published: Thu Sep 22 2016

Reddit Comments

[u/pjmlp]

People still ask me questions about Turbo C++ 4.0

Released in November 1993.

Sadly the quality of teaching seems to be quite low on certain places.

[u/journeymanpedant]

watched this talk earlier, thought it was very good. Nice to see Bjarne was pretty frustrated at lack of major progress in c++17, but it does make me a little uneasy that he seems to be gung-ho advising people to use non-standard stuff from bleeding edge compilers, even if much of it will be eventually standardised. We ALL want concepts, modules, etc, but, as a jobbing developer as well as an enthusiast there's no way I'll be investing too much effort in these implementations until we have a better idea of what it will eventually look like in the standard

[u/mat69]

Is it just me or are many (not all!) of the "questions" after the talk just a show-off knowledge/expertise instead of real questions? Like talking for a while to close with something resembling a question. Btw I had the same feeling when watching CppCon 2015 recordings.

[u/[deleted]]

This talk felt like Bjarne's version of "I'm not angry at you, I'm just dissapointed".

[u/lacosaes1]

Déjà vu.

[u/afiefh]

What is this Type and Resource Safety magic he has in slide 20 (timestamp: 24:20) and is positioned between C++17 and 20? Does anybody have a paper/article on it?

[u/xoner2]

Somebody in the audience got offended... TMZ-type stuff ....