[boost] Re: "invariants" class; Version 1.00

From: Dan W. (danw_at_[hidden])
Date: 2004-01-08 01:16:20

Daniel Wallin wrote:
> I find this overly complicated. Why do we need first_verify() and
> last_verify() for instance? I don't get it. I also don't think adding

The rationale is (or was, not sure) to have invariants checked after 
initialization, before any function calls so as to catch a bug as early 
as possible. This made more sense with my previous version, where I was 
checking invariants at function exit only. And I must admit that having 
also a last-check, and the enabled_ boolean have more to do with my own 
need to test the invariants class properly function in the case of 
inheritance, than it has to do with its user-perspective purpose. I'll 
get rid of all that or put it between #if INVARS_DEBUG #endif lines.
Thank you.

> members and virtual functions to classes depending on whether or not you
> are compiling with debug information is necessarily a good idea.

Inheritance from invariants< Derived > currently is there whether or not 
compiling for debug; but in release mode the invariants class is empty.
The only virtual function inherited from class invariants is 
check_invariants(), but note that (A) it is pure virtual in the base 
class, and (B) is no longer virtual when implemented in Derived. AFAIK 
this should avoid the compiler's seeing a need to create a virtual 
table, but I've been wrong before.

>  From a quick look I also noticed a problem with your code:
> 
>   # define _INVARIANTS_CHECKED_ invariants< type >::trigobj TRGBJ(this);
>      might be dependent type if in a class template ^^^^^^^

I don't understand:  If my derived class would be  foo< int, bar >, I'd 
end up with  invariants< foo< int, bar > >::trigobj, and I'm not sure 
what the problem is with that. The thired class, "my_class3" in the test 
program is exactly like that, BTW.

> I'm attaching a simplified invariant-guard-thing.

I'm studying it. Thank you. I certainly see the wisdom of not adding 
foot-print to the target class; I'll get rid of that char enabled_ right 
away. And it also makes sense to avoid introducing inheritance.

One comment I have is about using exceptions. I don't want to, for the 
following reasons:

A) The user may have turned off exception handling on the compiler and 
not want to enable it, for some good or bad reason.

B) I want the debugger to stop execution at the line in which the 
violated expression is coded; not in some other place from which I have 
to go back in the stack to see what happened.

Thank you!
dan