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

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-01-08 04:36:05

Dan W. wrote:
> Daniel Wallin wrote:
> 
>> 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.

I don't see how that could happen. At least, AFAIK, no compiler I have
ever used will do that.

>>  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.

You should probably try that with a standard conforming compiler.

   invariants<my_class<I, J> >::foo

is a dependent name, and should be:

   typename invariants<my_class<I, J> >::foo

But that's impossible to deduce. So either your solution will work with
class templates only, or non-templates only.

>> 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.

Yeah, I'm not actually using exceptions. I only translate exceptions
into assert so that exceptions that check_invariants() could throw by
mistake (for instance if it needs to allocate memory temporarily)
doesn't propagate. Normally check_invariants() should be implemented
with asserts.

-- 
Daniel Wallin