From: David Abrahams (dave_at_[hidden])
Date: 2004-07-17 07:03:01
"David B. Held" <dheld_at_[hidden]> writes:
> David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>>>The library requires that all operations on types used as template
>>> or function arguments provide the basic exception guarantee. In
>>> turn, all functions and algorithms in this library, except where
> >>stated otherwise, will provide the basic exceptions guarantee.
>> I hope not. There should be no instance in which you don't provide
>> the basic guarantee.
> The idea is that the library may offer some other guarantee instead
> of the basic guarantee.
No, you can strengthen the guarantee -- in other words, offer some
guarantees in addition to the basic guarantee -- but unless the
library is going to take an "invariants don't matter because I'm about
to terminate" strategy, you must always give the basic guarantee.
>> Fundamentally you don't have to say any of what's in that paragraph,
>> though I don't mind it in principle. By definition, you *can't* break
>> invariants. Unless you explicitly say you're going to leak resources,
>> the client has a right to expect you won't, even in the face of
>> exceptions. Nothing gives the client license to break imposed
>> requirements, even in the face of exceptions.
> Well, considering that many programmers don't even know how to talk
> about exception safety, I don't think it hurts to have a reminder
> that if the library behaves in an exception-unsafe way, it's the
> user's fault.
I agree that a reminder is good, but don't agree with "if the library
behaves in an exception-unsafe way", because it's not the library
>> I would either throw out this whole thing or rewrite it as follows:
>> The library maintains its invariants and does not leak resources
>> the face of exceptions. Some library operations give stronger
>> guarantees, which are documented on an individual basis.
> Ah, but you yourself have said that the guarantees do not form a
> hierarchy, so there is no proper notion of "stronger" with respect to
> them. ;)
Whaaaa??? I never said that! Or I was delusional when I did.
> Pretty easy to say it that way though, huh? Anyway, I would
> say that many libraries do *not* offer the basic guarantee, and that
> the value in saying so is that it indicates the author has considered
> the issue and certifies that the library is minimally
Yes, but if the reader doesn't know the meaning of the term, it will
not help her. It's such a simple concept that it doesn't hurt to
spell it out.
> Saying that it maintains its invariants instead of saying that it
> gives the basic guarantee does not convey the right message, in my
> opinion, because many programmers obviously do not feel a need to
> maintain invariants in the presence of exceptions (or they would write
> more exception-safe code).
I don't see the connection. What message do you think it should send
that it does not send?
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk