Previous Table of Contents Next


6.2.4.9. Features Considered but Not Provided

In the early days, many the features were considered that later appeared in C++ or are still discussed. These included virtual functions, static members, templates, and multiple inheritance. However, “All of these generalizations have their uses, but every feature of a language takes time and effort to design, implement, document, and learn.…The base class concept is an engineering compromise, like the C class concept” (Stroustrup, 1982). I just wish I had explicitly mentioned the need for experience. With that, the case against featurism and for a pragmatic approach would have been complete.

The possibility of automatic garbage collection was considered on several occasions before 1985 and deemed unsuitable for a language already in use for real-time processing and hard-core systems tasks such as device drivers. In those days, garbage collectors were less sophisticated than they are today, and the processing power and memory capacity of the average computer were small fractions of what today’s systems offer. My personal experience with Simula and reports of other GC-based systems convinced me that GC was unaffordable by me and my colleagues for the kind of applications we were writing. Had C with Classes (or even C++) been defined to require automatic garbage collection, it would have been more elegant but stillborn.

Direct support for concurrency was also considered but rejected in favor of a library-based approach (see section 6.2.2).

6.2.5. The C with Classes Work Environment

I designed and implemented C with Classes as a research project in the Computing Science Research Center of Bell Labs. This center provided a possibly unique environment for such work. When I joined, I was basically told to “do something interesting,” given suitable computer resources, encouraged to talk to interesting and competent people, and given a year before having to formally present my work for evaluation.

There was a cultural bias against “grand projects” requiring many people, against “grand plans” such as untested paper designs for others to implement, and against a class distinction between designers and implementers. If you liked such things, Bell Labs and others have many places where you could indulge such preferences. However, in the Computing Science Research Center, it was almost a requirement that you—if you were not into theory—(personally) implement something embodying your ideas and find users who could benefit from what you built. The environment was very supportive of such work and the Labs provided a large pool of people with ideas and problems to challenge and test anything built. Thus I could write in The C++ Programming Language (Stroustrup, 1986a):

There never was a C++ paper design; design, documentation, and implementation went on simultaneously. Naturally, the C++ front end is written in C++. There never was a C++ project either, or a C++ design committee. Throughout, C++ evolved, and continues to evolve, to cope with problems encountered by users and through discussions between the author and his friends and colleagues.

Only after C++ was an established language did more conventional organizational structures emerge. And even then I was officially in charge of the reference manual and had the final say over what went into it until that task was handed over to the ANSI C++ committee in early 1990. On the other hand, after the first few months I never had the freedom to design just for the sake of designing something beautiful or to make arbitrary changes in the language as it stood at any given time. Whatever I considered a language feature required an implementation to make it real. Furthermore, any change or extension required the concurrence and usually the enthusiasm of key C with Classes and later C++ users.

Because there was no guaranteed user population, the language and its implementations could survive only by serving the needs of its users well enough to counteract the organizational pull of established languages and the marketing hype of newer languages.

C with Classes grew through discussions with people in the Computing Science Research Center and early users there and elsewhere in the Labs. Most of C with Classes and later C++ was designed on somebody else’s blackboard and the rest on mine. Most ideas were rejected as too elaborate, too limited in usefulness, too hard to implement, too hard to teach for use in real projects, not efficient enough in time or space, too incompatible with C, or simply too weird. The few ideas that made it through this filter—invariably involving discussions among at least two people—I then implemented. Typically, the idea mutated through the effort of implementation, testing, and early use by me and one or two others. The resulting version was tried on a larger audience and would often mutate a bit further before finding its way into the “official” version of C with Classes as shipped by me. Usually, a tutorial was written somewhere along the way. I considered a tutorial an essential design tool because if a feature cannot be explained simply, the burden of supporting it will be too great. This point was never far from my mind because during the early years, I was the support organization.

In the early days, Sandy Fraser, my department head at the time, was very influential. For example, I believe he was the one who encouraged me to break from the Simula style of class definition, where the complete function definition is included, and adopt the style where function definitions are typically elsewhere, thus emphasizing the class declaration’s role as an interface. Much of C with Classes was designed to allow simulators to be built that could be used in Sandy Fraser’s work in network design. The first real application of C with Classes was such network simulators. Sudhir Agrawal was another early user who influenced the development of C with Classes through his work with network simulations. Jonathan Shopiro provided much feedback of the C with Classes design and implementation based on his simulation of a “dataflow database machine.”


Previous Table of Contents Next