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