Related information:
Bjarne Stroustrup: Standardization is an extremely valuable, most important, largely underestimated, and most frustrating activity. C++ became a better language through standardization and acquired a standard library of surprising expressive power. Formal standardization is one of the few defenses that a user has against the interests of compiler suppliers, who always try to lock in their users.
It's hard to pick out specific events. Most of the work in the committee has the form of a process of discovery, refinement, and building of trust. Such things take time. However, the single most important event must be either the initial 1990 vote to standardize C++ based on the reference manual of the 2nd edition of "The C++ Programming Language" (that is, with templates and exception handling) or the final 1998 vote ratifying the ISO standard. In between those events, the vote to accept the STL as part of the standard library standard stands out as a most happy event.
There is no negative/regrettable event of a magnitude to match these positive votes. All "regrettable things" are either very minor technical details or discussions that (temporarily) polarized the committee so as to make further progress harder. I would have liked to deprecate C-style casts and not to introduce in-class initialization of static const members of integral types (only), but these are minor details.
I am looking ahead to yet another key vote. Sometime over the next year, the committee will decide on the future directions for ISO C++. That will be an event of the first magnitude.
C++ View: Why is the standardization of C++ frustrating? And would you please tell us more about the process of the work in the committee?
Bjarne Stroustrup: Standardization is a slow process, often focussed on minute technical details, and you need to get dozens of people from many countries and from very diverse technical cultures to agree. Also people representing very different organizations (or just themselves) need to collaborate productively. The C++ committee is not an organization that is happy with a vote being "won" by a 60% to 40% margin. Such a vote would be considered a failure. We aim for consensus, meaning "almost everybody agrees" and work until we reach that. That's hard, and everybody - at least sometimes - wish for a faster way. However, the result is a language that is acknowledged to be good enough for an incredibly large community, rather than being just perfect for any one use or any one individual. In the end, we managed to get unanimous votes (43-0 in ANSI and 22-0 in ISO) for the standard. I have been told that this degree of agreement has never before been achieved for a programming language standard.
First the committee has to figure out what the real problems are and what kind of technical solution is feasible. This, I referred to as "discovery". Next we have to refine that solution into something precisely described in standards text. And always the individuals taking part in the standards process must learn to work with each other and to trust the good intent and the professional abilities of others. That, I referred to as "building of trust" - it is quite possibly the most important single part of the standard process; without mutual trust nothing can be achieved.
C++ View: Alexander Stepanov said that once he had argued with you because he thought C++ template functions should be explicitly instantiated like Ada generics, while you insisted that functions be instantiated implicitly using an overloading mechanism. Thanks to your insistence, this particular technique later plays an important part in STL. Could you tell us more about this story?
Bjarne Stroustrup: I can't add much. Alex and I spent some time discussing language features before templates became part of C++. He was - in my opinion - at the time overly influenced by his experience with Ada, but he also had valuable practical experience with generic programming that I largely lacked. He reinforced my bias in favor of uncompromising efficiency and inlining. We both shared a dislike of macros and a liking for type safety. He would have liked stronger static type checking of template arguments. So would I, but didn't see a way of getting that without limiting what could be expressed or compromising efficiency. In particularly, I was - and am - very suspicious of attempts to limit template arguments to inheritance hierarchies.
Later, Alex used the template features I designed in innovative ways that led to the STL, and to the current emphasis on generic and generative programming. Alex is alway fun to argue with! For an impression of his style, see an interview with Alex.
I experimented with ways of constraining template arguments without using language extensions. My early ideas are described in The Design and Evolution of C++ and later variations are part of the now common uses of constraints and concept checking. These systems are far more expressive and flexible than built-in facilities found in other languages. For an example, see my C++ Style and Technique FAQ.
C++ View: Jerry Schwarz reviewed the history of IOStream in the preface of the book Standard C++ IOStream and Locales. I guess that there must be many interesting stories in the process of transiting from classic stream into the standard IOStream. Can you tell us some?
Bjarne Stroustrup: I do not want to try to add to Jerry's description of the transition from my streams to the current iostreams. Instead, I'd like to emphasize that the original streams library was a very simple and very efficient library. I designed and built it in a couple of months.
The key decisions was to separate formatting from buffering, and to use the type-safe expression syntax (relying on operators << and >>). I made these decisions after discussions with my colleague Doug McIlroy at AT&T Bell Labs. I chose << and >> after experiments showed alternatives, such as < and >, comma, and = not to work well. The type safety allowed compile-time resolution of some things that C-style libraries resolve at run-time, thus giving excellent performance. Very soon after I started to use streams, Dave Presotto transparently replaced the whole buffering part of my implementation with a better one. I didn't even notice he'd done that until he later told me!
The current iostreams library will never be small, but I believe that aggressive optimization techniques will allow us to regain the efficiency of the original in the many common cases where the full generality of iostreams is not used. Note that much of the complexity in iostreams exist to serve needs that my original iostreams didn't address. For example, standard iostreams with locales can handle Chinese characters and strings in ways that are beyond the scope of my original streams.
C++ View: It's said that Java is purely object-oriented, while C# is even more. And many people say they are purely money-oriented. What's your opinion?
Bjarne Stroustrup: I like the term "money-oriented" :-) I also like Andrew Koenig's phrase "buzzword-oriented". C++ is neither.
More to the point, I don't think "purity" is a virtue. The signal strength of C++ is exactly that it supports several effective styles of programming (several paradigms, if you must), and combinations of these styles. Often, the most elegant, most efficient, and the most maintainable solution involves more than one style (paradigm). If you must use fancy words, C++ is a multi-paradigm programming language. Given the wide variety of demands in the huge area of software development, there is a need for at least one general-purpose language supporting a range of programming and design styles, and probably for more than one such language. Also, there is room for many programming languages in the world. The idea that a single language is best for every application and every programmer is absurd.
Java and C#'s main strengths are the support they receive from their owners. This implies a low price (implementations and libraries given away for free to gain market share), intensive and unscrupulous marketing (hype), and an appearance of a standard due to lack of alternative suppliers. However, when, as in the case with Java, other suppliers and revised versions eventually appear, versioning, compatibility, and portability problems re-emerge, as with other languages.
There is no substitute for formal standards, generated by an open process that is not manipulated by a language owner. A formal standards process, such as ISO's, is a user's only hope for a language that isn't jerked around for the benefit of it's owner or for the benefit of "average users" over the objections of "minorities" deemed economically unimportant.
C++ could be simpler and easier to use ("purer, if you must), but not while still supporting users with "unusual" demands. I am personally very concerned to support people building systems with demands for reliability, run-time performance, and maintainability that are far greater than the industry average. My conjecture is that over the span of a decade most programmers will face "unusual" technical requirements that will benefit from C++'s multi-paradigm structure while not being well served by "simplified" languages such as Java and C#.
I consider templates and generic programming central to modern C++. They are the keys to uncompromisingly efficient, type-safe code. However, they don't fit the classical object-oriented paradigm.
C++ View: In the book C++??: A Critique of C++ and Programming and Language Trends of the 1990s, Ian Joyner compared C++ to Java and Eiffel and criticized many mechanisms of C++. Do you agree with him? Especially, most new languages has a garbage collection mechanism. Will it be added to C++?
Bjarne Stroustrup: No. I don't agree with Ian Joyner about C++. Independently of that, garbage collection can be a valuable technique, but it is not a panacea and it can also cause problems. Automatic garbage collection is a valid implementation technique for C++. Good garbage collectors exist for C++ (both commercially supported and free) and are widely used (see links on my C++ page). However, garbage collection is optional in C++ so that applications for which GC is unsuitable, such as hard real time applications, aren't burdened by it. See my comments about GC in The C++ Programming Language (3rd Edition) and on my home pages.
I expect that the next C++ standard will explicitly state roughly what I just said above and elsewhere.
In this context, it is worth noting that C++ has support for elegant techniques for handling resources in general, and not just memory. In particular, the "resource acquisition is initialization" technique (see D&E, TC++PL3, and my technical FAQ) supports simple, exception-safe management of arbitrary resources. Since Java lacks destructors it cannot support that technique.
C++ View: STL is an excellent cross-platform framework. Have you considered designing such standard frameworks on other aspects, GUI for example?
Bjarne Stroustrup: Naturally. Many have wondered how to replicate STL's success in other areas. For example, interesting work has been done in numerics and for graphs. See my C++ page for links.
A standard GUI would be of immense value, but I doubt that it is politically feasible. Too many rich companies have serious commercial interests in maintaining their proprietary GUIs. Also, users cannot easily change from what they are currently using.
What I refer to is what is commercially and technically feasible. There are several very widely used GUIs. They won't just go away if a standards committee decided on an alternative. Their owners and their users would - often for good reasons - simply ignore a new standard. Worse: some company or group of people might actively oppose such a standard because they considered it inferior to what they already had or simply too different for a switch to the new GUI to be feasible. It is important to understand that if a standard doesn't adequately serve its intented user, then those users will simply ignore them. Many ISO standards are irrelevant because nobody follow them. The C++ standard is not one of those - it is doing immeasurable good by pulling the implementations closer together - and we don't want the ISO C++ standard to be an ignored standard in the future.
Note that one major reason that the STL succeeded was that it was a technical breakthrough. It wasn't simply "yet another container library", so it didn't have to compete directly against the many existing container libraries (several of which were of excellent quality). My guess is that for C++ to get a standard GUI, we need a technical breakthrough plus a lot of luck.
However, I still doubt that the committee has the technical expertise and the resources necessary to produce a GUI that could become a real standard in the real world.
My thoughts for the standard library goes more towards filling in gaps in the current library (e.g. hash_map and regular expressions) and support for distributed computing through more extensive (optional) run-time type information and concurrency libraries.
People sometime forget that a library doesn't have to be part of the standard to be useful. There are thousands of useful C++ libraries. For example, see the C++ libraries FAQ.
C++ View: Generic programming is a special paradigm in C++. What do you thinking of GP and OO? Will C++ provide more powerful mechanisms to support GP in the future? And have you considering importing other paradigms, pattern-oriented for example?
Bjarne Stroustrup: I think that object-oriented programming and generic programming complements each other nicely in C++, and many of my most elegant pieces of code relies on combinations of the two. That is, it is wrong to think of OOP and GP as completely distinct paradigms. They are techniques that should be used in combination, and a language should support such combinations - as C++ does.
I think that C++ supports generic programming rather well, so that it needs only minor additions. An obvious example is templated typedefs. We have to be careful to extend the language only where extensions provide major advantages in what can be expressed. For example, I don't support ideas of direct language support for template argument constraints checking. We can already do more with constraints/concept checking templates than could be done with the various language extensions proposed for C++ and similar languages.
I'm very reluctant to talk about "paradigms" and "new paradigms" - very few ideas deserve such fancy terms. I also worry that too direct support of new ideas can be limiting and failing to cater for further evolution of our ideas and our techniques. Ideally, language facilities should support very general ideas efficiently so that people can use those facilities to write code in a variety of styles. I think that it remains to be seen what patterns ideas can and cannot be supported elegantly through a combination of styles already supported in C++. I suspect that very few new language concepts are needed specifically to support patterns.
C++ View: Will C++ support the disturbed development later? And what about further support for RTTI and multi-thread?
Bjarne Stroustrup: Yes. If things progress as I hope they will, the next revision of the C++ standard will support distributed computing through the provision of extended type information and concurrency-support libraries. I do not think this will require specific language extensions. Making additional guarantees about the implementation of existing language facilities in the presence of concurrency will be needed, though.
There is not much that I can add to that now, because the discussions about what should and should not be in the next standard have just started. My view is that C++ need a standard library that seemlessly support threads (within a single address space), processes (with separate address spaces), and remote processes (where communication delays can be significant and where a network may become separated for a while). Supporting this will require facilities beyond simple Unix or Windows threads. However, I don't think it need involve new language primitives.
C++ View: Recently a new project called YASLI which stands for "Yet Another Standard Library Implementation" has been started, that intents to be the new generation of C++ Standard Library implementation. What do you think about it?
Bjarne Stroustrup: I don't know enough about that project to have an opinion.
C++ View: It's believed that great men would show their differences against others when they are young. So what differences did you show when studying in the universities?
Bjarne Stroustrup: I'm not sure anyone considered me as significantly different from others. I suspect that I was a bit more naive and idealistic than most. I also spent more time working of practical problems than most - to earn money to avoid getting into debt. Not building up debt was important for me because I don't come from a rich family. I have been told that I worked hard. On the other hand, I tended to work on a variety of things that interested me (including philosophy and history) rather than just on things that directly helped me finish my degree or improve my grades.
C++ View: Do you like reading Andersen's fairy stories? He wrote something about China in the story of The Nightingale. So what's your impression about China, the Chinese culture and the Chinese people? Have you ever been to China before? Maybe visiting China for the Olympics in 2008 would be a good idea.
Bjarne Stroustrup: As a Dane, I naturally know Hans Christian Andersen's tales. I also happen to like them. The China described in "The Nightingale" is a fiction that may or may not have anything to do with the China that then existed. Andersen created that "China" to be able to make universal points about countries and their rulers.
It is hard to have one impression about something as huge as China. The Chinese that I have met are mostly programmers or engineers, so I probably have a misleadingly narrow view of Chinese people. Even a small country and culture as my native Denmark is too complex for any individual to fully comprehend - and there are only 5 million Danes. I have a strong interest in history, so I have read several books on Chinese history and culture. However, that implies that ancient China may loom larger in my mind than it should compared to modern China. I lectured in Taiwan for a week and enjoyed my stay there, but I have not yet had the opportunity to visit the mainland.
I have read many books about Chinese history and culture. Because of the length of Chinese history and the size of China, most focus on events, people, and traditions of earlier times, and hardly any describe China as it has been for the last ten or 20 years. I know from the news and from Chinese friends that major changes have happened and that my ignorance of current-day China is immense (though probably not as immense as most people's ignorance about far-away countries). For example, I have no idea of current Chinese literature or music. Thus, when I think of China, some of what I think may be seriously out of date - despite the care I obviously take to avoid such mistakes. By the way, I have similar problems for other regions of the world that I also know of primarily from books.
I'm not keen on huge crowds and organized mass events, so I'll stay far away from the 2008 Olympics, just as I stayed away from every other Olympic games that I might have attended. I hope to find some other time to visit China.