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

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-01-07 18:24:04

> On Behalf Of Daniel Wallin
> Sent: Thursday, 8 January 2004 9:55 AM
> To: Boost mailing list
> Subject: Re: [boost] Re: "invariants" class; Version 1.00
> 
> Dan W. wrote:
> > Major clean-up. Interest? Bug reports? Thoughts? Criticism?
> >
> > All welcome.
> 
> 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
> members and virtual functions to classes depending on whether or not
you
> are compiling with debug information is necessarily a good idea.
> 
>  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'm attaching a simplified invariant-guard-thing.

Nice and readable but perhaps too simple.

People have differing needs for checking with invariants, pre conditions
and post conditions, sometimes concurrently with themselves ;-)

Checks have overhead.  To build a full specification for something you
often need existential and quantification operators which may be
expensive.

Also the use case for a class, called once or a billion times, affects
the perception of overhead.

This means that you would want to conditionally compile a solution with
different levels of checking, such as:  really expensive and
comprehensive full specification, quite a bit of checking but runs ok in
debug, small checks that are ok for calling a billion times.  

Also you might wish to have the same class with different requirements
in the same run time.  I do.  Such a case is where you might have a
final release build with a public interface that you want checked for
reliability and also internal use of the same interface where you can
rely on the interface contract with no checking.  You might with to use
two different checking interfaces for different performance requirements
as well I guess.

Another need is to support the hierarchical chaining of conditions to
support stronger and weaker conditions to model appropriate polymorphic
substitutability.

Threaded programming throws another spanner into the works.  In this
case, the more invariant checking the better as some other thread maybe
interfering.

I've never had a good solution for this.  I just hack stuff in with
macros...  Would be nice with boost could meet such requirements and it
would fit nicely with BCCL and the like.

Even with program proofs you still have a reasonable chance of making an
error in both the proof and the program :-(

Regards,

Matt Hurd
_______________________

Susquehanna Pacific P/L
hurdm_at_[hidden]
+61.2.8226.5029
_______________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.