"David B. Held" <dheld@codelogicconsulting.com> writes:
David Abrahams wrote:
[...]
Ah, but you yourself have said that the guarantees do not form a hierarchy, so there is no proper notion of "stronger" with respect ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to them. ;) ^^^^^^^^ Whaaaa??? I never said that! Or I was delusional when I did.
Well, perhaps you remember a thread in which I suggested another guarantee that I called the "smart guarantee" which was a cross between the strong and the basic guarantee. You argued that one could invent any number of guarantees that offer different promises and which could not be ordered in any purely objective way. It was a fairly convincing argument at the time. Are you going to retract it? ;>
Not at all. But I never said the marked thing above. Certainly any guarantee that only adds requirements to another is stronger. It's a partial order. There are plenty of pairs of guarantees that have an ordering relationship, and plenty of others that don't.
Saying that it maintains its invariants instead of saying that it gives the basic guarantee does not convey the right message, in my opinion, because many programmers obviously do not feel a need to maintain invariants in the presence of exceptions (or they would write more exception-safe code). I don't see the connection. What message do you think it should send
[...] that it does not send?
That it maintains invariants *in the presence of exceptions*.
Quoting my original suggestion:
... The library maintains its invariants and does not leak resources in the face of exceptions. Some library operations give stronger ^^^^^^^^^^^^^^^^^^^^^^^^^ ...
Perhaps we have an "and" associativity/ambiguity problem here? It meant the same as this when I wrote it: ;-) In the face of exceptions, the library maintains its invariants and does not leak resources.
The latter part is implicit, but if the user isn't thinking in terms of exception safety to begin with, then they may well miss that part. When you say "provides the basic guarantee", if the user is not familiar with exception safety, she will at least have an opportunity to investigate it. Of course, you could just say both.
Which is what I suggested in another message. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com