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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk