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
>> >point of requiring a mixin.
>> That would be nice. However there's a real problem with systems
>> 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
>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
>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
> > >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
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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk