Re: [boost] Exception specifications in smart_ptr.hpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-07-17 08:29:13

From: "Lois Goldthwaite" <loisg_at_[hidden]>

> Some of our tests in Hawaii showed that at least one compiler was able to
use the
> "throw()" specification to generate more optimized code, not less.

In some cases, only. Every bit of code in the system needs to agree to use
the throw() specification religiously. Take this imaginary example:

template <class T>
inline boost::auto_ptr<T>::~auto_ptr() throw()
{
    delete this->get();
}

What happens if T's destructor does not have an empty
exception-specification? I don't care how smart the compiler is; it is
required to generate an implicit try-catch block so it can call the
unexpected handler in case T's destructor throws. Since the auto_ptr
destructor is probably inlined, but T's destructor is likely not inlined,
this try/catch block is probably duplicated all over the client code.

You see, even with a smart compiler you can't just sprinkle in some empty
exception-specifications and expect your code to improve, any more than you
can do that with inline functions. In fact, the number of compilers that can
use exception-specifications to advantage is still way smaller than the
number that can take advantage of inlining.  I have no problem with the
judicious use of exception-specifications as long as we measure (or
carefully reason about) what we're doing and show that it is a win.

> I thought we had a general principle to write "ideal" code and let the
compilers
> catch up. If our target compilers are capable of compiling code with
exception
> specifications, albeit with some loss of efficiency, I think this is a
> documentation issue.
>
> As I understand the purpose of throw specs, they should contribute to
greater
> robustness of code.

That may be their purpose, but do they really do it? If so, how?

> and I believe there is some talk of strengthening the
> language support for them next time around.

**** AND HEREIN LIES THE ISSUE *****
The biggest problem with exception-specifications is that programmers use
them as though they have the effect the programmer would like, instead of
the effect they actually have. We shouldn't make decisions based on what
exception-specifications might turn into someday.
************************************

> Why pessimize the source code out of
> fear the (currently inadequate) compiler will pessimize the output?
(Unless, of
> course, the output is so woefully inefficient that it becomes absolutely
> necessary, but that should be a case-by-case decision, as Howard says.)

Oh, I completely agree. But equally, we should avoid premature assumptions
about what is likely to be an optimization.

-Dave