Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-19 14:34:20

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> hmn... Which implementations do not impose a significant run-time
> (or static size) overhead with inlined functions using exception
> specifications?

Codewarrior, for one. Empty exception specifications actually reduce the
static size by allowing the compiler to eliminate EH that it would otherwise
need to insert.

> Thanks! Assuming that you are right, then this is indeed one thing that I
> previously slightly misunderstood. Let me see. In practice, this would
> that a fully conforming implementation could omit the exception
> (possibly conditionally in "release builds") and avoid any possible

There has been a little argument about this in the committee, but I think
that is correct.

> > I agree. However, I doubt that your improvement will help much. Any
> > designed to be exception-safe is written with an awareness of what might
> > throw. Even if shared_ptr::reset can tolerate a throwing destructor, can
> > code calling reset tolerate a throwing reset (and so on...)?
> Well, the idea is that the code calling reset() is typically new code
> with a basic understanding of exception safety and as such would be more
> tolerant to exceptions. However, just preventing the leak of the new
> and double deletion of the old object, which could cause a core dump
> the program has a chance to unwind the stack completely, might make a big
> difference.

Maybe. Let me give you a concrete example: I have an object which I'm
putting in a standard container. My object contains an auto_ptr. So now
we're discussing what undefined behavior occurs when the object it holds
throws an exception in its destructor - you're hoping that it will be
benign. We have promised the standard library implementor that we won't
throw from our destructor. If we break our promise, what is the likelihood
that the container will be destructible. Worse, the container might be some
persistent bit of important program state. What is the liklihood that the
whole-program invariants have been preserved? I prefer not to speculate, but
since you asked (actually, I asked ;-)), I think the probablity of benign
recovery is very low.

> I'll have to see about what can be done about the documenting aspect. As
> explained earlier, I'm developing a resource library that could make use
> this feature. If it turns out that the feature is too difficult to
> then I should probably leave it out.

I don't think it's difficult to document. The problem is that documenting it
complicates the world for users of the library. They no longer can rely on
unconditional nothrow behavior from certain operations. Maybe that's not so
bad a complication in this case, but I'm reluctant because I think the real
power you gain for the complication is very low. I'm wary of setting a
precedent by tring to document behavior in case a destructor throws before
we really understand what that means for a whole program.


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