[boost] Re: [string algo review] exception specification

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-24 03:49:40

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031023211216.GC22941_at_lenin.felcer.sk...
> [...]
> An algorithm has no internal state, so its integrity as a
> component is always preserved.

You have to remember the context in which Dave wrote those
definitions.  He was looking at the standard library in particular,
so he was looking at a lot of member functions.  However, the
only thing special about a member function is the hidden 'this'
parameter.  I think a better way to say it is that the basic
guarantee ensures that a function preserves the invariants of
its arguments and any global state it modifies.  Phrased this
way, it becomes more obvious that non-member functions
don't automatically give the basic guarantee.

> Algorithms can only provide exception guaranitie for
> arguments they work with.

Exactly.

> In other words, this guarantie is always relative.

False.  The guarantee is defined in terms of the invariants
of every argument that could be passed to the function.  If
the function's interface allows an argument with an invariant
that the function does not preserve, then the function does
not give the basic guarantee.  You could argue that
arguments could have contrived invariants that would make
the basic guarantee impossible to ensure, but then, you
could argue that the function's interface is documented to
not allow those as valid arguments.

Also note that a template function is really a family of
actual functions, and each of those functions could provide
a different guarantee.  That is, the guarantee offered by a
template function set could (and probably is) a function of
the types of the template arguments (I've used the overloaded
forms of 'function' and 'argument' way too many times in the
last two paragraphs).

> [...]
> 1. The library alway manages the external components only
> through operations defined for them (i.e. it can never access
> their internal state, if no operation allows it).
>    If all such operations provide "basic exception guarantie",
>    naturaly this guarantie is preserved by an algorithm

That doesn't follow.  The arguments to a function might allow
operations that all give the basic guarantee, but that does not
mean that the function itself gives the basic guarantee.

> 2. None of the algorithms in this library throws an exception
>    on its own, therefore if all operations used by a particular
>    algorithm provide "no-throw" guarantie, this guarantie is
>    preserved.

This is a useful and important thing to note.

> 3. "Strong" guarantie is always preserved for constant and
>    pass-by-value arguments. (this is obvious, but important to
>    mention)

But arguments don't give exception safety guarantees.  Only
functions do, and if a function contains persistent state or
has access to global or otherwise external data, then just
because the arguments are const or pass-by-value does not
mean that the function gives the strong guarantee.  This may
sound pedantic, but the whole point of exception safety is
to make sure you don't get caught by one overlooked item.
That's why it's important to explicitly state whether function
f() gives the strong guarantee or not.  Don't make the user
look at the signature and go: "Oh, that only takes arguments
by value, so I assume this functions gives the strong guarantee."
And definitely don't make the user look at the implementation
to determine the guarantee.

> These definitions are sound, but does not provide many hints,
> what level of guarantie is given for a particular algorithm.

Which is why you should state the guarantees as a function
of the operations involved.

> [...]
> So this is the summary. It would be possible to specify for
> each algorithm a table with specific requirements to give the
> specific guarantie. It would be quite chalenging to do it
> properly,

Indeed!

> but the question is if it would be usable at all?

Yes!  I think this type of rigor is increasingly important.
It's bad enough that most exceptions are more or less
ignored in a lot of application code.  It's about time we
started paying more attention to exception safety.
You can only evaluate the safety of your own code when
you know the safety of the functions that your code calls.
Thus, an exception safety analysis is something that I
really think should be required of every Boost library.

> If requested, I can provide an example of such a table for
> one algorithm.

Please do.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003