In this way I hope to move you, a little at a time, from
understanding C to the point where the C++ mindset becomes your native tongue.
Throughout, I’ll be taking the attitude that you want to build a model in your head that allows you to understand the language all the way down to the bare metal; if you encounter a puzzle
you’ll be able to feed it to your model and deduce the answer. I will try to convey to you the insights which have rearranged my brain to make me start “thinking in C++.”
Prerequisites
In the first edition of this book, I decided to assume that someone else had taught you C and that you have at least a reading level of comfort with it. My primary focus was on simplifying what I found difficult – the C++ language. In this edition I have added a chapter that is a very rapid introduction to C, assuming that you have some kind of programming experience
already. In addition, just as you learn many new words intuitively by seeing them in context
in a novel, it’s possible to learn a great deal about C from the context in which it is used in the rest of the book.
Thinking in C
For those of you who need a gentler introduction to C than the chapter in this book, I have
created with Chuck Allison a CD ROM called “Thinking in C: foundations for Java and C++”
which will introduce you to the aspects of C that are necessary for you to move on to C++ or
Java (leaving out the nasty bits that C programmers must deal with on a day-to-day basis but
that the C++ and Java languages steer you away from). This CD can be ordered at
17
http://www.BruceEckel.com. [Note: the CD will not be available until late Fall 98, at the earliest – watch the Web site for updates]
Learning C++
I clawed my way into C++ from exactly the same position as I expect the readers of this book
will: As a C programmer with a very no-nonsense, nuts-and-bolts attitude about
programming. Worse, my background and experience was in hardware-level embedded
programming, where C has often been considered a high-level language and an inefficient
overkill for pushing bits around. I discovered later that I wasn’t even a very good C
programmer, hiding my ignorance of structures, malloc( ) & free( ), setjmp( ) & longjmp( ), and other “sophisticated” concepts, scuttling away in shame when the subjects came up in
conversation rather than reaching out for new knowledge.
When I began my struggle to understand C++, the only decent book was Stroustrup’s self-
professed “expert’s guide,1 ” so I was left to simplify the basic concepts on my own. This
resulted in my first C++ book,2 which was essentially a brain dump of my experience. That
was designed as a reader’s guide, to bring programmers into C and C++ at the same time.
Both editions3 of the book garnered an enthusiastic response and I still feel it is a valuable resource.
At about the same time that Using C++ came out, I began teaching the language. Teaching C++ has become my profession; I’ve seen nodding heads, blank faces, and puzzled
expressions in audiences all over the world since 1989. As I began giving in-house training
with smaller groups of people, I discovered something during the exercises. Even those
people who were smiling and nodding were confused about many issues. I found out, by
chairing the C++ track at the Software Development Conference for the last three years, that I and other speakers tended to give the typical audience too many topics, too fast. So
eventually, through both variety in the audience level and the way that I presented the
material, I would end up losing some portion of the audience. Maybe it’s asking too much, but because I am one of those people resistant to traditional lecturing (and for most people, I
believe, such resistance results from boredom), I wanted to try to keep everyone up to speed.
For a time, I was creating a number of different presentations in fairly short order. Thus, I ended up learning by experiment and iteration (a technique that also works well in C++