Bjarne Stroustrup walks through how C++ got standardized starting in 1989, the committee structure with three one-week meetings yearly, and why the language shifted from long release cycles to a three-year cadence for C++14, C++17, and C++20.
Questions this video answers
Early 1989 (two people from IBM and HP approached him).
1990.
1998.
About $1,000; Stroustrup says he thinks it's $1,280.
Three one-week meetings per year.
Chapters
But get back to the standardization. We are standardizing C under ISO rules, which are very open process. People come in. There's no requirements for education or experience.
So you started to develop C and there's hope. When was the first standard established? What is that like the ISO standard? Is there a committee that you're referring to? There's a group of people. What's that like? How often do you meet? What's the discussion?
I'll try and explain that. So Sometime in early 1989, two people, one from IBM, one from HP, turned up in my office and told me I would like to standardize C. This was a new idea to me and I pointed out that it wasn't finished yet. It wasn't ready for formal standardization and such. And they say, no, Bjarne, you haven't gotten it. You really want to do this? Our organizations depend on C. We cannot depend on something that's owned by another corporation that might be a competitor. Of course we could rely on you, but you might get run over by a bus.
Right, the old bus.
We really need to get this out in the open. It has to be standardized under formal rules and we are going to standardize it under ISO rules. You really want to be part of it? Because basically otherwise we'll do it ourselves. We know you can do it better. Through a combination of arm twisting and flattery, care got started. So in late 89 there was a meeting in D.C. at the. Actually, no, it was not ISO then. It was ansi, the American National Standard were doing. We met there, we were lectured on the rules of how to do an ANSI standard. There was about 25 of us there, which apparently was a new record for that kind of meeting. And some of the old C guys that has been standardizing C was there. So we got some expertise in. So the way this works is that it's an open process. Anybody can sign up if they pay the minimal fee, which is about $1,000. There's less than. It's a little bit more now. And I think it's $1280. It's not going to kill you. And we have three meetings a year is fairly standard. We tried two meetings a year for a couple of years. That didn't work too well. So three one week meetings a year. And you meet and you have technical discussions and then you bring proposals forward for votes. The votes are done. One person per. One vote per organization. So you can't have say IBM come in with 10 people and dominate things. That's not allowed.
And these are Organizations that extensively use cu.
Yes, or individuals.
Or individuals. I mean, it's.
It's.
It's a bunch of people in a room deciding the design of a language based on which a lot of the world's systems run.
That's right. Well, I think most people would agree it's better than if I decided it, or better than if a single organization like AT&T decides it.
I don't know if everyone agrees to that. By the way, bureaucracies have their critics, too.
Yes. Look, standardization is not pleasant. It's horrifying. It's like democracy, but exactly as Churchill says, democracy is the worst way, except for all the others. And it's, I would say, the same with formal standardization. But anyway, so we meet and we have these votes, and that determines what the standard is. A couple of years later we extended this, so it became worldwide. We have standard organizations that are active in currently 15 to 20 countries, and another 15 to 20 are sort of looking and voting based on the rest of the work on it. And we meet three times a year. Next week, I'll be in Cologne, Germany, spending a week doing standardization, and we'll vote out the committee draft of C20, which goes to the national standards committees for comments and requests for changes and improvements. Then we do that and there's a second set of votes where hopefully everybody votes in favor. This has happened several times. First time we finished, we started in the first technical meeting was in 1990. The last was in 98. We voted it out. That was the standard that people used till 11, or a little bit past 11. And it was an international standard. All the countries voted in favor of. It took longer with 11, and I'll mention why. But all the nations voted in favor. And we work on the basis of consensus, that is, we do not want something that passes 60, 40, because then we're good and getting dialects and opponents and people complain too much. They won't complain too much, but basically it has no real effect. The standards has been obeyed. They have been working to make it easier to use many compilers, many computers and all of that kind of stuff. And so the first, it was traditional with ISO standards, to take 10 years. We did the first one in eight. Brilliant. And we thought we were going to do the next one in six, because now we are good at it. Right? It took 13. Yeah.
It was named Ox.
It was named Ox.
Hoping that you would at least get it within the single. Within the odds, the single digits.
I thought we would get. I thought we would get six, seven.
Or eight the confidence of youth.
That's right. Well, the point is that this was sort of like a second system effect, that is we now knew how to do it and so we're going to do it much better and we got more ambitious ambition and it took longer. Furthermore, there is this tendency because it's a 10 year cycle or age doesn't matter. Just before you're about to ship, somebody has a bright idea.
Yeah.
And so we really, really must get that in. We did that successfully with the structure. We got the standard library, gives us all the STL stuff. Basically, I think it saved C. It was beautiful. And then people tried it with other things and it didn't work so well. They got things in, but it wasn't as dramatic and it took longer and longer and longer. So after C11, which was a huge improvement and what basically what most people are using today, we decided never again. And so how do you avoid those slips? And the answer is that you ship more often. So that if you, if you, if you have a slip on a 10 year cycle, by the time you know it's a slip, there's 11 years till you get it. Yeah. Now with a three year cycle there is about three, four years till you get it. Like the delay between feature freeze and shipping. So you always get one or two years more. And so we shipped 14 on time, we shipped 17 on time and we will ship 20 on time. It'll happen. And furthermore, this gives a predictability that allows the implementers, the compiler implementers, the library implementers, they have a target and they deliver on it. 11 took two years before most compilers were good enough. 14. Most compilers were actually getting pretty good in 14. 17. Everybody shipped in 17. Wow. We are going to have at least almost everybody ship almost everything in 20. And I know this because they're shipping in 19. Predictability is good, delivery on time is good. And so yeah, that's great. That's how it works. Sam.
