[boost] Re: Boost.Assertion

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:
    precondition
    postcondition
    invariant
    assert
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 
API.

   -- Jesse