TITLE: the cost of exceptions

AUTHOR: smeyers@netcom.com (Scott Meyers), 23 Oct 95

Doug Turner recently posted:

  In the November Microsoft System Journal, Scott Meyers says that if you add 
  try blocks to a program you should "...expect your overall code size to 
  increase by five to ten percent and your speed to go down by a similar 
  amount..."  He is not talking about the overhead of telling a compiler that 
  you want it to compile for exceptions; he specifically makes the point that 
  this *addditional* cost is related to try blocks.
  
  How should this be interpreted?  
  
The material in that MSJ article was excerpted from my forthcoming book,
"More Effective C++," and one of the problems with publishing book
excerpts is that not all the text in the book will fit in an article.
The editors at MSJ (with my tacit permission) chose to cut the following
paragraph, which is quite important in evaluating my comments above:

  But wait. How can I know this stuff? If support for exceptions is a
  relatively recent addition to most compilers (it is), and if different
  compilers implement their support in different ways (they do), how can I
  say that a program's size will generally grow by about 5-10%, its speed
  will decrease by a similar amount, and it may run orders of magnitude
  slower if lots of exceptions are thrown? The answer is frightening: a
  little rumor and a handful of benchmarks (see Item 23). The fact is that
  most people -- including most compiler vendors -- have little experience
  with exceptions, so though we know there are costs associated with them,
  it is difficult to accurately predict what those costs will be. 

I now regret I allowed this paragraph to be cut from the article.

Later, Andrew Evans posted:

  Where do I find source for the proposed ANSI/ISO library that contains the
  "auto_ptr" class? Scott Meyers mentions it in a recent article in
  Microsoft System Journal.

This is what I sent to MSJ for them to make available online:

  // The following implementation of auto_ptr is based on the one in the
  // book "More Effective C++: 35 New Ways to Improve Your Programs and
  // Designs," by Scott Meyers, Addison-Wesley, 1996. 
  
  // Please be aware that the interface for auto_ptr is still under
  // discussion by the ANSI/ISO standardization committee, so the
  // following template may not have exactly the same interface as the
  // standard template.  As of September 1995, however, this is my best
  // guess for how auto_ptr will look for compilers that lack member
  // templates. 
  
  // If your compiler fails to support the "explicit" keyword, uncomment
  // this line:
  // #define explicit
  
  template<class T>
  class auto_ptr {
  public:
    explicit auto_ptr(T *p = 0): p(p) {}
    auto_ptr(auto_ptr<T>& rhs): p(rhs.release()) {}
    ~auto_ptr() { delete p; }
    auto_ptr<T>& operator=(auto_ptr<T>& rhs);
  
    T& operator*() const  { return *p; }
    T* operator->() const { return p; }
    T* get() const        { return p; }
    T* release()          { T *oldP = p; p = 0; return oldP; }
    void reset(T *p = 0)  { delete p; p = p; }
  
  private:
    T *p;
  };
  
  template<class T>
  inline auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<T>& rhs)
  {
    if (this != &rhs) reset(rhs.release());
    return *this;
  } 

For those who are interested, I expect "More Effective C++" to be
available around the end of the year.  I'll post details to this
newsgroup when the book has been put to bed.