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. 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 ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com