Boost logo

Boost :

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

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

  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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at