On 8/25/13 5:16 AM, deadalnix wrote:
As they are defined now, invariant are plain useless. I find myself
disabling them one by one in my code as soon as cases get outside simple
trivia.
The problem is that invariant are checked at the beginning/end on public
function calls. As a consequence, it is impossible to use any public
method in an invariant.
But this is what they are for - check the state of an object upon access
through the client-accessible interface. Simple code factorization (use
a private method forwarded to by the public one) takes care of this
situation.
For instance, just right now I did refactor a struct to use bitfields,
in order to make it more compact. Now I have to remove the invariant as
field access are now function calls.
I don't get this case. Code?
Another typical situation is when you want to assert certain properties
in a class hierarchy, where calling virtual method is part of the
invariant check.
invariant should (and must to be useful) be inserted at callee point,
when the callee isn't itself subject to invariant insertion, and around
public memeber manipulation (when the manipulator isn't subject to
invariant insertion).
Any other pattern it doomed to create infinite recursion for non trivial
invariant checks.
There might be something here, but more like a performance problem. I do
see how calls of public methods from an invariant could cause trouble,
but I'd say that's a problem with the invariant design.
Andrei
