From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-17 23:54:50
>I've uploaded an updated header and a test file.
Even more comments:
1) The checks are enabled via an integral number. The current order is:
where precondition is the lowest and assert the highest (ie when
asserts are on everything else is on as well).
I think invariant's should be the highest. They often do more than
you'd really like to do in release. Moreover classes that don't want
or need an invariant will likely use assert for preconditions.
2) I don't see why do_assert() needs the assertion argument. And what
about the "E* dummy=0" argument? All I can figure is that it's there
to allow overloading on the different exception types, but I don't
think the macros or do_assert() is setup properly for that.
3) I don't think it's a good idea to use BOOST_REQUIRE and
BOOST_ENSURE inside a ctor or dtor.
4) I've uploaded another implementation to the vault. Look for a
folder called "DbC". The differences are as follows:
a) It's quite a bit simpler for clients. All they have to do is
declare an invariant method and define it using the normal assert
mechanism (allowing for different responses to the various checks
seems like overkill to me). The PRECONDITION macro calls ASSERT and
creates a stack based class to invoke the invariant. (I'm aware that
the macro names probably won't fly).
b) It won't work with mixins and I don't see how it can be made to work.
c) It's slightly slower since it uses a critical section. I'm
inclined to think this is an acceptable tradeoff for a cleaner client
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk