ISBN-10:
0201924889
ISBN-13:
9780201924886
Pub. Date:
09/02/1997
Publisher:
Addison-Wesley
Effective C++: 50 Specific Ways to Improve Your Programs and Design / Edition 2

Effective C++: 50 Specific Ways to Improve Your Programs and Design / Edition 2

by Scott Meyers

Paperback

Current price is , Original price is $39.95. You
Select a Purchase Option (Older Edition)
  • purchase options

Product Details

ISBN-13: 9780201924886
Publisher: Addison-Wesley
Publication date: 09/02/1997
Series: Professional Computing Series
Edition description: Older Edition
Pages: 256
Product dimensions: 7.39(w) x 9.18(h) x 0.57(d)

About the Author


Scott Meyers is a recognized authority on C++; he provides consulting services to clients worldwide. He is the author of More Effective C++, a former columnist for the C++ Report, and a featured speaker at technical conferences around the globe. He received his Ph.D. in Computer Science from Brown University in 1993.

Read an Excerpt

PREFACE:

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 Cchecking 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 importantthan 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:

Scott Meyers
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 ec@awl.com.

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, ...

Table of Contents

Preface xiii(4)
Acknowledgments xvii
Introduction 1(12)
Shifting from C to C++ 13(9)
Item 1: Prefer const and inline to #define.
13(4)
Item 2: Prefer [iostream] to [stdio.h.]
17(2)
Item 3: Prefer new and delete to malloc and free.
19(2)
Item 4: Prefer C++-style comments.
21(1)
Memory Management 22(27)
Item 5: Use the same form in corresponding uses of new and delete.
23(1)
Item 6: Use delete on pointer members in destructors.
24(1)
Item 7: Be prepared for out-of-memory conditions.
25(8)
Item 8: Adhere to convention when writing operator new and operator delete.
33(4)
Item 9: Avoid hiding the "normal" form of new.
37(2)
Item 10: Write operator delete if you write operator new.
39(10)
Constructors, Destructors, and Assignment Operators 49(28)
Item 11: Declare a copy constructor and an assignment operator for classes with dynamically allocated memory.
49(3)
Item 12: Prefer initialization to assignment in constructors.
52(5)
Item 13: List members in an initialization list in the order in which they are declared.
57(2)
Item 14: Make destructors virtual in base classes.
59(5)
Item 15: Have operator = return a reference to *this.
64(4)
Item 16: Assign to all data members in operator=.
68(3)
Item 17: Check for assignment to self in operator=.
71(6)
Classes and Functions: Design and Declaration 77(46)
Item 18: Strive for class interfaces that are complete and minimal.
79(5)
Item 19: Differentiate among member functions. non-member functions, and friend functions.
84(5)
Item 20: Avoid data members in the public interface.
89(2)
Item 21: Use const whenever possible.
91(7)
Item 22: Prefer pass-by-reference to pass-by-value.
98(3)
Item 23: Don't try to return a reference when you must return an object.
101(5)
Item 24: Choose carefully between function overloading and parameter defaulting.
106(3)
Item 25: Avoid overloading on a pointer and a numerical type.
109(4)
Item 26: Guard against potential ambiguity.
113(3)
Item 27: Explicitly disallow use of implicitly generated member functions you don't want.
116(1)
Item 28: Partition the global namespace.
117(6)
Classes and Functions: Implementation 123(30)
Item 29: Avoid returning "handles" to internal data.
123(6)
Item 30: Avoid member functions that return non-const pointers or references to members less accessible than themselves.
129(2)
Item 31: Never return a reference to a local object or to a dereferenced pointer initialized by new within the function.
131(4)
Item 32: Postpone variable definitions as long as possible.
135(2)
Item 33: Use inlining judiciously.
137(6)
Item 34: Minimize compilation dependencies between files.
143(10)
Inheritance and Object-Oriented Design 153(59)
Item 35: Make sure public inheritance models "isa."
154(7)
Item 36: Differentiate between inheritance of interface and inheritance of implementation.
161(8)
Item 37: Never redefine an inherited nonvirtual function.
169(2)
Item 38: Never redefine an inherited default parameter value.
171(2)
Item 39: Avoid casts down the inheritance hierarchy.
173(9)
Item 40: Model "has-a" or "is-implemented-in-terms-of" through layering.
182(3)
Item 41: Differentiate between inheritance and templates.
185(4)
Item 42: Use private inheritance judiciously.
189(5)
Item 43: Use multiple inheritance judiciously.
194(16)
Item 44: Say what you mean: understand what you're saying.
210(2)
Miscellany 212(25)
Item 45: Know what functions C++ silently writes and calls.
212(4)
Item 46: Prefer compile-time and link-time errors to runtime errors.
216(3)
Item 47: Ensure that non-local static objects are initialized before they're used.
219(4)
Item 48: Pay attention to compiler warnings.
223(1)
Item 49: Familiarize yourself with the standard library.
224(8)
Item 50: Improve your understanding of C++.
232(5)
Afterword 237(2)
Index 239

Preface

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:

Scott Meyers
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 .

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, . 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
STAFFORD, OREGON
JULY 1997


0201924889P04062001

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews