Previous | Table of Contents | Next |
For more general discussionson programming language issues, as opposed to looking at applications to determine which problems needed to be solved, I turned to Dennis Ritchie, Steve Johnson, and, in particular, Doug McIlroy. Doug McIlroys influence on the development of both C and C++ cannot be overestimated. I cannot remember a single critical design decision in C++ that I have not discussed at length with Doug. Naturally, we didnt always agree, but I still have a strong reluctance to make a decision that goes against Dougs opinion. He has a knack for being right and an apparently infinite amount of experience and patience.
Because the main design work for C with Classes and C++ was done on blackboards, the thinking tended to focus on solutions to archetypical problems: small examples that are considered characteristic for a large class of problems. Thus, a good solution to the small example provides significant help in writing programs dealing with real problems of that class. Many of these problems have entered the C++ literature and folklore through my use of them as examples in my papers, books, and talks. For C with Classes, the example considered most critical was the task class that was the basis of the task-library supporting Simula-style simulation. Other key classes were queue, list, and histogram classes. The queue and list classes were based on the ideaborrowed from Simulaof providing a link class from which users derived their own classes.
The danger inherent in this approach is creating a language and tools that provide elegant solutions to small selected examples, yet dont scale to building complete systems or large programs. This was counteracted by the simple fact that C with Classes (and later C++) had to pay for itself during its early years. This ensured that C with Classes couldnt evolve into something that was elegant but useless.
During 1982, it became clear to me that C with Classes was a medium success and would remain so until it died. I defined a medium success as something so useful that it easily paid for itself and its developer, but not so attractive and useful that it would pay for a support and development organization. Thus, continuing with C with Classes and its C preprocessor implementation would condemn me to support C with Classes use indefinitely. I was convinced that there were only two ways out of this dilemma:
The third alternative, increasing the user population through marketing (hype), never occurred to me. What actually happened was that the explosive growth of C++, as the new language was eventually named, kept me so busy that to this day, I havent managed to get sufficiently detached to do something else of significance.
The success of C with Classes was, I think, a simple consequence of meeting its design aim: C with Classes did help organize a large class of programs significantly better than C without the loss of runtime efficiency and without requiring enough cultural changes to make its use infeasible in organizations that were unwilling to undergo major changes. The factors limiting its success were partly the limited set of new facilities offered over C and partly the preprocessor technology used to implement C with Classes. There simply wasnt enough support in C with Classes for people who were willing to invest significant efforts to reap matching benefits; C with Classes was an important step in the right direction, but only one small step. As a result of this analysis, I began designing a cleaned-up and extended successor to C with Classes and implementing it using traditional compiler technology.
The resulting language was at first still called C with Classes, but after a polite request from management, it was given the name C84. The reason for the naming was that people had taken to calling C with Classes new C and then C. This last abbreviation led to C being called plain C, straight C, and old C. The name C84 was used only for a few months, partly because it was ugly and institutional, partly because there would still be confusion if people dropped the 84. I asked for ideas for a new name and picked C++ because it was short, had nice interpretations, and wasnt of the form adjective C. C++ can, depending on context, be read as next, successor, or increment, although it is always pronounced plus plus. The name C++ and its runner-up ++C are fertile sources for jokes and punsalmost all of which were known and appreciated before the name was chosen. The name C++ was suggested by Rick Mascitti. It was first used in Data Abstraction in C (Stroustrup, 1984b), where it was edited into the final copy in December 1983.
Previous | Table of Contents | Next |