Re: Boost.Assertion

From: williamkempf_at_[hidden]
Date: 2001-04-17 16:21:34

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
> > At 2:01 PM +0000 4/16/01, williamkempf_at_h... wrote:
> > >An assertion mechanism should not intrude into a class design to 
> the
> > >point of requiring a mixin.
> > 
> > That would be nice. However there's a real problem with systems 
> that 
> > make heavy use of mixins. If most of an object's public methods 
are 
> > from mixins how can the assertion mechanism know what invariant 
to 
> > call? I suppose the class that the mixins are mixed into could 
> > override these functions, but that's an ugly burden to place on 
> > clients.
> 
> A "mixin" (a base class, actually) would need to use a virtual 
method 
> for the invariants check.  Classes intended to not be used in a 
class 
> heirarchy should not be forced to use a mixin just to be able to 
> check invariants.  It is possible to satisfy both types of class 
> design, simply by having the check_invariants class constructed by 
an 
> object pointer and a member function pointer and having "mixin" 
> classes supply a virtual member function here.

I've uploaded an updated header and a test file.  The original issues 
have still not been addressed (i.e. configurable asserts, et. al.) 
but a minimal DbC usage is now possible.  I took the easy way out for 
providing simple invariant specifications and many may not like the 
heavy use of macros.  I'd love to see better designs/implementations 
here, but what's posted illustrates how we can get a minimal DbC with 
out impacting class design or limiting usage to only classes (i.e. 
preconditions and postconditions work just as well with stand alone 
functions).  Any changes to the implementation must meet the same 
criteria here.

1.  It must be possible to turn off varying levels of assertions 
resulting in no overhead in execution time or size.

2.  Class heirarchies can not be effected.  In other words we can not 
force a base class on a design or require virtual methods, though 
inheritance has to be addressed (knowing that full inheritance 
concepts of DbC can't be enforced with out language support).

3.  Assertions have to be usable in non-class methods.

Other goals that would be nice, but aren't present in the code posted:

1.  Configurable assertion handling.  When an assertion fails we 
should be able to dictate whether or not an exception is thrown of 
the program terminates, as well as do more elaborate actions such as 
write to an error log or invoke a debugger.

2.  Use of fewer (or possibly no) macros.

3.  Eliminate or reduce likelyhood of ODR violations.

4.  Allow configurability of assertion levels on a class by class or 
even object by object granularity.

I'm not sure that all of these goals can be met, and some will make 
others harder to achieve, I'm just throwing them out to help spark 
thoughts on how to make the library as robust and useful as possible.

Bill Kempf