From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 10:54:40
Pavol Droba <droba_at_[hidden]> writes:
> On Thu, Jul 15, 2004 at 07:03:38AM -0400, David Abrahams wrote:
>> Pavol Droba <droba_at_[hidden]> writes:
>> > Such a guarantee would allow me to use a local variable of a given type
>> > without needing to worry, that it will break the guarantie of the whole
>> > function.
>> > Is this ok?
>> > How would you name such a property?
>> While I support the use of the "pure" distinction in exception-safety
>> analysis, a word of caution: be careful not to specify such a detailed
>> ES contract that it becomes unreasonably hard to use. Another risk is
>> that you'll undly constrain your future implementation choices.
>> Sometimes it makes sense to paint with a slightly broader brush and
>> and provide a simpler guarantee.
>> Further, I'm not sure it usually makes sense to use "pure" when
>> describing constraints on user-supplied operations. It stands to
>> reason that in general, the library has no knowledge of external state
>> that might be modified by a user-supplied operation and can't roll
>> back the results. It's often a reasonable shorthand to say "gives the
>> strong guarantee" when you mean "gives the strong guarantee as long
>> as the user-supplied operation is pure".
> I have written sumarized something. Is this correct:
> Exception Safety
> 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.
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.
> In addtion some functions can provide the strong exception guarantee
> as long as the operations on the types used for arguments for these
> funtions either do not alter the global state, or provide the strong
> exception guarantee.
Probably an English usage error, but that means that if operations on
the arguments to functions provide the strong guarantee, the functions
won't provide it.
I would either throw out this whole thing or rewrite it as follows:
The library maintains its invariants and does not leak resources in
the face of exceptions. Some library operations give stronger
guarantees, which are documented on an individual basis.
-- 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