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

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-19 13:49:29

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
> > From: <scleary_at_[hidden]>
> > > From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
> > > > From: "David Abrahams" <david.abrahams_at_[hidden]>
> > > > > From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>

> > - Currently exception specifications imply additional run-time overhead.
>
> Only on some implementations.

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

[snip]
> I think you misunderstand the standard. The presence of "throw()" on a
> signature in the standard does not actually imply that an
> exception-specification must be present. It is a shorthand way of saying
> "will not throw an exception". This is a confusing notation, but don't blame
> me (please): I didn't invent it.

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.

> Since the standard states quite clearly that the behavior is undefined if
> the user's destructor throws an exception, there's a strong case to be made
> that there's no way a user's conforming code can detect whether there's an
> exception-specification on the signature anyway.

Yes. This is why I think that changing the behaviour might be feasible - if a
better alternative is found. Of course, the technique I've described isn't
perfect - it is an attempt to make the behaviour more useful.

> Please, let's try not to make this personal.

I agree. Please accept my apology.

[snip - lots of thought provoking stuff]
> I think you're the one that needs to explain things to us, if you want your
> ideas to gain acceptance ;-)

hmn... I think that this is a valid point. I think that if an implementation
alternative can not be described or analyzed satisfactorily it should be
avoided.

> > I believe that the current situation is such that the number of
> > destructors out there that might throw greatly outnumbers the number of
> > destructors that don't. Because of this, I think that it is useful to
> consider
> > approaches for making software more robust even in the current situation.
> > Sometimes tolerating minor faults is preferable to termination.
>
> 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.

> Still, as I have said, I don't mind your improvement to shared_ptr, though I
> am lukewarm to it. I have grave reservations about documenting it, however.
> If we can't document it, it has no meaning in a standards context.

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. Anyway, I'm open to hear other thoughts
on this subject. Perhaps someone has invented a better mechanism for dealing
with (legacy) objects that might throw in their destructors.