Re: Boost.Assertion

From: williamkempf_at_[hidden]
Date: 2001-04-18 09:26:17

--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
> >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.

The order is taken from the DbC concept as described in OOSC2 by 
Bertrand Meyer, and it makes sense.  General assertion checks are the 
least likely checks to be needed in production code.  You suggest 
that "classes that don't want or need an invariant will likely use 
assert for preconditions" but this is a violation of DbC.  A 
precondition should always be a precondition.  Attempting to use a 
check (the proper term in DbC speak for a general assertion made 
during processing of a method) in place of a precondition muddies the 
intent and fails to convey the contract.  Checks are for insuring 
proper implementation of a method, they are not formally a part of 
the contract (meaning they don't specify what's expected of the 
caller or what's insured by the callee).

As for the worry about unnecessarily checking the invariants... in 
general you should always check the invariants making this an 
erroneous concern.  In practice there are cases where this will be 
true since we're using a C++ library and not a language feature (for 
example, you wnat to check the invariants only at the end of a c-tor 
and only at the beginning of a d-tor).  However, this is precisely 
why invariants aren't automagically checked by the preconditions 
(well, one of the reasons any way).

> 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.

The Assertion argument comes from borrowing code.  Given the 
definition of the macros you are correct, it's not needed.  The E* 
dummy=0 is needed as a hack work around for a VC++ bug.  With out 
this dummy argument the wrong template instantiation is used (the 
first one found in the translation unit is used for all other 
instances).  This is a common and well known fix for one of the most 
vexing VC++ bugs.

> 3) I don't think it's a good idea to use BOOST_REQUIRE and 
> BOOST_ENSURE inside a ctor or dtor.

According to DbC it is.  What makes you think otherwise?
 
> 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.

I'll look at it later today, hopefully.

Bill Kempf