- Paperback: 240 pages
- Publisher: Addison-Wesley Professional (November 28, 1999)
- Language: English
- ISBN-10: 0201615622
- ISBN-13: 978-0201615623
- Product Dimensions: 7.3 x 0.6 x 9.1 inches
- Shipping Weight: 15.5 ounces (View shipping rates and policies)
- Average Customer Review: 41 customer reviews
- Amazon Best Sellers Rank: #641,026 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
Use the Amazon App to scan ISBNs and compare prices.
The Amazon Book Review
Author interviews, book reviews, editors picks, and more. Read it now
Frequently bought together
Customers who bought this item also bought
Aimed at the experienced C++ programmer, Herb Sutter's Exceptional C++ tests the reader's knowledge of advanced C++ language features and idioms with several dozen programming puzzles and explanations. This book can definitely help raise your C++ class design skills to the next level.
Based on the author's Guru of the Week Web column, this book poses a series of challenging questions on the inner workings of C++, centering around generic programming with the Standard Template Library (STL), exception handling, memory management, and class design. Even if you think you know C++ well, most of these problems will teach you something more about the language and how to write more robust classes that are "exception safe" (meaning they don't throw any handled exceptions or leak resources). Don't think this is just "language lawyering," though. The author's explanations stress sound programming principles (favoring simplicity) and idioms (such as the Pimpl idiom for class design that promotes faster compile times and better maintainability, or using "smart" auto_ptrs with STL.) Judging from the range and depth of these examples, Sutter's command of the inner workings of C++ is impressive, and he does an excellent job of conveying this expertise without jargon or a lot of theory.
After reading this book, C++ designers will learn several "best practices" of how to write robust, efficient classes that are "exception safe." Chances are you'll gain a better understanding of memory management techniques and working with STL too. For the experienced developer seeking leading-edge knowledge of some of the best ways to use C++, Exceptional C++ is both a challenging and truly worthwhile source of information. --Richard Dragan
Topics covered: Advanced C++ programming tutorial, generic programming, tips for string classes, containers and STL, temporary objects, exception-safe code tutorial, virtual functions, class inheritance, the Pimpl idiom, namespaces, memory management, C++ memory areas, overloading new and delete, using smart pointer with auto_ptr, using const, casts, and hints for better performance and code maintainability.
From the Inside Flap
Exceptional C++ shows by example how to go about solid software engineering. Along with a lot of other material, this book includes expanded versions of the first 30 issues of the popular Internet C++ feature Guru of the Week (or, in its short form, GotW), a series of self-contained C++ engineering problems and solutions that illustrate specific design and coding techniques.
This book isn't a random grab-bag of code puzzles; it's primarily a guide to sound real-world enterprise software design in C++. It uses a problem/solution format because that's the most effective way I know to involve you, gentle reader, in the ideas behind the problems and the reasons behind the guidelines. Although the Items cover a variety of topics, you'll notice recurring themes that focus on enterprise development issues, particularly exception safety, sound class and module design, appropriate optimization, and writing portable standards-conforming code.
I hope you find this material useful in your daily work. But I also hope you find at least a few nifty thoughts and elegant techniques, and that from time to time, as you're reading through these pages, you'll suddenly have an "Aha! Gnarly!" moment. After all, who says software engineering has to be dull? How to Read This Book
I expect that you already know the basics of C++. If you don't, start with a good C++ introduction and overview (good choices are a classic tome like Bjarne Stroustrup's The C++ Programming Language, Third Edition 1 or Stan Lippman and JosEe Lajoie's C++ Primer, Third Edition 2 ), and then be sure to pick up a style guide like Scott Meyers' classic Effective C++ books (I find the browser-based CD version convenient and useful).3
Each item in this book is presented as a puzzle or problem, with an introductory header that looks like this:
ITEM ##: THE TOPIC OF THIS PUZZLE DIFFICULTY: X
The topic tag and difficulty rating (typically anything from 3 to 9-1/2, based on a scale of 10) gives you a hint of what you're in for. Note that the difficulty rating is my own subjective guess at how difficult I expect most people will find each problem, so you may well find that a given 7 problem is easier for you than another 5 problem. Still, it's better to be prepared for the worst when you see a 9-1/2 monster coming down the pike.
You don't have to read the sections and problems in order, but in several places there are "miniseries" of related problems that you'll see designated as "Part 1," "Part 2," and so onosome all the way up to "Part 10." Those miniseries are best read as a group. How We Got Here: GotW and PeerDirect
The C++ Guru of the Week series has come a long way. GotW was originally created late in 1996 to provide interesting challenges and ongoing education for our own development team here at PeerDirect. I wrote it to provide an entertaining learning tool, including rants on things like the proper use of inheritance and exception safety. As time went on, I also used it as a means to provide our team with visibility to the changes being made at the C++ standards meetings. Since then, GotW has been made available to the general C++ public as a regular feature of the Internet newsgroup comp.lang.c++.moderated, where you can find each new issue's questions and answers (and a lot of interesting discussion).
Using C++ well is important at PeerDirect for many of the same reasons it's important in your company, if perhaps to achieve different goals. We happen to build systems softwareo for distributed databases and database replicationoin which enterprise issues such as reliability, safety, portability, efficiency, and many others are make-or-break concerns. The software we write needs to be able to be ported across various compilers and operating systems; it needs to be safe and robust in the presence of database transaction deadlocks and communications interruptions and programming exceptions; and it's used by customers to manage tiny databases sitting inside smart cards and pop machines or on PalmOS and WinCE devices, through to departmental Windows NT and Linux and Solaris servers, through to massively parallel Oracle back-ends for Web servers and data warehouseso with the same software, the same reliability, the same code. Now that's a portability and reliability challenge, as we creep up on half a million tight, noncomment lines of code.
To those of you who have been reading Guru of the Week on the Internet for the past few years, I have a couple of things to say:
Thank you for your interest, support, e-mails, kudos, corrections, comments, criticisms, questionsoand especially for your requests for the GotW series to be assembled in book form. Here it is; I hope you enjoy it. This book contains a lot more than you ever saw on the Internet.
Exceptional C++ is not just a cut-and-paste of stale GotW issues that are already floating out there somewhere in cyberspace. All the problems and solutions have been considerably revised and reworkedofor example, Items 8 through 17 on exception safety originally appeared as a single GotW puzzle and have now become an in-depth, 10-part miniseries. Each problem and solution has been examined to bring it up to date with the then-changing, and now official, C++ standard.
So, if you've been a regular reader of GotW before, there's a lot that's new here for you. To all faithful readers, thanks again, and I hope this material will help you continue to hone and expand your software engineering and C++ programming skills. Herb Sutter
1. Stroustrup B. The C++ Programming Language, Third Edition (Addison Wesley Longman, 1997).
2. Lippman S. and Lajoie J. C++ Primer, Third Edition (Addison Wesley Longman, 1998).
3. Meyers S. Effective C++ CD: 85 Specific Ways to Improve Your Programs and Designs (Addison Wesley Longman, 1999). An online demo is available at meyerscd.awl.
Top customer reviews
The Good: it's refreshing to see each Item given in quiz format, especially if you've already read 3-4 short-essay C++ advice books (anyone considering "Exceptional C++" should at a minimum first read Meyers' "Effective C++, Third Edition"). Another factor that makes this book pleasant to read is the laid-back writing style. For example, when discussing a confusing piece of code Sutter says in a footnote: "the programmer of Derived ought to be taken out into the back parking lot and yelled at." (Item 21); similarly, when he first introduces the pimpl pointer he adds "//MYOB" (Item 23). Moving on to the themes covered, it should be noted that the book's title is mainly a pun: Sutter includes substantive material on a variety of topics, most notably on containment versus inheritance, the pimpl idiom, and name lookup. At a more fine-grained level, this book contains lots of fascinating tidbits of information. A few examples: a) publicly inheriting from char_traits<char> does not necessarily violate the Liskov Substitution Principle (Item 3), b) private inheritance does not need to keep us from using a derived object polymorphically as a base -- inside the derived object's own member functions and friends (Item 24), c) when calling a function inside a class, if the compiler finds a member it won't bother trying to use Koenig lookup to find free functions (Item 32), d) many of the counter-intuitive aspects of auto_ptr's interplay with change of ownership can be eliminated simply by using const auto_ptr (Item 37) -- of course, in this day and age it's better to avoid auto_ptr altogether, e) comparing pointers into string literals is undefined, so compilers are allowed to store string literals in overlapping areas of memory as a space optimization (Item 38), f) finally, we cannot use static_cast to go from char* to unsigned char* (Item 44). Despite the breadth of the material, there's no denying that one of the finest aspects of this volume is the 10-part miniseries on designing generic containers that are exception-safe (work properly in the presence of exceptions) and exception-neutral (propagate all exceptions to the caller). Regarding the style of the presentation, it's worth noting that certain Items end with a Summary of the lessons learned: this is very helpful when picking up the book months after having finished it. The same goes for many of the guideline boxes that the author has included. Some of these are very good reference material, e.g. the guideline in Item 20 on making an operator a member versus a nonmember function. This box in some senses typifies Sutter's writing: not always easy to read, but well structured and authoritative.
The Bad: in many cases the Item titles are completely uninformative (e.g. "Writing Exception-Safe Code -- Part 7"). On a different note, the writing is often not page-setting aware: Sutter reproduces code or text that we can still see on the facing page (e.g. pp. 4 & 5) or even on the same page (p. 22). The space wasted on duplicating things we can already see might have been dedicated to a few more clarifications (e.g. the return value optimization is mentioned in Items 10 & 46 but is never explained). A similar issue arises when Sutter flat-out repeats material already shown in a previous Item (e.g. Items 31 & 32). A related point is that some of the guideline boxes are too abstract: they tend to generalize the lesson learned and therefore make sense only when you read the entire Item. As a result, different Items sometimes have identical guidelines. This has two unwanted consequences: i) it essentially wastes space that could have been put to better use (as above), and ii) it interferes with skimming, since some of the guidelines are simply too vague to constitute a tangible lesson (e.g. "Know about and use design patterns.", Item 23). In connection to the latter point, let me note that Sutter (or maybe Alexandrescu) did a better job in the "Summary of Summaries" contained in "C++ Coding Standards". At a more detailed level, I also spotted a few more specific (minor) problems: a) in Item 5 the author uses O (that's uppercase O) to denote a template type parameter, a bad practice if ever there was one. b) In Item 23 we read: "you can get fancy and make method a nonclass template parameter instead." However, "nonclass template parameter" is not a C++ term. Perhaps Sutter wanted to say "non-type template parameter" but that wouldn't make sense either, since in the code he shows a type template parameter. c) Item 33 violates Item 23's guideline to prefer the Template Method pattern over public virtual functions. d) Item 44's guideline says "Prefer new-style casts" but Item 5 uses old-style casts. e) Item 43 first recommends const pass-by-value in a function definition and then criticizes a function definition with const pass-by-value by saying that this is "unuseful and misleading at best." f) Finally, in Item 21 Sutter writes: "Some authors even argue that 'void main()' might be standard-conforming. It isn't. It never was, not even in the 1970s, in the original pre-standard C." The problem is, "int main()" wasn't standard-conforming either in those bygone times (nothing was).
Sutter will probably produce a second edition of this book in the not too distant future. Even so, this doesn't mean that the book is out of date: many Items could be re-written in C++11, but most will stand you in good stead for many years to come (a glaring exception being Item 37 on auto_ptr) and would probably help you understand the C++11 simplifications more deeply. Overall, this book is a classic whose author is extremely knowledgeable in all things C++, so it's definitely worth reading. However, despite having been first published more than a decade ago, it does suffer from some presentation issues and minor inconsistencies, which is why I'm giving it 4 stars.
If you aren't a C++ expert but at least can find your way, make sure you have Stroustroup's on your table when you get to this. Try to answer every question on this book with the help of Stroustroup's. You will learn *a lot* from the experience, and have a lot of fun, too. Also, if you run everything you do by your compiler, you will find compiler bugs, which for me is a plus because saves time in the long run.
As for the exercises themselves, all of them, without exception, are worth every penny. Not a single one has an obvious answer (a perfect one - sure you can give some decent if you know C++ well), and from all of them you will learn something valuable.
Finally, a quick list of the topics, since Amazon.com doesn't have one online at this time:
Generic Programming and the C++ Standard Library. Exception-Safety Issues and Techniques. Class Design and Inheritance. Compiler Firewalls and the Pimpl Idiom. Name Lookup, Namespaces and the Interface Principle. Memory Management. Traps, Pitfalls and Anti-Idioms. Miscellaneous Topic.
Each of the topic has 4-7 subtopics, each of them with a few exercises.
Don't miss this book.
1. It was written from the generic library writer point of view.
2. The difficulty of writing exception safe code is rated artificially low. Dealing with exception safety issues is rated at difficulty <= 9, at the same time trivial class construction issues (like passing parameters by const reference) are rated at 7.
IMHO, the contents of this book does contradict its main advice about the possibility for mere mortals to use c++ exceptions beyond the absolute minimum of catching them at the origin.
So, if you are not a member of small super-guru team writing general purpose library (like boost or may be just working for thoughtworks) you will be much better off by not using exceptions at all. Especially if you are working on a large or very large project, where involvement of under-qualified engineers is inevitable over the long run.