Previous | Table of Contents | Next |
In fall 1983, my next door neighbor at work, Al Aho, suggested that I write a book on C++ structured along the lines of Brian Kernighan and Dennis Ritchies The C Programming Language and base it on my published papers, internal memoranda, and the C++ reference manual (Kernighan & Ritchie, 1978). Completing the book took nine months.
The preface mentions the people who had by then contributed most to C++: Tom Cargill, Jim Coplien, Stu Feldman, Sandy Fraser, Steve Johnson, Brian Kernighan, Bart Locanthi, Doug McIlroy, Dennis Ritchie, Larry Rosler, Jerry Schwarz, and Jon Shopiro. My criterion for adding a person to that list was that I was able to identify a specific C++ feature that he or she caused to be added.
The books opening line C++ is a general-purpose programming language designed to make programming more enjoyable for the serious programmer was deleted twice by reviewers who refused to believe that the purpose of programming-language design could be anything but some serious mutterings about productivity, management, and software engineering. However, C++ was designed primarily so that the author and his friends would not have to program in assembler, C, or various modern high-level languages. Its main purpose is to make writing good programs easier and more pleasant for the individual programmer (Stroustrup, 1991). This was the case whether those reviewers were willing to believe it or not. The focus of my work is the person, the individual (whether part of a group or not), the programmer. This line of reasoning has been strengthened over the years and is even more prominent in the Second Edition (Stroustrup, 1991).
The C++ Programming Language (Stroustrup, 1986a) was the definition of C++ and the introduction to C++ for an unknown number of programmers, and its presentation techniques and organization (borrowed with acknowledgments if not always sufficient skill from The C Programming Language) have become the basis for an almost embarrassingly large number of articles and books. It was written with a fierce determination not to preach any particular programming technique. In the same way as I feared to build limitations into the language out of ignorance and misguided paternalism, I didnt want the book to turn into a manifesto for my personal preferences.
Having shipped Release 1.0 and sent the camera-ready copy of the book to the printers, I finally found time to reconsider larger issues and to document overall design issues. Just then Karel Babcisky (the chairman of the Association of Simula Users) phoned from Oslo with an invitation to give a talk on C++ at the 1986 ASU conference in Stockholm. Naturally, I wanted to go, but I was worried that presenting C++ at a Simula conference would be seen as a vulgar example of self advertisement and an attempt to steal users away from Simula. After all, I said, C++ is not Simula, so why would Simula users want to hear about it? Karel replied Ah, we are not hung up on syntax. This provided me with an opportunity to write not only about what C++ was, but what it was supposed to be and where it didnt measure up to those ideals. The result was the paper What Is Object-Oriented Programming? (Stroustrup, 1986c) that I presented to the ASU conference in Stockholm.
The significance of this paper is that it is the first exposition of the set of techniques that C++ was aiming to support. All previous presentations, to avoid dishonesty and hype, had been restricted to describe what features were already implemented and in use. The What Is? paper defined the set of problems I thought a language supporting data abstraction and object-oriented programming ought to solve and gave examples of language features needed.
The result was an affirmation of the importance of the multiparadigm nature of C++ (Stroustrup, 1986c):
Object-oriented programming is programming using inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction. These techniques need proper support to be effective. Data abstraction primarily needs support in the form of language features, and object-oriented programming needs further support from a programming environment. To be general purpose, a language supporting data abstraction or object-oriented programming must enable effective use of traditional hardware.
The importance of static type checking was also strongly emphasized. In other words, C++ follows the Simula rather than the Smalltalk model of inheritance and type checking (Stroustrup, 1986):
A Simula or C++ class specifies a fixed interface to a set of objects (of any derived class), whereas a Smalltalk class specifies an initial set of operations for objects (of any subclass). In other words, a Smalltalk class is a minimal specification and the user is free to try operations not specified, whereas a C++ class is an exact specification and the user is guaranteed that only operations specified in the class declaration will be accepted by the compiler.
This has deep implications for the way you design systems and for what language facilities are needed. A dynamically typed language such as Smalltalk simplifies the design and implementation of libraries by postponing type checking to runtime. Heres an example (using C++ syntax):
stack cs; cs.push(new Saab900); cs.pop()->takeoff(); // Oops! Run time error: // a car does not have a takeoff method.
This delayed type-error detection was considered unacceptable for C++, yet there had to be a way of matching the notational convenience and the standard libraries of a dynamically typed language. The notion of parameterized types was presented as the (future) solution for that problem in C++:
stack(plane*) cs; cs.push(new Saab37b); // ok a Saab37b is a plane cs.push(new Saab900); // error, type mismatch: car passed, plane* expected cs.pop()->takeoff(); // no run-time check needed cs.pop()->takeoff(); // no run-time check needed
Previous | Table of Contents | Next |