On Saturday 09 October 2010 08:39:30 bearophile wrote:
> J. Berger:
> > This is more or less what Jonathan said in his last post.
> 
> You are right, if the state isn't changed between two method calls, there's no point in calling the invariant two times after the method call and before the next method call.

Yes, the problem creeps in because public methods are not necessarily the only way to alter the state of an object. Running the invariant before the function is run is actually a good catch on Walter's part. I wouldn't have thought of it precisely because it wouldn't be necessary if the only way to alter an object is through it's public methods (and that's often how classe/structs are written).

- Jonathan M Davis

Jonathan M Davis:

> Yes, the problem creeps in because public methods are not necessarily the only way to alter the state of an object. Running the invariant before the function is run is actually a good catch on Walter's part. I wouldn't have thought of it precisely because it wouldn't be necessary if the only way to alter an object is through it's public methods (and that's often how classe/structs are written).

Partially unrelated: if a method is const, it doesn't change instance state, so there's no need to test the invariant after the method call... well unfortunately this is not true, because the invariant tests the static attributes too, that a const method may modify.

Regarding the static state, in another implementation of DbC I have seen the "class static invariant" too, that tests the static class attributes, but I don't understand why it may be useful...

Bye,
bearophile