The early development of
C++ and its transition from
C with Classes was, in a way, a rather
informal process between Stroustrup, his peers and the users. There was never a
design commitee, or a
design paper - the
design,
documentation and
implementation all went on at the same time (the next time your
boss or
teacher insists on massive amounts of
planning and
design, tell him/her about
C++).
C with Classes eventually became known as C++ through a somewhat long process. At first, the management at Bell Labs requested the language be named C84, because people had taken to referring to C with Classes as "new C" and later just "C". This led to them calling traditional C "old C", which was considered insulting.
The name C84 was eventually dropped because, well, it sucked. It was ugly and institutional, and this was exactly the image Stroustrup didn't want for his new language. The name C++ was eventually picked because it had meaning within the language and was generally a nice pun-type thing.
Although, as noted, no formal design took place for C++, Stroustrup details in his book The Design and Evolution of C++ the general rules he kept in mind while implementing C++. He hastens to point out, however, that where practical experience and rule disagreed, practical experience always won. He was keen to create a language that was of genuine use in solving real-world programs, not an academic plaything.
Aims of C++:
- C++ should make programming enjoyable for serious programmers.
- C++ should be a general-purpose language that improves on C, supports data abstraction, and supports object orientation.
General rules for the evolution of C++:
- C++ must be useful in tackling real-world problems.
- C++ must be useful now, not several years down the line.
- C++ should not be a useless quest for perfection - sacrifices have to be made when solving real-world problems.
- Every feature must be reasonably obvious to implement, so potential compiler implementators are not discouraged.
- When adding a new feature or changing an existing one, a transition path should always be provided.
- Programmers should not be forced to do things what is considered the "right" way, but should have freedom to do as they wish.