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
> > >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
> > from mixins how can the assertion mechanism know what invariant
> > 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
> for the invariants check. Classes intended to not be used in a
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk