Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-24 14:15:16


"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20031024171237.GP22941_at_lenin.felcer.sk...
> [...]
> So these are constraints. I don't know what kind of guarantie
> can be implicated from them, except for those claims that I
> have already stated.
> [...]

Well, what I should have mentioned, and what Dave implies
in another post, is that half of exception safety analysis involves
imposing requirements on your inputs. So first of all, you
want to require that all component operations at least give you
the basic guarantee. If that then gives you the basic guarantee
for most of your algorithms, regardless of the actual types
used, then you can just say: "For the following algorithms, the
basic guarantee is ensured".

In some cases, you can get a better guarantee by increasing
the requirements. For instance, you might be able to get the
strong guarantee by requiring that some operation be nothrow,
and that operation might naturally be nothrow most of the time
anyway (such as operator==). You might not have any cases
like this, but it's worth keeping in mind.

So basically, your table probably doesn't need to include every
operation in every function. However, I think it does need to
include every function, stating the minimum guarantee provided.
Whether you want to state how to get a stronger guarantee or
not is up to you. Usually, that means how to get the strong
guarantee when you are only promising the basic (since the
nothrow guarantee requirements are trivial to state).

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk