Dave Abrahams wrote:
on Mon Sep 19 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:
This is a general issue with contracts. In general, an arbitrary complex (const) expression can be used to assert preconditions, postconditions, or invariants. Such a complex assertion might introduce an arbitray set of extra requirements on the types used, requirements that might not be necessary to implement the function body. The extra type requirements introduced by the contracts are especially problematic when programming templates because the used types are generic and it is not know a priori to the function programmer if the generic types will or not satisfy the requirements.
If the contract can't be expressed within the constraints, the constraints are broken, period.
But this means that if you add contracts to vector<T> then you cannot use it unless T is EqualityComparable... I don't think that will be acceptable to Boost.Contract users... will it be acceptable?
Now, however, the standard contains special hand-wavey language that says, essentially, "when we use a == b to describe a postcondition we don't literally mean ==. We mean that a and b are equivalent" (whatever that means). So even if T supports == it doesn't necessarily mean the standard is going to use it. I think what it really means is that b is indistinguishable from any other copy of a.
...which doesn't help you at all in terms of deciding what to actually /do/, I know... hopefully, though, it muddies the water a bit just in case it was too clear for you up till now ;-)
I will study this part of the standard. Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-extra-type-requirements-fo... Sent from the Boost - Dev mailing list archive at Nabble.com.