Exceptional C++ Style 40 New Engineering Puzzles, Programming Problems, and Solutions

by Sutter, Herb; Fuller, John

• ISBN13: 9780201760422
• ISBN10: 0201760428
• Edition: 1st
• Format: Paperback
• Copyright: 2004-08-02
• Publisher: Addison-Wesley Professional

Summary

Software "style" is about finding the perfect balance between overhead and functionality... elegance and maintainability... flexibility and excess. InExceptional C++ Style, legendary C++ guru Herb Sutter presents 40 new programming scenarios designed to analyze not only the what but the why and help you find just the right balance in your software. Organized around practical problems and solutions, this book offers new insight into crucial C++ details and interrelationships, and new strategies for today's key C++ programming techniques--including generic programming, STL, exception safety, and more. You'll find answers to questions like: What can you learn about library design from the STL itself? How do you avoid making templated code needlessly non-generic? Why shouldn't you specialize function templates? What should you do instead? How does exception safety go beyond try and catch statements? Should you use exception specifications, or not? When and how should you "leak" the private parts of a class? How do you make classes safer for versioning? What's the real memory cost of using standard containers? How can using const really optimize your code? How does writing inline affect performance? When does code that looks wrong actually compile and run perfectly, and why should you care? What's wrong with the design of std::string? Exceptional C++ Stylewill help you design, architect, and code with style--and achieve greater robustness and performance in all your C++ software.

Author Biography

Herb Sutter serves as contributing editor and columnist for C/C++ Users Journal, and is a Visual C++ architect for Microsoft

Table of Contents

Preface	ix
Generic Programming and the C++ Standard Library	1	(78)
Uses and Abuses of vector
The String Formatters of Manor Farm, Part 1: sprintf	10	(6)
The String Formatters of Manor Farm, Part 2: Standard (or Blindingly Elegant) Alternatives	16	(11)
Standard Library Member Functions	27	(4)
Flavors of Genericity, Part 1: Covering the Basis [sic]	31	(4)
Flavors of Genericity, Part 2: Generic Enough?	35	(7)
Why Not Specialize Function Templates?	42	(7)
Befriending Templates	49	(10)
Export Restrictions, Part 1: Fundamentals	59	(9)
Export Restrictions, Part 2: Interactions, Usability Issues, and Guidelines	68	(11)
Exception Safety Issues and Techniques	79	(20)
Try and Catch Me	80	(5)
Exception Safety: Is It Worth It?	85	(4)
A Pragmatic Look at Exception Specifications	89	(10)
Class Design, Inheritance, and Polymorphism	99	(52)
Order, Order!	100	(4)
Uses and Abuses of Access Rights	104	(6)
(Mostly) Private	110	(9)
Encapsulation	119	(10)
Virtuality	129	(10)
Enforcing Rules for Derived Classes	139	(12)
Memory and Resource Management	151	(32)
Containers in Memory, Part 1: Levels of Memory Management	152	(4)
Containers in Memory, Part 2: How Big Is It Really?	156	(8)
To new, Perchance to throw, Part 1: The Many Faces of new	164	(9)
To new, Perchance to throw, Part 2: Pragmatic Issues in Memory Management	173	(10)
Optimization and Efficiency	183	(30)
Constant Optimization?	184	(6)
inline Redux	190	(9)
Data Formats and Efficiency, Part 1: When Compression Is the Name of the Game	199	(5)
Data Formats and Efficiency, Part 2: (Even Less) Bit-Twiddling	204	(9)
Traps, Pitfalls, and Puzzlers	213	(32)
Keywords That Aren't (or, Comments by Another Name)	214	(7)
Is It Initialization?	221	(6)
double or Nothing	227	(3)
Amok Code	230	(5)
Slight Typos? Graphic Language and Other Curiosities	235	(4)
Operators, Operators Everywhere	239	(6)
Style Case Studies	245	(70)
Index Tables	246	(12)
Generic Callbacks	258	(9)
Construction Unions	267	(19)
Monoliths ``Unstrung,'' Part 1: A Look at std::string	286	(6)
Monoliths ``Unstrung,'' Part 2: Refactoring std::string	292	(9)
Monoliths ``Unstrung,'' Part 3: std::string Diminishing	301	(4)
Monoliths ``Unstrung,'' Part 4: std::string Redux	305	(10)
Bibliography	315	(4)
Index	319

Excerpts

The scene: Budapest. A hot summer evening. Looking across the Danube, with a view of the eastern bank.In the cover photo showing this pastel-colored European scene, what's the first building that jumps out at you? Almost certainly it's the Parliament building on the left. The massive neo-Gothic building catches the eye with its graceful dome, thrusting spires, dozens of exterior statues and other ornate embellishmentsand catches the eye all the more so because it stands in stark contrast to the more utilitarian buildings around it on the Danube waterfront.Why the difference? For one thing, the Parliament building was completed in 1902; the other stark, utilitarian buildings largely date from Hungary's stark and utilitarian Communist era, between World War II and 1989."Aha," you might think, "that explains the difference. All very nice, of course, but what on earth does this have to do withExceptional C++ Style?"Certainly the expression of style has much to do with the philosophy and mindset that goes into it, and that is true whether we're talking about building architecture or software architecture. I feel certain that you have seen software designed on the scale and ornateness of the Parliament building; I feel equally sure that you have seen utilitarian blocky (or should that be "bloc-y"?) software buildings. On the extremes, I am just as convinced that you have seen many gilded lilies that err on the side of style, and many ugly ducklings that err on the side of pushing code out the door (and don't even turn out to be swans). Style or Substance?Which is better?Don't be too sure you know the answer. For one thing, "better" is an unuseful term unless you define specific measures. Better for what? Better in which cases? For another, the answer is almost always a balance of the two and begins with: "It depends..."This book is about finding that balance in many detailed aspects of software design and implementation in C++, and knowing your tools and materials well to know when they are appropriate.Quick: Is the Parliament building abetterbuilding, crafted withbetterstyle, than the comparatively drab ones around it? It's easy to say yes unthinkinglyuntil you have to consider building and maintaining it: Construction. When it was completed in 1902, this was the largest Parliament building in the world. It also cost a horrendous amount of time, effort, and money to produce and was considered by many to be a "white elephant," which means a beautiful thing that comes at too high a cost. Consider: By comparison, how many of the ugly, drab, and perhaps outright boring concrete buildings could have been built for the same investment? And you work in an industry where the time-to-market pressure is far fiercer than the time pressure was in the age of this Parliament. Maintenance. Those of you familiar with the Parliament will note that in this picture the Parliament building was under renovation and had been in that state for a number of years, at a controversial and arguably ruinous cost. But there's more to the maintenance story than just this recent round of expensive renovations: Sadly, the beautiful sculptures you can see on the exterior of the building were made of the wrong materials, materials that were too soft. Soon after the building was originally completed, those sculptures became the subjects of a continual repair program under which they have been replaced with successively harder and more durable materials, and the heavy maintenance of the "bells and whistles" begun in the early 1900s has gone on continuously ever sincefor the pastcentury.

Rewards Program

Currently unavailable