OriginsEarly in 1988, about when I had finished writing C Traps and Pitfalls, Bjarne Stroustrup told me that he had just been invited to join the editorial board of a new magazine called the Journal of Object-Oriented Programming(JOOP). The magazine was intended to fit between the conventional academic journals and the magazines that are mostly product reviews and advertising. They were seeking a C++ columnist; was I interested?
C++ was just beginning to become an important influence on the programming community. Usenix had recently held its first C++ workshop, in Santa Fe, New Mexico.They had expected 50 people; more than 200 showed up. Many more would hop on the C++ bandwagon, which meant that the community would need an articulate, reasoned voice to speak against the torrent of hype that was sure to come. It would need someone who could make clear the difference between hype and substance and keep a cool head in all the turmoil. I took the offer anyway.
I am writing these words while thinking about my sixty-third column for JOOP. The column has appeared in every issue but two, during which time I badly needed a break and was lucky enough to be able to get Jonathan Shopiro to take my place. On a third occasion, I wrote only the introduction to the column, stepping aside for the distinguished Danish computer scientist Bjorn Stavtrup. In addition, Livleen Singh talked me into writing a column for the quarterlyC++ Journal, which lasted six issues before folding, and Stan Lippman cajoled me into doing a column for the C++ Reportwhen it changed from a newsletter into a full-fledged magazine. Adding my 29 C++ Reportcolumns to the others brings the total to 98.
That's a lot of stuff to be scattered in periodicals all over the place.If the articles are useful individually, they should be evenmore useful when collected.In consequence, Barbara and I (mostly Barbara) have gone back over the columns, selected the best, and added to or rewritten them as needed for coherence and continuity. Just what the world needs--another C++ book
Now that you know why the book exists, let me tell you why you should read it instead of some other C++ book. Goodness knows, there are enough of them; why pick this one?
The first reason is that I think you'll enjoy it. Most C++ books don't have that in mind: They are curriculum-based. Enjoyment is secondary at best.
Magazine columns are different. I suppose there must be some people out there who thumb through a copy of JOOPin a bookstore and skim my column before deciding whether to buy the magazine, but it would be arrogant to think that there are more than a few. Most readers will be seeing my column after they've already paid for it, which means that they have a completely free choice about whether to read it or not. So each column has to be worth reading on its own.
This book contains no long, boring discussions of obscure details. Beginners are not intended to be able to learn C++ from this book alone. A few people, who already know several programming languages thoroughly, and who have figured out how to infer the rules for a new language by reading code, will be able to use this book to get an overview of C++. Most readers starting from scratch would do well to read The C++ Programming Language(Addison-Wesley 1991)by Bjarne Stroustrup, or Stan Lippman's C++ Primer(Addison-Wesley 1991), and then read this book.
This is a book about ideas and techniques, not details. If you want to find out how to make virtual base classes do double reverse backflips, you will have to turn elsewhere.What you will find here is lots of code to read.Try the examples for yourself. Classroom experience indicates that getting these programs to run and then modifying them is a good way to cement your understanding. For those who prefer to start with working code, we have made available selected examples from the book by anonymous FTP from ftp.aw in directory cseng/authors/koenig/ruminations.
If you know some C++ already, I think that this book will not only entertain but also enlighten you. This is the second reason to read it. My intent isn't to teach C++ per se. Instead, I want to show you how to think about programming in C++, and how to look at problems and express a solution in C++. Knowledge can be acquired systematically; wisdom cannot.OrganizationAlthough I intended each column to stand alone, I believe that the collection will be easier and more enjoyable to read when grouped by concept. The book is therefore divided into six parts.
Part I is an extended introduction to themes that will pervade the rest of the book. You won't find much code, but the ideas of abstraction and pragmatism explored there underlie both this book and, more important, the design of C++ and strategies for its effective use.
Part II looks at inheritance and object-oriented programming, which most people think are the most important ideas in C++. You will learn why inheritance is important and what it can do.You will also learn why it can be useful to conceal inheritance from its users and when to avoid inheritance altogether.
Part III explores templates, which I think constitute the most important idea in C++. The reason I think templates are so important is that they provide a particularly powerful kind of abstraction. Not only do templates allow the construction of containers that know almost nothing about the types of what they will contain, but they make it possible to abstract away things far more general than just types.
One reason that inheritance and templates are important is that they are ways of extending C++ without waiting (or paying) for people to produce new languages and compilers. The way to organize such extensions is through class libraries. Part IV talks about libraries--both their design and use.
With the basics well understood, we can look at some specialized programming techniques in Part V. Here you will find ways to tie classes inextricably together, as well as ways to keep them as far apart as possible.
Finally, in Part VI, we turn back for a last look at the terrain we have covered. Compilation and editing One artifact of these papers having been written over a number of years is that they do not always use all the current features of the language.This raises a problem: Do we rewrite the columns as if full-fledged ISO C++ were the norm when the standard hasn't been approved yet?Or do we deliberately write in an archaic style?
As with so much else in C++, we compromised. Where the original column was simply incorrect--either in light of how the language has changed since the column was written or because of a change in our understanding of how things should be--we'vefixed it. A particularly pervasive example is our use of const the importance of which has steadily grown in our understanding since const entered the language.
On the other hand, for instance, lots of examples here use int to represent true or false values, even though the standards committee has accepted bool as a built-in data type. The reasoning is that the columns were written that way originally, using int for such values will still work, and it will be years before most compilers support bool. AcknowledgmentsIn addition to publishing our ideas in JOOP, the C++ Report, and the C++ Journal, we refined them through giving talks (and listening to students) in many places. Particularly noteworthy were the conferences organized by the Usenix Association and by SIGS Publications, publishers of JOOPand the C++ Report. In addition, there are the weeklong courses that the two of us have taught at Stanford University under the auspices of the Western Institute in Computer Science, and at Bell Labs for members of the Acoustics Research Laboratory and Network Services Research Laboratory, as well as several courses and lectures that Dag Bruck, then at the Department of Automatic Control at the Lund Institute of Technology and now at Dynasim AB, organized in Sweden.
We are also grateful to the people who read and commented on drafts of the book and the columns that it comprises: Dag Bruck, Jim Coplien, Tony Hansen, Bill Hopkins, Brian Kernighan (who gets extra credit for reading the entire book twice carefully with pen in hand), Stan Lippman, Rob Murray, George Otto, and Bjarne Stroustrup.
The columns would never have become a book without the help of Deborah Lafferty, Loren Stevens and Tom Stone at Addison-Wesley, and the copy editing of Lyn Dupre.
We are particularly grateful to the enlightened managers at AT&T who made it possible to write these columns and to compile this book, including Dave Belanger, Ron Brachman, Jim Finucane, Sandy Fraser, Wayne Hunt, Brian Kernighan, Rob Murray, Ravi Sethi, Bjarne Stroustrup, and Eric Sumner.
Andrew Koenig
Barbara Moo
Gillette, New Jersey
April, 1996
0201423391P04062001
From the Back Cover
A book that stands out from the herd.
Ruminations on C++ concentrates on the key C++ ideas and programming techniques--skimming the cream--to let you understand the "why" and not just the "how" of C++ programming. You need not be an expert C++ programmer to find solid fodder here, yet even experts need not fear overgrazing: You will find something worth chewing on in every chapter.
This should be your next C++ book, because it
- covers a broad range of C++ ideas and techniques, from detailed code examples to design principles and philosophy
- shows how to think about programming in C++, not just how to follow rules
- explains the motivation behind its examples; sometimes even solving the same problem in two different ways
- covers both object-oriented programming and generic programming
- explains the ideas behind the Standard Template Library, which is the most important recent innovation in C++.
This book comes to you from two people who started using C++ when its entire user community could still fit in one room. Both of them have contributed significantly to the evolution of C++.
0201423391B04062001
About the Author
Andrew Koenig is a member of the Large-Scale Programming Research Department at AT&T's Shannon Laboratory, and the Project Editor of the C++ standards committee. A programmer for more than 30 years, 15 of them in C++, he has published more than 150 articles about C++, and speaks on the topic worldwide.
Barbara E. Moo is an independent consultant with 20 years' experience in the software field. During her nearly 15 years at AT&T, she worked on one of the first commercial products ever written in C++, managed the company's first C++ compiler project, and directed the development of AT&T's award-winning WorldNet Internet service business.
0 Excerpt. © Reprinted by permission. All rights reserved.
Origins
Early in 1988, about when I had finished writing C Traps and Pitfalls, Bjarne Stroustrup told me that he had just been invited to join the editorial board of a new magazine called the Journal of Object-Oriented Programming(JOOP). The magazine was intended to fit between the conventional academic journals and the magazines that are mostly product reviews and advertising. They were seeking a C++ columnist; was I interested?C++ was just beginning to become an important influence on the programming community. Usenix had recently held its first C++ workshop, in Santa Fe, New Mexico.They had expected 50 people; more than 200 showed up. Many more would hop on the C++ bandwagon, which meant that the community would need an articulate, reasoned voice to speak against the torrent of hype that was sure to come. It would need someone who could make clear the difference between hype and substance and keep a cool head in all the turmoil. I took the offer anyway.
I am writing these words while thinking about my sixty-third column for JOOP. The column has appeared in every issue but two, during which time I badly needed a break and was lucky enough to be able to get Jonathan Shopiro to take my place. On a third occasion, I wrote only the introduction to the column, stepping aside for the distinguished Danish computer scientist Bjorn Stavtrup. In addition, Livleen Singh talked me into writing a column for the quarterlyC++ Journal, which lasted six issues before folding, and Stan Lippman cajoled me into doing a column for the C++ Reportwhen it changed from a newsletter into a full-fledged magazine. Adding my 29 C++ Reportcolumns to the others brings the total to 98.
That's a lot of stuff to be scattered in periodicals all over the place.If the articles are useful individually, they should be evenmore useful when collected.In consequence, Barbara and I (mostly Barbara) have gone back over the columns, selected the best, and added to or rewritten them as needed for coherence and continuity.
Just what the world needs--another C++ book
Now that you know why the book exists, let me tell you why you should read it instead of some other C++ book. Goodness knows, there are enough of them; why pick this one?
The first reason is that I think you'll enjoy it. Most C++ books don't have that in mind: They are curriculum-based. Enjoyment is secondary at best.
Magazine columns are different. I suppose there must be some people out there who thumb through a copy of JOOPin a bookstore and skim my column before deciding whether to buy the magazine, but it would be arrogant to think that there are more than a few. Most readers will be seeing my column after they've already paid for it, which means that they have a completely free choice about whether to read it or not. So each column has to be worth reading on its own.
This book contains no long, boring discussions of obscure details. Beginners are not intended to be able to learn C++ from this book alone. A few people, who already know several programming languages thoroughly, and who have figured out how to infer the rules for a new language by reading code, will be able to use this book to get an overview of C++. Most readers starting from scratch would do well to read The C++ Programming Language(Addison-Wesley 1991)by Bjarne Stroustrup, or Stan Lippman's C++ Primer(Addison-Wesley 1991), and then read this book.
This is a book about ideas and techniques, not details. If you want to find out how to make virtual base classes do double reverse backflips, you will have to turn elsewhere.What you will find here is lots of code to read.Try the examples for yourself. Classroom experience indicates that getting these programs to run and then modifying them is a good way to cement your understanding. For those who prefer to start with working code, we have made available selected examples from the book by anonymous FTP from ftp.aw.com in directory cseng/authors/koenig/ruminations.
If you know some C++ already, I think that this book will not only entertain but also enlighten you. This is the second reason to read it. My intent isn't to teach C++ per se. Instead, I want to show you how to think about programming in C++, and how to look at problems and express a solution in C++. Knowledge can be acquired systematically; wisdom cannot.
Organization
Although I intended each column to stand alone, I believe that the collection will be easier and more enjoyable to read when grouped by concept. The book is therefore divided into six parts.Part I is an extended introduction to themes that will pervade the rest of the book. You won't find much code, but the ideas of abstraction and pragmatism explored there underlie both this book and, more important, the design of C++ and strategies for its effective use.
Part II looks at inheritance and object-oriented programming, which most people think are the most important ideas in C++. You will learn why inheritance is important and what it can do.You will also learn why it can be useful to conceal inheritance from its users and when to avoid inheritance altogether.
Part III explores templates, which I think constitute the most important idea in C++. The reason I think templates are so important is that they provide a particularly powerful kind of abstraction. Not only do templates allow the construction of containers that know almost nothing about the types of what they will contain, but they make it possible to abstract away things far more general than just types.
One reason that inheritance and templates are important is that they are ways of extending C++ without waiting (or paying) for people to produce new languages and compilers. The way to organize such extensions is through class libraries. Part IV talks about libraries--both their design and use.
With the basics well understood, we can look at some specialized programming techniques in Part V. Here you will find ways to tie classes inextricably together, as well as ways to keep them as far apart as possible.
Finally, in Part VI, we turn back for a last look at the terrain we have covered.
Compilation and editing
One artifact of these papers having been written over a number of years is that they do not always use all the current features of the language.This raises a problem: Do we rewrite the columns as if full-fledged ISO C++ were the norm when the standard hasn't been approved yet?Or do we deliberately write in an archaic style? As with so much else in C++, we compromised. Where the original column was simply incorrect--either in light of how the language has changed since the column was written or because of a change in our understanding of how things should be--we'vefixed it. A particularly pervasive example is our use of const the importance of which has steadily grown in our understanding since const entered the language.
On the other hand, for instance, lots of examples here use int to represent true or false values, even though the standards committee has accepted bool as a built-in data type. The reasoning is that the columns were written that way originally, using int for such values will still work, and it will be years before most compilers support bool.
Acknowledgments
In addition to publishing our ideas in JOOP, the C++ Report, and the C++ Journal, we refined them through giving talks (and listening to students) in many places. Particularly noteworthy were the conferences organized by the Usenix Association and by SIGS Publications, publishers of JOOPand the C++ Report. In addition, there are the weeklong courses that the two of us have taught at Stanford University under the auspices of the Western Institute in Computer Science, and at Bell Labs for members of the Acoustics Research Laboratory and Network Services Research Laboratory, as well as several courses and lectures that Dag Bruck, then at the Department of Automatic Control at the Lund Institute of Technology and now at Dynasim AB, organized in Sweden. We are also grateful to the people who read and commented on drafts of the book and the columns that it comprises: Dag Bruck, Jim Coplien, Tony Hansen, Bill Hopkins, Brian Kernighan (who gets extra credit for reading the entire book twice carefully with pen in hand), Stan Lippman, Rob Murray, George Otto, and Bjarne Stroustrup.
The columns would never have become a book without the help of Deborah Lafferty, Loren Stevens and Tom Stone at Addison-Wesley, and the copy editing of Lyn Dupre.
We are particularly grateful to the enlightened managers at AT&T who made it possible to write these columns and to compile this book, including Dave Belanger, Ron Brachman, Jim Finucane, Sandy Fraser, Wayne Hunt, Brian Kernighan, Rob Murray, Ravi Sethi, Bjarne Stroustrup, and Eric Sumner.
Andrew Koenig
Barbara Moo
Gillette, New Jersey
April, 1996
0201423391P04062001
