[boost] Re: Boost.Assertion

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-18 18:43:11

At 2:26 PM +0000 4/18/01, williamkempf_at_[hidden] wrote:
>--- 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.

With the way your macros are written you're correct.

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

I have some sympathy for this argument, but we're not dealing with 
Eiffel here. The preconditions are not part of the interface and 
using an assert macro instead of a precondition macro isn't going to 
confuse anyone. OTOH I can see a tool like Doxygen making use of 
these macros. I must admit that that would be nice. :-) I think I may 
be coming around...

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

I think I would still switch the order of the check and the 
invariant. In a sense they're rather similar: the invariant checks 
the object state and the check checks the algorithm state. However 
the performance hit of the invariant checks is likely to be larger.

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

It takes time to disengage your mind from macros you've used for 
years. You can ignore that question. :-)

   -- Jesse