Boost logo

Boost :

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

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