Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-11 19:01:34

on Thu Oct 11 2012, Andrew Sutton <asutton.list-AT-gmail.com> wrote:

>> Doesn't compile, but "should"
>>
>>   struct Predicate
>>   {
>>       typedef char argument_type;
>>
>>       bool operator()(char) const;
>>       bool operator()(long) const;
>>   };
>>
>>   std::vector<int> v(10);
>>   std::vector<int>::iterator p = std::find_if(v.begin(), v.end(), Predicate());
>
> I don't think it should compile. Predicate doesn't seem like it can be
> called with an int in any context, so a concept that catches that
> seems to be doing the right thing.

You're missing the point.  I claim the associated "argument type" of
Predicate is char.  The value type of the sequence (int) is convertible
to the associated argument type.  That's all that's required according
to the text.

>> If you take the standard definition of "input iterator" instead of the
>> SGI one, the examples are even more compelling, because the result type
>> of "*p" merely has to be "convertible to T", so it's easy to arrange a
>> Predicate with no overloads that fails to accept the argument because
>> too many implicit conversions are required.
>>
>> For the "shouldn't compile, but does" example I was presuming the
>> standard definition of "input iterator;" just make an input iterator
>> that returns a type X convertible to the value type, and make the
>> predicate's operator() accept X but not the value type.
>
> I can see how those might be problematic. I'll have to tinker with
> some concrete examples to get a better understanding.

You can work around these kinds of issues by forcing the implicit
conversions in algorithms, but the result is that algorithms get ugly.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost