Re: [boost] Re: Re: Re: In-place construction for variant

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-29 23:13:16

--- Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
[...]
> > > > struct type
> > > > {
> > > >   //invariant is x + y = 10
> > > >   int x;
> > > >   int y;
> > > >
> > > >   void f( int n )
> > > >   {
> > > >      x = n;  //* invariant is broken
> > > >      f1();  //* is this allowed?
> > > >      y = 10-n;  //* invariant restored
> > > >   }
> > > >
> > > The way I see it, if f1() is not public, then the above is most likely
> OK.
> > > If is it public, then it is most likely not OK.
> >

[...]

> Invariants are realted to design *contracts* and not all calls are routing
> contract messages. Implementation calls typically don't, and as you pointed
> out, outside calls might be also contract unrelated, thus the invariant need
> not hold during the call.

You mentioned before:
> > > If is it public, then it is most likely not OK.

So "most likely" means "if the public methods contract related"...
if f1() is contract unrelated, then it is Ok?

Anyway I'd really like to look at a systematic discussion 
of the basic guarantees concept and how it applies to real 
life design. What the best techniques are and how to
make sure that basic/strong guarantees are part 
of the complex systems design?

Eugene

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/