Boost logo

Boost :

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.



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