Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2004-07-15 07:43:24

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.

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.


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