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.
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk