The book is organized like this (see the table of contents or the expanded table of contents for more detail):
The idea is to give the reader an overview and then go through the language and the main programming techniques it supports in a bottom-up fashion. Then, the standard library is described as a larger example of C++ language facilities and design techniques. After the language and standard library have been described, I present more general issues of design and programming technique. To avoid the discussion of the language turning into a simple enumeration of features and rules, I pushed many technical details into appendices.
The book is aimed at programmers with some experience and a wish to master C++. It is not aimed at non-programmers trying to learn their first programming language or casual programmers trying to gain a superficial understanding of C++ as fast as possible. Consequently, this book focuses on concepts and techniques and goes to some pain to be complete and precise.
The presentation is centered on small program fragments embedded in the text. The examples are chosen to illustrate fundamental programming techniques rather than to be immediately useful as part of a reader's code. The language used is "pure C++" without vendor-specific extensions or system dependencies. Look to your vendor documentation for examples of how to deal with system-specific resources. To get the program fragments from the text to work, expect to have to add "scaffolding" in the form of header files, driver code (e.g. a main()), etc., and to supply parts of an example that I didn't need for the discussion of a concept or technique.
To illustrate the full language and an extensive range of techniques, I use language features available only in the latest compiler releases. One purpose of the book is to demonstrate the utility of facilities that at the time of writing were unavailable or unavailable to most people. At the time of writing, no compiler was capable of compiling every example in the book and no standard library implementation supported every facility described. For years to come, the use of advanced features will cause some problems to readers who use older compilers. I encourage upgrading to implementations that support full ISO C++, but understand that practical issues often force production code to be written in a language subset determined by older implementations.
This use of language features contrasts to the common sensible approach of maximizing the appeal of a book by describing only a subset of language features and only techniques that work with all common implementations. One benefit of my approach is that it gives the book a much longer lifespan (the first and second editions each had a useful life as up-to-date descriptions of C++ and its use of about six years; I expect the useful life of the third edition to be longer).
This book can be used as a user-level reference for language features, standard library facilities, and programming techniques. However, it is not a reference manual or the standards text. If you need 100% precise and complete information you'll have to consult the text of the ISO C++ standard. Be warned that the standard is not a tutorial and it takes considerable effort and skill to extract answers from it. One aim in writing "The C++ Programming Language" has been to approximate the ideal that "if the answer isn't there, you'd better avoid the feature."
I take a very aggressive approach to "book maintenance." When I receive comments about bugs, typos, inaccuracies, possible ambiguities, omissions, suggested improvements, etc., I try to make improvements and post errata documenting what I've done. Much errata are improvements rather than fixes of errors. Thus, the amount of errata isn't a valid measure of errors. If you count omissions, inaccuracies, and ambiguities as errors, even the 1st printing of my 3rd edition had fewer errors than most books. By now, I'm confident enough to offer a bounty for each error found.
When I make a change to a printing, I make sure that material doesn't migrate from one page to another. Consequently, references to a page in one printing (e.g. an index entry) remain valid for all printings.
Some statistics: The book contains
Look here for working code examples.
- Bjarne Stroustrup