2015, October 14th
I don’t know if it was important, but it seemed a good idea at the time. Both AT&T and Addison-Wesley asked me when would be a good release day, so I told them October 14 because I was giving a talk at the ACM conference and could announce it there.
It was a necessary book. The tiny, but growing, community needed it. It wasn’t even my own idea to write it. Al Aho, then my neighbor at Bell Labs, pointed out that need. I completely underestimated the amount of work needed to write The C++ Programming Language. Writing clearly on new topic is hard. I did learn a fair bit about C++ by trying to explain it to people. C++ was improved to simplify my explanations by making the language more logical or more capable. Writing a tutorial is an effective design technique.
I don’t remember. In fact, I don’t remember all that much from the 1980s. That was a very busy time for me. From 1979 to 1991 the number of C++ programmers doubled every 7.5 month. Such growth generates a lot of work. Today, the number of C++ users is estimated to 4.4 million (JetBrains survey). It was a big day for me, but the only thing I remember is getting the first copy of my 1st edition.
I did learn a fair bit about C++ by trying to explain it to people.
Obviously, I did not predict C++’s enormous, and occasionally explosive growth. I was focused on improving the language, on figuring out how to write libraries, on improving the compiler, and on explaining how to use it all.
On the other hand, most of what we see in C++ today has deep roots into the early days. Classes, function declarations (function prototypes), constructors, and destructors were part of the very first design. I included inline functions and overloaded assignments a couple of years later. The distinction between initialization and assignment was there. General overloading of operators came a bit later (1983 or so) together with virtual functions. People often forget that parameterized types were there from the start. I used a vector macro with the element type as a macro parameter from the earliest days and Cfront shipped with a <generic.h> header. For a couple of years, I thought macros would be enough to support generic programming. I was very wrong about that, but I was right about the need to parameterize types and functions with (other) types. The result became templates (1988).
The basic idea was to extend the language with facilities allowing users to define powerful, elegant, and efficient abstractions. This contrasts with the idea of supporting application-specific abstractions directly in the language. To this day, C++ has C’s basic machine model to allow efficient and reasonable portable use of hardware. We are also still working on incremental improvements of C++’s support for efficient abstraction.
Most of what we see in C++ today has deep roots into the early days. [...] People often forget that parameterized types were there from the start
Gratifying and a bit scary. It is good to have done something that proved useful to many, but it is also a great responsibility – especially as the language evolves. If we add good and useful features to the language, we have done some good for the world, but if we mess up, we can do great harm. So far, I think that the evolution of C++ has been a sequence of improvements. Not every features has been a success, but most have been very helpful to many and the failures have not been fatal. Each year C++ has become a better tool. Today’s C++ is immensely more useful than the 1985 release 1.0. We can write much more elegant code today and it runs faster (even if you take the difference in hardware performance into account).
The reason for the success? There must be many. To succeed, a language must be reasonably good at just about anything its users need and must not fail completely at anything. It is not enough to be best in the world at one or two things. Fundamentally, C++ addressed and still addresses critical issues in systems where performance and hardware access are critical (e.g., “systems programming”), and especially for systems where complexity needs to be managed. Secondly, C++ was carefully and gradually evolved in response to real-world problems; it grew. It was never an “Ivory tower project.” Finally, I think it is important that C++ isn’t fueled by hype: I made comparatively modest promises and kept them.
C++ was carefully and gradually evolved in response to real-world problems; it grew. It was never an “Ivory tower project.”
I tried to get out of developing C++ a few times, but it always dragged me back. I feel that working with C++ is my best chance of making a significant contribution. Thus, C++ is my main tool for research and development. The lessons learned – by me and by many others in the C++ community – are then fed back into the language and its libraries where they can benefit millions.
I have of course dreamed of designing a new and better language, but it takes a long time for a language to develop from a set of ideas to a useful tool. It is hard to compete with C++ on its own turf, and my main interests are in areas where C++ is a good tool. Also, most new languages fail. It is easy to make mistakes when designing from scratch. A successful large system is almost always derived from a smaller working system.
It is hard to integrate an idea in a large language like C++ with complexities from its long evolution, but once the idea is supported by C++, it can be used by millions rather than the few hundreds who could benefit from the early versions of a new language.
I tried to get out of developing C++ a few times, but it always dragged me back. [...] It is easy to make mistakes when designing from scratch. A successful large system is almost always derived from a smaller working system.
The machine model and the wish for better support for abstraction are unchanged are as relevant as ever. So is my emphasis on the use of a static (compile-time) type system.
The use of exceptions and templates have radically improved how we can write elegant and efficient code. Both were first mentioned as possible directions for C++ in a paper I wrote for IEEE Software in 1986. Exception together with constructors and destructors gave us resource safety (RAII). Templates allowed Alex Stepanov’s STL and his ideas of generic programming to thrive. Just this year, we got direct language support for concepts to complete C++’s template facilities.
In the late 1980s, people were over-excited about the use of class hierarchies. I was rather more interested in blending different programming styles into a coherent whole. My 1st edition (deliberately) didn’t even use the term “Object-Oriented Programming” and I was giving talks with titles such as “C++ is not just an object-oriented programming language”. Later, people got over-excited about the use of templates in the form of generic programming and template meta-programming, sometimes for getting that simple solution are often the best. I am still looking for ways to articulate my notion of elegant programming based on a synthesis of language features and library facilities.
One very recent thing that I suspect will be very important over the next few years is an effort to develop a set of tool and library coding guidelines. This will make it far easier for the C++ community to effectively use new facilities. One really new aspect of this is that we have tools that can eliminate dangling pointers, opening the possibility of completely type-and resource-safe C++ programs. In particular, we eliminate all resource leaks without using a garbage collector (because we don’t generate any garbage), so we don’t suffer any loss of performance despite the increased safety. We don’t restrict what C++ can be used for either.
In the late 1980s, people were over-excited about the use of class hierarchies [...] and I was giving talks with titles such as “C++ is not just an object-oriented programming language”. [...] Later, people got over-excited about the use of templates.
I hope that this can help fight a problem that has plagued C++ forever: Poor teaching and poor understanding of C++ even among its practitioners. There has always been a tendency to describe C++ as some odd variant of something else. For example, C++ is still frequently taught as “a few features added to C” or as “an unsafe Java with a few modern features missing.” This does enormous harm to actual C++ use. My new A Tour of C++ might also help. I describes all of C++ and its standard library at a fairly high level in fewer pages than K&R; uses for C. It is aimed at people who are already programmers, rather than for complete novices.
I suspect that I’ll have a better idea of what C++17 will be after next week’s standards meeting in Kona [Hawaii]. But I’m (still) and optimist. C++11 was a great improvement over C++98 and I expect C++17 to be an improvement of similar magnitude over C++11.
I hope to see: