The first edition of Effective C++ sold nearly 100,000 copies and was translated into four languages. It's easy to understand why. Scott Meyers' practical approach to C++ described the rules of thumb employed by the experts--the things they almost always do or almost always avoid doing--to produce clear, correct, efficient code.
Each of this book's 50 guidelines summarizes a way to write better C++, and the accompanying discussions are backed by specific examples. For this new edition, Meyers reworked every guideline in the book. The result is exceptional adherence to C++'s Draft International Standard, current compiler technology, and the latest insights into the use of C++ for real-world applications.
Highlights of Effective C++, Second Edition include:
2. Shifting From C to C++.
Prefer const and inline to #define.
Prefer iostream to stdio.h.
Prefer new and delete to malloc and free.
Prefer C++-style comments.
Use the same form in corresponding uses of new and delete.
Use delete on pointer members in destructors.
Be prepared for out-of-memory conditions.
Adhere to convention when writing operator new and operator delete.
Avoid hiding the "normal" form of new.
Write operator delete if you write operator new.
Declare a copy constructor and an assignment operator for classes with dynamically allocated memory.
Prefer initialization to assignment in constructors.
List members in an initialization list in the order in which they are declared.
Make destructors virtual in base classes.
Have operator return a reference to *this.
Assign to all data members in operator.
Check for assignment to self in operator.
Strive for class interfaces that are complete and minimal.
Differentiate among member functions, non-member functions, and friend functions.
Avoid data members in the public interface.
Use const whenever possible.
Prefer pass-by-reference to pass-by-value.
Don't try to return a reference when you must return an object.
Choose carefully between function overloading and parameter defaulting.
Avoid overloading on a pointer and a numerical type.
Guard against potential ambiguity.
Explicitly disallow use of implicitly generated member functions you don't want.
Partition the global namespace.
Avoid returning "handles" to internal data.
Avoid member functions that return non-const pointers or references to members less accessible than themselves.
Never return a reference to a local object or to a dereferenced pointer initialized by new within the function.
Postpone variable definitions as long as possible.
Use inlining judiciously.
Minimize compilation dependencies between files.
Make sure public inheritance models "isa."
Differentiate between inheritance of interface and inheritance of implementation.
Never redefine an inherited nonvirtual function.
Never redefine an inherited default parameter value.
Avoid casts down the inheritance hierarchy.
Model "has-a" or "is-implemented-in-terms-of" through layering.
Differentiate between inheritance and templates.
Use private inheritance judiciously.
Use multiple inheritance judiciously.
Say what you mean; understand what you're saying.
Know what functions C++ silently writes and calls.
Prefer compile-time and link-time errors to runtime errors.
Ensure that non-local static objects are initialized before they're used.
Pay attention to compiler warnings.
Familiarize yourself with the standard library.
Improve your understanding of C++.
This book is a direct outgrowth of my experiences teaching C++ to professional programmers. I've found that most students, after a week of intensive instruction, feel comfortable with the basic constructs of the language, but they tend to be less sanguine about their ability to put the constructs together in an effective manner. Thus began my attempt to formulate short, specific, easy-to-remember guidelines for effective software development in C++: a summary of the things experienced C++ programmers almost always do or almost always avoid doing.
I was originally interested in rules that could be enforced by some kind of
lint-like program. To that end, I led research into the development of tools to examine C++ source code for violations of user-specified conditions. Unfortunately, the research ended before a complete prototype could be developed. Fortunately, several commercial C++-checking products are now available.
Though my initial interest was in programming rules that could be automatically enforced, I soon realized the limitations of that approach. The majority of guidelines used by good C++ programmers are too difficult to formalize or have too many important exceptions to be blindly enforced by a program. I was thus led to the notion of something less precise than a computer program, but still more focused and to-the-point than a general C++ textbook. The result you now hold in your hands: a book containing 50 specific suggestions on how to improve your C++ programs and designs.
In this book, you'll find advice on what you should do, and why, and what you should not do, and why not. Fundamentally, of course, the whys are more important than the whats, but it's a lot more convenient to refer to a list of guidelines than to memorize a textbook or two.
Unlike most books on C++, my presentation here is not organized around particular language features. That is, I don't talk about constructors in one place, about virtual functions in another, about inheritance in a third, etc. Instead, each discussion in the book is tailored to the guideline it accompanies, and my coverage of the various aspects of a particular language feature may be dispersed throughout the book.
The advantage of this approach is that it better reflects the complexity of the software systems for which C++ is often chosen, systems in which understanding individual language features is not enough. For example, experienced C++ developers know that understanding inline functions and understanding virtual destructors does not necessarily mean you understand inline virtual destructors. Such battle-scarred developers recognize that comprehending the interactions between the features in C++ is of the greatest possible importance in using the language effectively. The organization of this book reflects that fundamental truth.
The disadvantage of this design is that you may have to look in more than one place to find everything I have to say about a particular C++ construct. To minimize the inconvenience of this approach, I have sprinkled cross-references liberally throughout the text, and a comprehensive index is provided at the end of the book.
In preparing this second edition, my ambition to improve the book has been tempered by fear. Tens of thousands of programmers embraced the first edition of Effective C++, and I didn't want to destroy whatever characteristics attracted them to it. However, in the six years since I wrote the book, C++ has changed, the C++ library has changed (see Item 49), my understanding of C++ has changed, and accepted usage of C++ has changed. That's a lot of change, and it was important to me that the technical material in Effective C++ be revised to reflect those changes. I'd done what I could by updating individual pages between printings, but books and software are frighteningly similar--there comes a time when localized enhancements fail to suffice, and the only recourse is a system-wide rewrite. This book is the result of that rewrite: Effective C++, Version 2.0.
Those familiar with the first edition may be interested to know that every Item in the book has been reworked. I believe the overall structure of the book remains sound, however, so little there has changed. Of the 50 original Items, I retained 48, though I tinkered with the wording of a few Item titles (in addition to revising the accompanying discussions). The retired Items (i.e., those replaced with completely new material) are numbers 32 and 49, though much of the information that used to be in Item 32 somehow found its way into the revamped Item 1. I swapped the order of Items 41 and 42, because that made it easier to present the revised material they contain. Finally, I reversed the direction of my inheritance arrows. They now follow the almost-universal convention of pointing from derived classes to base classes. This is the same convention I followed in my 1996 book, More Effective C++, an overview of which you can find on pages 237-238 of this volume.
The set of guidelines in this book is far from exhaustive, but coming up with good rules--ones that are applicable to almost all applications almost all the time--is harder than it looks. Perhaps you know of additional guidelines, of more ways in which to program effectively in C++. If so, I would be delighted to hear about them.
On the other hand, you may feel that some of the Items in this book are inappropriate as general advice; that there is a better way to accomplish a task examined in the book; or that one or more of the technical discussions is unclear, incomplete, or misleading. I encourage you to let me know about these things, too.
Donald Knuth has a long history of offering a small reward for people who notify him of errors in his books. The quest for a perfect book is laudable in any case, but in view of the number of bug-ridden C++ books that have been rushed to market, I feel especially strongly compelled to follow Knuth's example. Therefore, for each error in this book that is reported to me--be it technical, grammatical, typographical, or otherwise--I will, in future printings, gladly add to the acknowledgments the name of the first person to bring that error to my attention.
Send your suggested guidelines, your comments, your criticisms, and--sigh--your bug reports to:
c/o Publisher, Corporate and Professional Publishing
Addison Wesley Longman, Inc.
1 Jacob Way
Reading, MA 01867
U. S. A.
Alternatively, you may send electronic mail to firstname.lastname@example.org.
I maintain a list of changes to this book since its first printing, including bug-fixes, clarifications, and technical updates. This list is available at the Effective C++ World Wide Web site, http://www.aw.com/cseng/titles/0-201-92488-9/. If you would like a copy of this list, but you lack access to the World Wide Web, please send a request to one of the addresses above, and I will see that the list is sent to you.SCOTT DOUGLAS MEYERS