C++: Interview with Bjarne Stroustrup

Bjarne Stroustrup is currently the College of Engineering Chair and Computer Science Professor at Texas A&M University, and is an AT&T labs fellow. We chat to him about the design and development of C++, garbage collection and the role of facial hair in successful programming languages.

What prompted the development of C++?

 I needed a tool for designing and implementing a distributed version of the Unix kernel. At the time, 1979, no such tool existed. I needed something that could express the structure of a program, deal directly with hardware, and be sufficiently efficient and sufficiently portable for serious systems programming. You can find more detailed information about the design and evolution of C++ in my HOPL (History of Programming Languages) papers, which you can find on my home pages (http://www.research.att.com/~bs), and in my book The Design and Evolution of C++.

Was there a particular problem you were trying to solve? 

The two problems that stick in my mind were to simulate the inter-process communication infrastructure for a distributed or shared-memory system (to determine which OS services we could afford to run on separate processors), and [the need] to write the network drivers for such a system. Obviously – since Unix was written in C – I also wanted a high degree of C compatibility. Very early, 1980 onwards, it was used by other people (helped by me) for simulations of various network protocols and traffic management algorithms.

 Where does the name C++ come from? 

As C with Classes (my ancestor to C++) became popular within Bell Labs, some people found that name too much of a mouthful and started to call it C. This meant that they needed to qualify what they meant when they wanted to refer to Dennis Ritchie’s language, so they used ‘Old C,’ ‘Straight C,’ and such. Somebody found that disrespectful to Dennis (neither Dennis nor I felt that) and one day I received a request though Bell Labs management channels to find a better name. As a result, we referred to C++ as C84 for a while. That didn’t do much good, so I asked around for suggestions and picked C++ from the resulting list. Everybody agreed that semantically ++C would have been even better, but I thought that would create too many problems for non-geeks.

 Were there any particularly difficult or frustrating problems you had to overcome in the development of the language? 

Lots! For starters, what should be the fundamental design rules for the language? What should be in the language and what should be left out? Most people demand a tiny language providing every feature they have ever found useful in any language. Unfortunately, that’s impossible. After a short period of relying on luck and good taste, I settled on a set of rules of thumb intended to ensure that programs in C++ could be simultaneously elegant (as in Simula67, the language that introduced object-oriented programming) and efficient for systems programming (as in C). Obviously, not every program can be both and many are neither, but the intent was (and is) that a competent programmer should be able to express just about any idea directly and have it executed with minimal overheads (zero overheads compared to a C version). Convincing the systems programming community of the value of type checking was surprisingly hard. The idea of checking function arguments against a function declaration was fiercely resisted by many – at least until C adopted the idea from C with Classes. These days, object-oriented programming is just about everywhere, so it is hard for people to believe that I basically failed to convince people about it’s utility until I finally just put in virtual functions and demonstrated that they were fast enough for demanding uses. C++’s variant of OOP was (and is) basically that of Simula with some simplifications and speedups. C compatibility was (and is) a major source of both problems and strengths. By being C compatible, C++ programmers were guaranteed a completeness of features that is often missing  in first releases of new languages and direct (and efficient) access to a large amount of code – not just C code, but also Fortran code and more because the C calling conventions were simple and similar to what other languages supported. After all, I used to say, reuse starts by using something that already exists, rather than waiting for someone developing new components intended for reuse. On the other hand, C has many syntactic and semantic oddities and keeping in lockstep with C as it evolved has not been easy.

What are the main differences between the original C with Classes and C++?

 Most of the differences were in the implementation technique. C with Classes was implemented by a preprocessor, whereas C++ requires a proper compiler (so I wrote one). It was easy to transcribe C with Classes programs into C++, but the languages were not 100% compatible. From a language point of view, the major improvement was the provision of virtual functions, which enabled classical object-oriented programming. Overloading (including operator overloading) was also added, supported by better support for inlining. It may be worth noting that the key C++ features for general resource management, constructors and destructors, were in the earliest version of C with Classes. On the other hand, templates (and exceptions) were introduced in a slightly later version of C++ (1989); before that, we primarily used macros to express generic programming ideas.

Would you have done anything differently in the development of C++ if you had the chance? 

This common question is a bit unfair because of course I didn’t have the benefits of almost 30 years of experience with C++ then, and much of what I know now is the result of experimentation with the earlier versions of C++. Also, I had essentially no resources then (just me – part time) so if I grandly suggest (correctly) that virtual functions, templates (with concepts similar to what C++0x offers), and exceptions would have made C++85 a much better language, I would be suggesting not just something that I didn’t know how to design in the early 1980s but also something that – if I magically had discovered the perfect design – couldn’t have been implemented in a reasonable time. I think that shipping a better standard library with C++ 1.0 in 1985 would have been barely feasible and would have been the most significant improvement for the time. By a ‘better library’ I mean one with a library of foundation classes that included a slightly improved version of the (then available and shipping) task library for the support of concurrency and a set of container classes. Shipping those would have encouraged development of improved versions and established a culture of using standard foundation libraries rather than corporate ones. Later, I would have developed templates (key to C++ style generic programming) before multiple inheritance (not as major a feature as some people seem to consider it) and emphasized exceptions more. However, ‘exceptions’ again brings to a head the problem of hindsight. Some of the most important concepts underlying the modern use of templates on C++ did not exist until a bit later. For example the use of guarantees in describing safe and systematic uses of templates was only developed during the standardization of C++, notably by Dave Abrahams.

How did you feel about C++ becoming standardized in 1998 and how were you involved with the standardization process? 

I worked hard on that standard for years (1989-1997) – as I am now working on its successor standard: C++0x. Keeping a main-stream language from fragmenting into feuding dialects is a hard and essential task. C++ has no owner or ‘sugar daddy’ to supply development muscle, free libraries, and marketing. The ISO standard committee was essential for the growth of the C++ community and that community owes an enormous amount to the many volunteers who worked (and work) on the committee.

What is the most interesting program that you’ve seen written with C++? 

 I can’t pick one and I don’t usually think of a program as interesting. I look more at complete systems – of which parts are written in C++. Among such systems, NASA’s Mars Rovers’ autonomous driving sub-system, the Google search engine, and Amadeus’ airline reservation system spring to mind. Looking at code in isolation, I think Alexander Stepanov’s STL (the containers, iterators, and algorithms part of the C++ standard library) is among the most interesting, useful, and influential pieces of C++ code I have ever seen.

 Have you ever seen the language used in a way that was not originally intended?

 I designed C++ for generality. That is, the features were deliberately designed to do things I couldn’t possibly imagine – as opposed to enforce my views of what is good. In addition, the C++ abstraction facilities (e. g., classes and templates) were designed to be optimally fast when used on conventional hardware so that people could afford to build the basic abstractions they need for a given application area (such as complex numbers and resource handles) within the language. So, yes, I see C++ used for many things that I had not predicted and used in many ways that I had not anticipated, but usually I’m not completely stunned. I expected to be surprised, I designed for it. For example, I was very surprised by the structure of the STL and the look of code using it – I thought I knew what good container uses looked like. However, I had designed templates to preserve and use type information at compile time and worked hard to ensure that a simple function such as less-than could be inlined and compiled down to a single machine instruction. That allowed the weaving of separately defined code into efficient executable code, which is key to the efficiency of the STL. The biggest surprise, I guess, was that the STL matched all but one of a long list of design criteria for a general purpose container architecture that I had compiled over the years, but the way STL code looked was entirely unexpected. So I’m often pleased with the surprises, but many times I’m dismayed at the attempts to force C++ into a mold for which it is not suited because someone didn’t bother to learn the basics of C++. Of course, people doing that don’t believe that they are acting irrationally; rather, they think that they know how to program and that there is nothing new or different about C++ that requires them to change their habits and learn new tricks. People who are confident in that way structure the code exactly as they would for, say, C or Java and are surprised when C++ doesn’t do what they expect. Some people are even angry, though I don’t see why someone should be angry to find that they need to be more careful with the type system in C++ than in C or that there is no company supplying free and standard libraries for C++ as for Java. To use C++ well, you have to use the type system and you have to seek out or build libraries. Trying to build applications directly on the bare language or with just the standard library is wasteful of your time and effort. Fighting the type system (with lots of casts and macros) is futile.

It often feels like a large number of programmers have never really used templates, even if they are C++ programmers 

You may be right about that, but many at least – I think most – are using the templates through the STL (or similar foundation libraries) and I suspect that the number of programmers who avoid templates is declining.

Why do you think this is? 

Fear of what is different from what they are used to, rumors of code bloat, potential linkage problems, and spectacular bad error messages.

Do you ever wish the GNU C++ compiler provided shorter compiler syntax errors so as to not scare uni students away?

 Of course, but it is not all GCC’s fault. The fundamental problem is that C++98 provides no way for the programmer to directly and simply state a template’s requirements on its argument types. That is a weakness of the language – not of a complier – and can only be completely addressed through a language change, which will be part of C++0x. I’m referring to concepts which will allow C++0x programmers to precisely specify the requirements of sets of template arguments and have those requirements checked at call points and definition points (in isolation) just like any other type check in the language. For details, see any of my papers on C++0x or Concepts: Linguistic Support for Generic Programming in C++ by Doug Gregor et al (including me) from OOPSLA’06 (available from my publications page). An experimental implementation can be downloaded from Doug Gregor’s home pages (http://www.osl.iu.edu/~dgregor).