Book Review: C Gotchas
Marc Briand
Name: C Gotchaas: Avoiding Common Problems In Coding and Design
Author: Stephen C. Dewhurst
Publisher: Addison Wesley Professional, 2003
Pages: 324, SoftBound
Price: $ 44.99
Rating: Amazon four stars
Translation: Gotcha is I've got you's omission, "I'm hard to fall you", "I asked you".
C has long evolved and developed, such a late publishing of the Gotchas book is a bit weird. C is a real-world-available language that has historical history; and C standard has almost no change in the past five years. In this case, you may think that the defects in the language should now be a well-known "common knowledge" [Note 1] ". However, even if experienced C programmers will encounter trouble from time to time; Steve Dewhurst - this industry's multi-year C course teachers, authors, and consultants - are more clear than anyone. DewhursT seems to seem to be safe for the programmer, not the complexity of C . In this book, the neglect and poor style of the C basic topic is listed as two original sins in programming. Experience itself cannot avoid such artificial mistakes; sometimes we do need some harsh loyalty. According to this, C Gotchas is more than just a reading book books of C difficult diseases, but also a police speech, reminding us to pay attention to problems that may be ignored by us.
The usual method is one of the above problems. In the spoken language, the so-called usual method refers to the frequently used words (such as "gotcha"), which can quickly express a clear meaning. The meaning of the usual method is clear, it is only because the monochron is widely used, rather than the meaning of each single word. In a programming language, a customary method refers to an expression or skill that can clearly express the programmer. Similarly, the properties of the programs in the programming language are derived from their extensive use. A person who has not learned how to use oral usage will be very inconvenient; and a programmer who does not use programming usage will lead to all other programmers - especially their code maintenance. In Dewhurst's book, the appropriate use of customary methods is considered a good programming style, while a good programming style can minimize Gotchas appearance.
Of course, if all of us is just a 霹雳 discussion about style problems, this book will be much thin. But what we need is about Gotchas's specific information, no matter what it started. DEWHURST puts these details among nine chapters: Basics, Syntax, The Preprocessor, Conversions, Initialization, Memory and Resource Management (Memory & Resource " Management), POLYMORPHISM, Class Design, and Hierarchy Design (class system design). These Gotchas sources, from simple carelessness (such as erroneous use DELETE instead of delete [] to make the array) to the array), to the pure ignore (a conversion operator as a "cast") until it is quite mixed (For example, the overload and overwriting of the virtual function is mixed in the case of insufficient reasons). In addition, the development process of depression and emotionalization is now being seen as a gotcha; please see the book in the book. Gotcha # 12. Even if you are a codeware, righteous indignation is no longer a "impulse" behavior. Most of the Gotchas elaborated in the book can be unfair. For some parties that have any objections, is it obviously not appropriate because of the introduction of Gotchas? At least, the answer is affirmative on the standing place to see it. DewhursT really provides an example of persuasion - occasionally, a hidden error comes out. However, this book has a small number of terms not incisive. One of them is the problem of the preferred placement location in the declaration:
Const int * thisway; // Pointer to Constant INTEGER
INT const * tratway; // is the same as the previous sentence
DewhursT also advocates the first form because it is a Writing of C programmers habits. It has become a usual form in a long time in a long time. However, the second declaration form also has a prominent truth, and it has been respected in the C community. The second form allows us to always follow a simple rule: "Const always limits the character of the next to the left." So, it is meaningless to recommend one of the methods as a provision may be a laugh. But it also reflects the attention of Dewhurst to habits. More familiar with the habitual usage, more familiar use of the habitual usage (this may include most programmers) relative to the sage, which may be understood as a CONSTANT POINTER statement, but actually not. Dewhurst is not a language of the Crusaders and revolutionaries. He just wants to be responsible for maintaining its code.
Vertical
This book often flashes "Maintenance" this word, why is not difficult. One of the modernization of modern calculations is that hardware is updated once a few years, while many software have to maintain dozens of years. Software is often long than the life foresee foreseen, just a few years ago Y2K panic as a certificate. Dewhurst frequently reminds readers in books, how to consider how to be maintained. His suggestion can be classified as two design guidelines:
1. Suppose at least another person will keep your code; 2. Don't assume that this person is the smarter in the group.
The ancient quasi-made code we wrote now will become bugs in the future. If you have not become a victim of many C Gotchas in recent years, you may not feel the necessary reading books. But you may want to be wrong. C Gotchas is like a feedback mechanism from future. It is showing you that you will cause trouble in the future.
Is it a new thing or ancient?
Of course, this is not the first C book involved in Gotchas. Many readers may immediately think of Scott Meyers' classic Effective C , and to ask how many new things in C Gotchas. I found 15 overlap with C GTOCHAS from the 85 clauses of Scott Meyers Effective C and More Effective C . There are not many quantities, in addition, the focus of these books is quite different. Dewhurst is more concerned about the topics I called "Subtle Basics". From the terms literal, it seems to have contradictory with its content, but unfortunately, this is not contradictory in C . This book has a lot of available content, but there are more content this book is not covered. For example, this book does not have the use of C standard libraries or Templates. This will let you ponder how many possible Gotchas books will appear. If Dewhurst only wrote one of them, we are very fortunate.
Comment
[Note 1]: Sorry to Steve Dewhurst, because here is stealing his iconic language. In the past, his "commit knowledge" column made C Report (now there have been reported) and CUJ proud.
About author
Marc Briand is the editor of the former C / C Users Journal. He now develops ATE (Automated Test Equipment Software for Aerospace Industry. You can contact him via marcbriand@cs.com.
PREFACE.
Acknowledgments.
Basics.
Gotcha # 1:. Excessive Commenting Gotcha # 2: Magic Numbers Gotcha # 3:.. Global Variables Gotcha # 4: Failure to Distinguish Overloading from Default Initialization Gotcha # 5:. Misunderstanding References Gotcha # 6:.. Misunderstanding Const Gotcha # 7 :. Ignorance of Base Language Subtleties Gotcha # 8: Failure to Distinguish Access and Visibility Gotcha # 9:.. Using Bad Language Gotcha # 10: Ignorance of Idiom Gotcha # 11:.. Unnecessary Cleverness Gotcha # 12: Adolescent Behavior.
2. SYNTAX.
Gotcha # 13:. Array / Initializer Confusion Gotcha # 14:. Evaluation Order Indecision Gotcha # 15: Precedence Problems Gotcha # 16:.. For Statement Debacle Gotcha # 17: Maximal Munch Problems Gotcha # 18:. Creative Declaration-Specifier Ordering. ..... gotcha # 19: Function / Object Ambiguity gotcha # 20: Migrating Type-Qualifiers gotcha # 21: Self Initialization gotcha # 22: Static and Extern Types gotcha # 23: Operator Function Lookup Anomaly gotcha # 24: Operator -> Subtleties.3. The Preprocessor.
Gotcha # 25: #define literals. Gotcha # 26: #define pseudofunctions. Gotcha # 27: Overuse of #if. Gotcha # 28: Side Effects in assertions.
4. Conversions.
Gotcha # 29: Converting Through void * Gotcha # 30:.. Slicing Gotcha # 31: Misunderstanding Pointer to Const Conversion Gotcha # 32:. Misunderstanding Pointer to Pointer to Const Conversion Gotcha # 33:. Misunderstanding Pointer to Pointer to Base Conversion Gotcha. # 34: Pointer to Multi-Dimensional Array Problems Gotcha # 35:.. Unchecked downcasting Gotcha # 36: Misusing Conversion Operators Gotcha # 37:.. Unintended Constructor Conversion Gotcha # 38:. Casting Under Multiple Inheritance Gotcha # 39: Casting Incomplete Types . Gotcha # 40:. Old Style Casts Gotcha # 41:. Static Casts Gotcha # 42:. Temporary Initialization of Formal Arguments Gotcha # 43:. Temporary Lifetime Gotcha # 44:. References and Temporaries Gotcha # 45: Ambiguity Failure of dynamic_cast. Gotcha # 46: misunderstanding contrariance.
5. inTILALIZATION.
Gotcha # 47: Assignment / Initialization Confusion Gotcha # 48:.. Improperly Scoped Variables Gotcha # 49: Failure to Appreciate C 's Fixation on Copy Operations Gotcha # 50:. Bitwise Copy of Class Objects Gotcha # 51:. Confusing Initialization and Assignment in Constructors . Gotcha # 52: Inconsistent Ordering of the Member Initialization List Gotcha # 53:.. Virtual Base Default Initialization Gotcha # 54: Copy Constructor Base Initialization Gotcha # 55:. Runtime Static Initialization Order Gotcha # 56:. Direct vs. Copy Initialization. Gotcha # 57: Direct Argument Initialization. Gotcha # 58: Ignorance of the Return Value Optimizations. Gotcha # 59: Initializing A Static MEMBER IN A Constructor.6. Memory and Resource Management.
Gotcha # 60: Failure to Distinguish Scalar and Array Allocation Gotcha # 61:. Checking for Allocation Failure Gotcha # 62:. Replacing Global New and Delete Gotcha # 63:.. Confusing Scope and Activation of Member New and Delete Gotcha # 64: Throwing String Litrals. Gotcha # 65: Improper Exception Mechanics. Gotcha # 66: Abusing local addresses. Gotcha # 67: Failure to Employ Resource Acquisition is initialization. Gotcha # 68: Improper Use of auto_ptr.
7. Polymorphism.
Gotcha # 69: Type Codes Gotcha # 70:. Non-Virtual Base Class Destructor Gotcha # 71:. Hiding Non-Virtual Functions Gotcha # 72:.. Making Template Methods Too Flexible Gotcha # 73:. Overloading Virtual Functions Gotcha # 74: Virtual Functions With Default Argument Initializers Gotcha # 75:. Calling Virtual Functions in Constructors and Destructors Gotcha # 76:. Virtual Assignment Gotcha # 77:. Failure to Distinguish Among Overloading, Overriding, and Hiding Gotcha # 78:. Failure to Grok Virtual Functions And Overriding. Gotcha # 79: Dominance Issues.
8. Class Design.
Gotcha # 80: Get / Set Interfaces Gotcha # 81:. Const and Reference Data Members Gotcha # 82:. Not Understanding the Meaning of Const Member Functions Gotcha # 83:. Failure to Distinguish Aggregation and Acquaintance Gotcha # 84:. Improper Operator Overloading Gotcha # 86: Friend vs. Member Operators. Gotcha # 87: Problems with increment and Decrement. Gotcha # 88: misunderstanding Templated Copy Operations.
9. Hierarchy design.
Gotcha # 89: Arrays of Class Objects Gotcha # 90:. Improper Container Substitutability Gotcha # 91:. Failure to Understand Protected Access Gotcha # 92:. Public Inheritance for Code Reuse Gotcha # 93:.. Concrete Public Base Classes Gotcha # 94: Failure to Employ Degenerate Hierarchies Gotcha # 95:. overuse of Inheritance Gotcha # 96:. Type-Based Control Structures Gotcha # 97:.. Cosmic Hierarchies Gotcha # 98: Asking Personal Questions of an Object Gotcha # 99:. Capability Queries.
Bibliography. Index. 0321125185T07192002
