Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-01 16:16:28

"E. Gladyshev" <egladysh_at_[hidden]> writes:

> --- David Abrahams <dave_at_[hidden]> wrote:
> [...]
>> Can you give a "scientific" definition of what you mean by
>> "scientific?"
> I am not sure... some links/discussions/papers/books
> that elaborate on how and when object invariants
> can be broken and how to deal with that practically.
> I'd be especially interested to see how basic guarantees are useful
> in practical C++ programming. Perhaps some practical usage cases.

Have you read the analysis section of

The guarantees are abstractions which help you to reason about program
behavior hiding irrelevant details and highlighting important ones.

> Are there any special considerations for breaking invariants and
> calling other methods of the broken object internally?

Not usually.

> You can imaging some examples like the following.
> struct type
> {
> //invariant is x + y = 10
> int x;
> int y;
> void f( int n )
> {
> x = n; //* invariant is broken
> f1(); //* is this allowed?

Depends on your coding standard, I guess. It's not inherently unsafe.

> y = 10-n; //* invariant restored
> }
> //can f1()/f2() or any internal method
> //assume that invariant is Ok

Not if called in that way by f; it's up to the class designer.

> void f1() {}
> void f2() {}
> };
> This becomes much more complicated if you add
> complex polymorphic hierarchies.
> It seems that I am not alone who is confused
> about this stuff.

I think you should check out discussions of invariants in literature,
e.g. Bertrand Meyer's discussions of Eiffel. Then come back and
think of exception-safety in that context.

Dave Abrahams
Boost Consulting

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