[boost] Re: Boost.Assertion

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-17 18:32:21

At 1:57 PM +0000 4/17/01, williamkempf_at_[hidden] 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.

Yep

>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 think you're right. Each mixin needs its own virtual invariant, but 
that's OK.

>  > >There's also the need for an old() method to compare
>>  >values at the start and finish of a method.  If you can solve these
>>  >issues then invariants become even easier.
>>
>>  old() is nice, but it's usually not needed. If it is needed the
>>  client can create an explicit temporary.
>
>Which is wasted memory and computation time when postconditions are
>turned off.  However, old() is easy to handle with a couple more
>macros.
>

If that's true we should probably make it available.

>  > This is pretty much the mixin approach. The only difference is that
>>  the boiler-plate code has been moved from the mixin to the
>>  subclasses. I'm not too comfortable with the additional burden on
>>  clients. I think it's important to make adding these checks as
>>  painless as possible: each little hurdle we place in the way
>provides
>>  an excuse to blow off the checks.
>
>No, this is not a mixin.  The class heirarchy is not effected by the
>use of invariant checking in any way.  Notice that class foo has no
>virtual methods and doesn't inherit from any classes, for instance.

No kidding. I said it was *like* the mixin approach.

   -- Jesse