Boost logo

Boost :

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 <> wrote:

>> Look for example at
>> 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             Clang/LLVM/EDG Compilers  C++  Boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at