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 16:52:49

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

>> Look for example at
>> http://www.sgi.com/tech/stl/find_if.html.  I can easily satisfy all the
>> stated requirements and produce an example that won't compile.  I can
>> also easily fail to satisfy the stated requirements and produce an
>> example that *will* compile.  That's because there's a great deal of
>> potential mischief hiding in expressions such as
>>
>>   f(*p)
>
> Can you produce those examples? You've made me curious.

Doesn't compile, but "should"

--8<---------------cut here---------------start------------->8---
  #include <algorithm>
  #include <vector>

  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());
--8<---------------cut here---------------end--------------->8---

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.

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