OK, I confess. I didn't change anything in the proof. But how can anyone reviewing that
complicated text be sure one way or the other? Program proofs are not practical because
most programmers find them too inaccessible.
Chapter 11. You Know C, So C++ is Easy!
C++ will do for C what Algol-68 did for Algol. [1]
—David L. Jones
[1] Algol-68 was a monster-sized language that built on the small and successful Algol-60. It
was hard to understand (it had a formal specification written in denotational semantics), hard
to implement, and hard to use. But it was "very powerful" or so everyone said. Algol-68
effectively killed Algol-60 by replacing it, before self-destructing in a wave of impracticality.
Some people see parallels between the two Algols and the two C's.
If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual
private destructor, and when was the last time you needed one?
—Tom Cargill, C++ Journal, Fall 1990
allez-OOP!...abstraction—extracting out the essential characteristics of a thing...encapsulation—grouping together related types, data, and functions...showing
some class—giving user-defined types the same privileges as predefined types...constructors and destructors...inheritance—reusing operations that are already
defined...multiple inheritance—deriving from two or more base classes...overloading—having one name for the same action on different types...input/output in
C++...polymorphism—runtime binding...other corners of C++...if I was going there, I wouldn't start from here...it may be crufty, but it's the only game in
town...some light relief—the dead computers society
Allez-OOP!
You know C, so C++ is easy, right? Well, maybe. Most C++ books are three or four hundred pages of
densely packed text. It's easy to get lost in a forest of detail, and not be able to see the semantic wood
for the binary trees. On the other hand, for most practical purposes C++ is a superset of ANSI C.
Some of the places where it's not are listed in a table at the end of this chapter. But to benefit from the
language, or even understand it fully, you have to understand the underlying concepts. This is what
people mean when they talk about the "object-oriented paradigm" and the "shift in thinking" needed to
program in C++. We strip away the mystique, and describe C++ in simple English, relating it to
familiar C features.
It's similar to the window-interface paradigm, when we learned to rewrite our programs for the
window system point of view. The control logic was turned inside-out to cope with
window_main_loop. Object-oriented programing is in the same vein, but rewriting for the datatype
point of view.
Object-Oriented Programming (OOP) is not a new idea; the concept has been around since Simula-67
pioneered it more than a quarter of a century ago. Object-oriented programming (naturally) involves
the use of objects as the central theme. There are lots of ways to define a software object; most of
them agree that a key element is grouping together data with the code that processes it, and having
some fancy ways of treating it as a unit. Many programming languages refer to this type of thing as a
"class." There are some ten-dollar definitions of object-oriented programming, too. You can usually
follow them only if you already know what OOP is. They generally run something like: