Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-07-16 15:59:59

--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: Howard Hinnant <hinnant_at_t...>
> > David Abrahams wrote on 7/16/2000 11:29 AM
> > >I'm surprised to hear that they
> > >crept back in.
> >
> > No I don't think they should be banned. Though I will admit that
I would
> > vote against they're use in every project I'm currently familiar
> > But I think they should be considered on a case by case basis,
and not
> > banned with a blanket statement. They provide a runtime behavior
> > could be desirable in some circumstances.

To reiterate my position, I think we ought to ban them only _as a
general rule_. I take this position in part because even seasoned
programmers tend to misuse exception-specifications, misinterpreting
them as a convenient way of specifying the exceptions a function may
throw. If in specific cases the use of exception-specifications can
be shown to be an advantage on a particular compiler, then by all
means, we should allow them to be used. Regarding the runtime
behavior, well, I'm sure most of you know how I feel about that:
in most cases something sufficiently similar and useful (and less
deadly) can be achieved with try/catch blocks. If we really want
exactly the behavior of an exception-specification, then by all means
we should use an exception-specification! So, what I'm saying is that
the use of exception-specifications should be strongly discouraged,
which is what I thought we had decided all along.

> Given the state of current compilers exception specifications
> usually do more harm than good on inline functions. It's
> unforunate that this is true, because the "throws nothing"
> specifications in shared_ptr aren't there for runtime behavior,
> they are there as *specifications* that certain operations will
> not throw, by design. If we are forced by low compiler quality
> to remove the specs we should add comments and documentation so
> that users can count on this design.

That is arguably a better approach anyway. I could have _sworn_
that's what we decided to do.

> For non-inline functions "throws nothing" specs may allow
> optimizations that help more than their overhead hurts.

Maybe. That might even be true for inline functions; it really
depends on the compiler. In my experience the negative effects on a
compiler which can't use the optimization are much greater than the
positive effects on a compiler which can. That's why I'd like to have
a general guideline which is violated only with suitable
justification, rather than having to prove this point to each new
library author.


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