Re: [boost] Stronger exception safety guarantee for smart_ptr.res et()

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
performance
> (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
have
> previously slightly misunderstood. Let me see. In practice, this would
mean
> that a fully conforming implementation could omit the exception
specifications
> (possibly conditionally in "release builds") and avoid any possible
overhead.

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
program
> > 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
the
> > code calling reset tolerate a throwing reset (and so on...)?
>
> Well, the idea is that the code calling reset() is typically new code
written
> with a basic understanding of exception safety and as such would be more
> tolerant to exceptions. However, just preventing the leak of the new
object,
> and double deletion of the old object, which could cause a core dump
before
> 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
I've
> explained earlier, I'm developing a resource library that could make use
of
> this feature. If it turns out that the feature is too difficult to
document,
> 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.

-Dave