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
> > precondition
> > 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
>> 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.
>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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk