Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-11-03 13:31:23

--- David Abrahams <dave_at_[hidden]> wrote:
> No. The *definition* of "invariant" as used in stateful programming
> allows invariants to be temporarily broken, because it's basically
> impossible to write stateful software of any interesting complexity
> that doesn't break them temporarily. As soon as you build a class
> whose invariant requires keeping two different things in synch, you
> have to be able to break the invariant to modify the class.

I agree, especially if the two things have anything
to do with hardware.
One of my points was that in practice, anything
can happens while invariants are "temporarily" broken.

> This has *nothing* whatsoever to do with the basic guarantee, other
> than that the basic guarantee is phrased in terms of invariants. Any
> condition arising from this fact that you can conjure up with
> exceptions can also be created without them. I suggest you drop
> discussion of the basic guarantee and exceptions for the time being and
> just look at invariants in stateful programming.

The point of my question was how to use basic guarantees
in practice especially in case of an exception.
Usually I am making two assumptions.
If there is an an exception then:
1. There is a problem with the hardware.
2. The program is incorrect and the invariants,
   integrity of the memory and program stack can be broken.

In both cases, I don't think that it is safe to do anything.
Do program invariants or basic guarantees change anything
in how you handle exceptions?


Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

Boost list run by bdawes at, gregod at, cpdaniel at, john at