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

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-30 00:56:19

On Wed, Oct 29, 2003 at 05:29:29PM -0800, E. Gladyshev wrote:
> Are there any special considerations 
> for breaking invariants and calling other methods
> of the broken object internally?
> 
> 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?
>      y = 10-n;  //* invariant restored
>   }
> 
>   //can f1()/f2() or any internal method 
>   //assume that invariant is Ok
>   void f1() {}
>   void f2() {}
> };
> This becomes much more complicated if you add
> complex polymorphic hierarchies.

I'm pretty sure that sometime a few years ago I read a research paper
or two in software engineering that tried to offer a formal model for
all of this (I think in the context of Java, and trying to come up with
a unit testing methodology).  But of course I can't track down any of
the references now.  Rats.

I seem to recall that there are annoying subtleties in cases involving
either dynamic dispatch or calling out to "outside code" which may
contain an alias to "this" object.  

I don't think that the papers I'm remembering dealt with issues like the
basic or strong guarantees.

At the end of the day, in the general case I think it just comes down to
"it's hard to build correct software, especially in the presence of
effects".  I don't recall any particularly useful morals or recommended
practices coming from the papers I'm thinking of.

(If you're really concerned about this in practice, the "paranoia"
method, while potentially overly restrictive, may help.  Just turn your
invariant into a const method returning a bool, and then assert() it at
the start and finish of every method in the interface.  Yuck.)

-- 
-Brian McNamara (lorgon_at_[hidden])