Computerworld Australia is undertaking a series of investigations into the most widely used programming languages. Previously, we have spoken to Alfred v. Aho of AWK fame, S. Tucker Taft on the Ada 1995 and 2005 revisions, Microsoft about its server-side script engine ASP and Chet Ramey about his experience maintaining Bash.
In this interview, we chat with Bjarne Stroustrup of C++ fame about the design and development of C++, garbage collection and the role of facial hair in successful programming languages. Stroustrup is currently the College of Engineering chairman and computer science professor at Texas A&M University, and is an AT&T Labs fellow.
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 [History of Programming Languages] papers, which you can find on my home pages 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 interprocess 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 nongeeks.
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 its 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.