Boost logo

Boost :

Subject: Re: [boost] [contract] diff n1962
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2010-04-14 16:50:53


Lorenzo Caminiti skrev:
> On Sun, Apr 11, 2010 at 7:49 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>> Agreed: the most constructive way to discuss policies 6) and 7) is for
>> me to present examples. I will work on this.
>
> I checked that the current Boost.Contract implementation follows the
> policies 6) and 7) as originally specified in n1613 (the original
> revision on n1962). I would like to ask for additional clarifications
> on the rational for changing (relaxing) these policies in subsequent
> revisions of the CP C++ standard proposal.

>
> Revision history for 6) "disabling of checks during assertions":
> yes, but not in preconditions -- n1962 ** latest proposal revision **
> no -- n1866, n1773
> yes -- n1669, n1613 ** current Boost.Contract **
>
>>From n1613: <<There is one global rule about assertions and it is that
> assertions must
> be disabled in assertions. This removes the possibility of infinite recursion
> and allows a reasonable performance even with assertions enabled. With-
> out disabling assertions, infinite recursion will happen when a public func-
> tion appears in the invariant.>>
> This is also the policy that Eiffel follows.

First of, the problem is not so big IMO. If your tests runs all
functions, the infinite recursion is easy to detect and fix.

D disables nothing, which we found somewhat silly since it is
merely leading to poorer performance in debug-builds and adds cheks that
are unlikely to recove any real errors (it deals mostly with "second
hand errors").

Preconditions, OTOH, need to be checked to ensure correctness.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk