Re: [boost] Re: Exception safety guarantie

From: Pavol Droba (droba_at_[hidden])
Date: 2004-07-15 08:40:40

On Thu, Jul 15, 2004 at 08:40:03AM -0400, David Abrahams wrote:
> 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.

I see. Under the term "const operation" I understand an operation that
does not alfter the state of the associated objects. Examples are
const member functions.

> 
> > - 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"

Ok. I was confused, because I was always talking about this kind of guarantee,
but everytime, somebody corrected me, that I forgot about the global state.
So I wanted to be precise.

>      
> > 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.

No, I wanted to formulate a specification for the class of algorithms, that
I have described. 

Now I see, that plain formulation "they provide strong exception guarantee"
is enough. And that is exactly the point I wanted to get to.

Regards,

Pavol