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 run-time overhead compared to C. The explicit aim was to match C in terms of run-time, code compactness, and data compactness. To wit: Someone once demonstrated a 3% systematic decrease in overall run-time efficiency compared with C caused by the use of a spurious temporary introduced into the function return mechanism by the C with Classes preprocessor. This was deemed unaccpetable and the overhead promptly removed. Similarly, to ensure layout compatibility with C and thereby avoid space overhead, no "houskeeping data" was placed int class objects.
Another major concern was to avoid restrictions on the domain where C with Classes could be used. The ideal - which was achieved - was 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/principle had to be repeated often to people (rarely C with Classes users) who wanted C with Classes made safter by increasing static type checking along the lines of early Pascal. The alternative way of providing "safety," inserting run-time 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 run-time and space efficiency. Consequently, such checks were not provided for C with Classes, although some C++ environments do provide such checks for debugging. In addition, users can and do insert run-time checks where needed and affordable.
C allows low-level opperations, 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 Clases 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 and performs unsafe operations only at the explicit request of the programmer. 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 varietly of styles and practices that have proven effective and to provide language features and tools to help programmers avoid the well-known traps and pitfalls.
