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".
I have written sumarized something. Is this correct:
" Exception Safety
The library requires that all operations on types used as template or function arguments provide the basic exception guarantee. In turn, all functions and algorithms in this library, except where stated otherwise, will provide the basic exceptions guarantee.
I hope not. There should be no instance in which you don't provide the basic guarantee. Fundamentally you don't have to say any of what's in that paragraph, though I don't mind it in principle. By definition, you *can't* break invariants. Unless you explicitly say you're going to leak resources, the client has a right to expect you won't, even in the face of exceptions. Nothing gives the client license to break imposed requirements, even in the face of exceptions.
In addtion some functions can provide the strong exception guarantee as long as the operations on the types used for arguments for these funtions either do not alter the global state, or provide the strong exception guarantee.
Probably an English usage error, but that means that if operations on the arguments to functions provide the strong guarantee, the functions won't provide it. I would either throw out this whole thing or rewrite it as follows: The library maintains its invariants and does not leak resources in the face of exceptions. Some library operations give stronger guarantees, which are documented on an individual basis. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com