[boost] Re: Pedantic changes to noncopyable

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-03-20 11:32:11

> From: Stephen Cleary [mailto:scleary_at_[hidden]]

> The only benefit I can think of is a compiler that is working on a part
> of code in a try block -- if it can determine that that code cannot
> throw an exception, then the try/catches there can be removed.

Remember that auto objects with non-trivial destructors imply a certain
amount of try/catch behavior.  In presence of possible exceptions they
require some overhead (perhaps nothing more than a static table) to ensure
that the correct objects are destroyed.

> There
> are *many* problems, though:
>   1) throw() will not guarantee that a function will not throw an
> exception -- it just guarantees that a different course of action will
> be taken.  Because of this, throw() can only be used as a hint to the
> compiler that the function *should* not throw an exception.

throw() guarantees that an exception will not propogate into the calling
scope from the body of the called function.  That allows some minimal
optimization.

struct T1 { ~T1(); };
struct T2 { T2() throw(); ~T2() throw(); };

foo()
{
  T1 t1;
  T2 t2;
  ...
}

The compiler can tell that the implicit call to t1.~T1() will never occur
except right after the non-throwing implicit call to t2.~T2().  Without the
throw specifications the compiler has to handle (as special cases) the
situations where an exception is thrown during construction or destruction
of t2.  As a result foo() will have some overhead (possibly no more than a
static word or two) in the case where there is no throw specification.

Of course the throw specification is typically an anti-optimization in the
body of T2::T2() and/or T2::~T2(), but that is not necessarily the case.