From: Pavol Droba (droba_at_[hidden])
Date: 2004-07-15 07:02:16
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
- 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)
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 think that this is reasonable, but I'm not sure how to correctly
formulate the specification.
Regards,
Pavol