This was the main reason for creating a new language. The original name was "C with Classes". Stroustrup did not copy Smalltallk's O-O features for C++, but based them on the old Simula 67 language (from 1967). Smalltalk also was based on Simula 67, so that Stroustrup regards C++ as a sibling of Smalltalk and not an offspring.

The principle competitor of C++ was Objective C, another extension of C that grafted Smalltalk's features onto C, particularly the classes and message passing as communication between classes. More occurs at run-time in Objective C than in C++ -- in particular the message passing takes place at run-time. For this reason Objective C is more flexible (and perhaps easier to use) than C++, but not as efficient. Objective C was used in the very successful project to develope the upper parts of the NeXT operating system, and Objective C is still used in parts of Apple's OS X operating system, which was derived from NeXT.

C++ provides a rich set of O-O features, including most of what Java has, and even the controversial multiple inheritance.

2. A compatible extension of C:

This was a difficult goal, partly because there were many C dialects. In the end, C++ is compatible with reasonable and modern features of C, but drops some old-fashions C features, ones that today's students usually don't learn anyway. For example, old-style C function parameters are not legal in C++. They look like the following:

int funct(x, y)
  int x; double y;
{
   /* ... */
}

int funct(int x, double y)
{
   /* ... */
}

As another example, C allows a function call without an earlier prototype -- the function is assumed to return int by default. C++ requires a prototype or definition of any function before it is called.

The more-or-less compatibility was a big factor in C++'s popularity.

3. As efficient as C (almost):

It was very important to Stroustrup that C++ would execute a given C program as efficiently as C. This is major reason for the popularity of C++. Some few new features of C++ do involve a slight additional run-time overhead: polymorphism for example.

4. A "better C":

• Discourage all use of the preprocessor (except for #include).
  • Instead of constants defined by (for example) #define PI 3.141592653589793, use something like const double PI = 3.141592653589793;. (The second method gets syntax checked and type checked -- much less error prone.)
  • Instead of macros defined by (for example) #define SQR(x) (x)*(x), use a function declared inline. (This is much less error prone, and with a good compiler, it will be as efficient.)
• Various outmoded features of C actually dropped -- mostly stuff you aren't familar with anyway. (Examples mentioned under 2 above.)
• Required prototypes.
• Strong typing more rigorously enforced.
• Type-safe I/O.
• A user-defined type should look just like a built-in type.