This CD includes the following articles. If you already know why they're here, just choose the one you want. Otherwise, please read my introductory comments below.

• Exception Handling: A False Sense of Security by Tom Cargill .

• Coping with Exceptions by Jack W. Reeves.

• Exception-Safe Generic Containers by Herb Sutter.

• Counting Objects in C++ by me (i.e., Scott Meyers).

• A First Look at C++ Program Analyzers by me and Martin Klaus.

When I wrote More Effective C++ in 1995, I had this to say about exception-handling and C++:

There is much the C++ community does not know about writing programs using exceptions, including, for the most part, how to do it correctly. There is as yet no agreement on a body of techniques that, when applied routinely, leads to software that behaves predictably and reliably when exceptions are thrown.

• "Exception Handling: A False Sense of Security" by °Tom Cargill. It's hard to overestimate the influence this article had on the C++ community when it appeared in the November-December 1994 issue of the °C++ Report. At that time, most C++ programmers thought there was little more to exceptions than try, throw, and catch. Tom showed just how wrong that was. (They didn't call his column "C++ Gadfly" for nothing.) He demonstrated that writing exception-safe code isn't just hard, it's really hard. In addition, Tom challenged the C++ community to come up with rules for writing exception-safe programs. It took years before those rules began to appear in print, and the difficulties Tom identified affected work on the standard C++ library (see Items onMouseOver="self.status='Familiarize yourself with the C++ standard library.'; return true" onMouseOut="self.status=self.defaultStatus">E49 and onMouseOver="self.status='Familiarize yourself with the C++ standard library.'; return true" onMouseOut="self.status=self.defaultStatus">M35) until the final days of its specification.
  
  
• "Coping with Exceptions" by °Jack W. Reeves. Jack was not the first to respond to Tom Cargill's challenge, but his March 1996 °C++ Report article was the first to describe how to achieve exception safety in a way I could easily understand. He explained how even normal programmers could write code that behaves well in the presence of exceptions.
  
  
• "Exception-Safe Generic Containers" by °Herb Sutter is a wonderful companion to Jack Reeves' article, because it focuses on how to achieve exception safety in templated containers. This is a tricky business, because the containers' member functions have no idea what types of objects they contain, what types of exceptions they may throw, or the conditions under which they may throw them. Jack Reeves considered many of these problems in his article, but Sutter's approach is both different and, in my mind, simpler. Certainly they are both instructive. Sutter's original article appeared in two installments in the °C++ Report (September and November-December 1997), but for this CD, Herb has allowed me to combine them into a single article.
  
  

• "Counting Objects in C++" by me (i.e., °Scott Meyers). In onMouseOver="self.status='Constructors, Destructors, and Assignment Operators'; return true" onMouseOut="self.status=self.defaultStatus">Item E14, I describe a simple way to keep track of how many objects of a class exist, but I fail to address the fact that I write the code twice, once for each of two classes. Shame on me; code duplication is bad. It seems like it should be easy to make the object-counting code reusable, but it turns out to require an understanding of public and private inheritance, templates, the interaction of new and delete, the implementation of virtual functions, implicit type conversions, and valid compiler optimizations. In this April 1998 °C/C++ Users Journal article, I prattled on about all these issues.
  
  
• "A First Look at C++ Program Analyzers" by °me and °Martin Klaus. In the preface to the original 1992 edition of Effective C++, I noted my interest in lint-like tools for C++, and in this article from the February 1997 issue of °Dr. Dobb's Journal, Martin and I examined five C++ compilers and nine lint-like programs to see how well they were able to identify 36 problematic conditions in C++ source code. The raw data in this article are now out of date, but the analysis remains valid. Furthermore, the links to home pages for commercial lint-like tools make this a convenient starting point for developers interested in tools of this nature.