On Thu, Jul 15, 2004 at 07:03:38AM -0400, David Abrahams wrote:
Pavol Droba <droba@topmail.sk> 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