Andrzej Krzemienski wrote
Hi Lorenzo, If I understand your question and Boost.Contract design correctly, it looks like the former approach is more flexible in cases where I do _not_ want to use a meta-function to describe a constraint:
postcondition( auto result = return, some_cond1(result), requires x / 2 == 0, some_cond2(result), requires noexcept(x), some_cond3(result), requires sizeof(x) > 2, )
Yes, that is correct but I was wondering if there's any strong reason in favor of using a nullary boolean meta-function instead of sizeof(x) > 2, etc (I couldn't find such a reason myself and that's why I opted for the static boolean value).
Although I am not sure if such constraints would be useful in real life.
Assertions requirements are definitely useful for the basic has_equal_to<T> case (as you and I discussed a while back). Take the vector<T>::push_back example where T is not required to be EqualityComparable by the STL but it is if you program the postconditions and that can be modeled as: postcondition( back() == value, requires has_equal_to<T>::value ... ) Now you use the contracted vector class as usual and the postcondition is checked only when you use such a class on an EqualityComparable type T. Another interesting use of assertion requirements is to model computational complexity. Sometimes the contracts can be more expensive to check than the body itself :( so it is useful to disable specific assertions that might be too expensive (previous N1962 revisions used to do this introducing the notion of "importance ordering" then N1962 gave up on this feature -- assertion requirements are more general than importance ordering and they can be used also in this context). For example: #deifne O_1 0 #deifne O_N 1 ... postcondition( auto result = return, result == (find(begin(), end(), value) != end()), requires O_N <= COMPLEXITY_MAX ) If you compile this code with #define COMPLEXITY_MAX O_N (or greater) than this postcondition will be checked otherwise it will neither be compiled nor checked at run-time. So using assertion requirements you can program the notion "this assertion requires a computational complexity of O(n)" and then enable or disable all assertions with a complexity greater than some maximum set complexity COMPLEXITY_MAX. IMO, this might be useful too. (Of course, all this can be done just as well if assertion requirements are specified using a nullary boolean meta-functions but I saw no reason for that so I'm asking the ML.) Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-assertion-requirements-as-... Sent from the Boost - Dev mailing list archive at Nabble.com.