[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 07:40:03

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".
>> 
>
> What I want to cover is quite a large number of algorithms in the lib,
> that can supply strong guagantee if
> - const operations are pure

I still don't know what a const operation is.  The power of good
distinctions is in their simplicity; let's try not to add too many new
terms.

> - all operations for a specific type, change only the object itself and not
>   the global state (or at least, they give a strong guarantee when they do)

That's just the strong guarantee; no need to complicate terminology.

Consider the language precedent set in the standard:

  "If an exception is thrown, there are no effects other than those
  of <user-supplied operation>"

and

  "If an exception is thrown other than by <user-supplied operation>,
  there are no effects"
     
> IMHO this is very natural behaviour for most of the containers.
>
> To say it in plain words, I want algorithm, that change only local variables
> and use const inputs to have strong guarantee if the inputs behave
> well.

I don't understand the above; it sounds like a design criterion but
IIUC your code is already written and you're just trying to document
it.  Nobody cares (at this point) what you're doing inside your
function with local variables and inputs, so I think talking about
that stuff is heading in the wrong direciton.

> I think that this is reasonable, but I'm not sure how to correctly
> formulate the specification.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com