Previous | Table of Contents | Next |
An early description of C with Classes was published as a Bell Labs technical report in April 1980 (Stroustrup, 1980a) and later in SIGPLAN Notices. The SIGPLAN paper was followed in April 1982 by a more detailed Bell Labs technical report Adding Classes to the C Language: An Exercise in Language Evolution (Stroustrup, 1982) that was later published in Software: Practice and Experience. These papers set a good example by describing only features that were fully implemented and had been used. This was in accordance with a long-standing tradition of Bell Labs Computing Science Research Center. That policy was modified only where more openness about the future of C++ became necessary to ensure a free and open debate over the evolution of C++ among its many non-AT&T users.
C with Classes was explicitly designed to allow better organization of programs; computation was considered a problem solved by C. I was very concerned that improved program structure was not achieved at the expense of runtime overheads compared to C. The explicit aim was to match C in terms of runtime, code compactness, and data compactness. To wit: Someone once demonstrated a 3% systematic decrease in overall runtime efficiency compared with C. This was considered unacceptable, and the overhead was promptly removed by compiler improvements. Similarly, to ensure layout compatibility with C and thereby avoid space overheads, no housekeeping data was placed in class objects.
Another major concern was to avoid restrictions on the domain where C with Classes could be used. The idealwhich was achievedwas that C with Classes could be used for whatever C could be used for. This implied that in addition to matching C in efficiency, C with Classes could not provide benefits at the expense of removing dangerous or ugly features of C. This observation or principle had to be repeated often to people (rarely C with Classes users) who wanted C with Classes made safer by increasing static type checking along the lines of early Pascal. The alternative way of providing safety, inserting runtime checks for all unsafe operations, was (and is) considered reasonable for debugging environments, but the language could not guarantee such checks without leaving C with a large advantage in runtime and space efficiency. Consequently, such checks were not provided for C with Classes, although C++ environments exist that provide such checks for debugging. In addition, users can and do insert runtime checks (assertions; Stroustrup, 1997) where needed and affordable.
C allows quite low-level operations such as bit manipulation and choosing between different sizes of integers. There are also facilities, such as explicit unchecked type conversions, for deliberately breaking the type system. C with Classes, and later C++, follow this path by retaining the low-level and unsafe features of C. In contrast to C, C++ systematically eliminates the need to use such features except where they are essential. C++ provides facilities that allow a programmer to avoid unsafe operations except through explicit requests. I strongly felt then, as I still do, that there is no one right way of writing every program and a language designer has no business trying to force programmers to use a particular style. The language designer does, on the other hand, have an obligation to encourage and support a variety of styles and practices that have been proven effective and to provide language features and tools to help programmers avoid the well-known traps and pitfalls.
The features provided in the initial 1980 implementation can be summarized as follows:
During 1981, three more features were added
Because a preprocessor was used for the implementation of C with Classes: only new featuresthat is, features not present in Cneeded to be described and the full power of C was directly available to users. Both of these aspects were appreciated at the time. Having C as a subset dramatically reduced the support and documentation work needed. This was most important because for several years I handled all the C with Classes and later C++ documentation and support in addition to doing the experimentation, design, and implementation. Having all C features available further ensured that no limitations introduced through prejudice or lack of foresight on my part would deprive a user of features already available in C. Naturally, portability to machines supporting C was ensured. Initially, C with Classes was implemented and used on a DEC PDP/11, but soon, it was ported to machines such as DEC VAX and Motorola 68000-based machines.
C with Classes was still seen as a dialect of C. Furthermore, classes were referred to as An Abstract Data Type Facility for the C Language (Stroustrup, 1980a). Support for object-oriented programming was not claimed until the provision of virtual functions in C++ in 1983 (Stroustrup, 1984a).
Previous | Table of Contents | Next |