Subject: Re: [boost] [contract] assertion requirements as meta-functions or not?
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-04-24 10:08:46
Andrzej Krzemienski wrote
> Hi Lorenzo,
> If I understand your question and Boost.Contract design correctly, it
> like the former approach is more flexible in cases where I do _not_ want
> use a meta-function to describe a constraint:
> 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
> 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:
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
auto result = return,
result == (find(begin(), end(), value) != end()), requires O_N <=
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.)
-- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-assertion-requirements-as-meta-functions-or-not-tp4583283p4583610.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk