on Tue Sep 20 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:
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?
No, almost certainly not. It would probably be reasonable to say that *if* T supports ==, the contract checking will use that, and otherwise, the parts of the contract that depend on == won't be checked. Another reasonable possibility (which could be used together with the former one) would be to provide a hook for people to implement some equivalence test for T that isn't spelled "==". That said, I would argue that if they can implement the equivalence test, they should call it "==". Overall I have more confidence in the first idea above than in the second one.
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.
Good luck. Incidentally, this is part of the reason Stepanov puts so much emphasis on the importance of "regular types:" you can't check (programmatically or by inspection) even the most basic assertions about the correctness of code that copies data unless you have some notion of "==" for just about everything. However, the C++ standard was written to accomodate "partial" types that lack essential operations, so what are you gonna do? -- Dave Abrahams BoostPro Computing http://www.boostpro.com