Re: [boost] [contract] Contract Programming Library
Hi, two other questions that came to my mind, regarding the library design. (1) Sometimes the assertions execute longer than the function itself. For example: iterator find( iterator begin, iterator end, value v ) precondition { is_sorted( begin, end ); } { return find_sorted( begin, end, v ); } find_sorted has logarithmic complexity, whereas is_sorted has linear one. If I use function find like this: sort( begin, end ); process( find(begin, end, A) ); // call is_sorted process( find(begin, end, B) ); // call is_sorted process( find(begin, end, C) ); // call is_sorted is_sorted is called many a time. Even if I am in debugging mode but use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level? (2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls? Regards, &rzej
Hello Andrzej, Sorry, I realize I did not complete the loop example: void f(std::vector v, const size_t& n) { size_t i = 0; CONTRACT_ASSERT_BLOCK_INVARIANT( i == 0 ); // Block inv. for (CONTRACT_INIT_LOOP_VARIANT; i < v.size(); ++i) { CONTRACT_ASSERT_BLOCK_INVARIANT( i < v.size() ); // Block inv as loop inv. CONTRACT_ASSERT_LOOP_VARIANT( v.size() - i ); // Loop variant. ... } } On Tue, Feb 16, 2010 at 3:01 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level?
Yes, I will consider this in the future. Also, I might want to check inv/pre/post for most of the classes I compile but not for a few templates part of a library that I trust (e.g., Boost). So it would be nice to select different contract checking levels (at least at run-time) based on class name or similar.
(2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls?
Yes, the library policy is to disable assertion checking within assertions and to disable class invariants checking for nested function calls (public or not) (requirements from [Meyer1997], [Ottosen2004], and [Crowl2006]). Different policies could be implemented but this one avoids infinite recursion well in my experience. Regards, Lorenzo
participants (2)
-
Andrzej Krzemienski -
Lorenzo Caminiti