Boost logo

Boost :

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

on Thu Oct 11 2012, Andrzej Krzemienski <> wrote:

>> >
>> > "pseudo-signatures > usage patterns"
>> Hello all,
>> Can we write down pros and cons for concepts implemented via
>> pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns
>> (N3351 and Boost.Contract)?
> I think such comparison looks different when you want to provide the best
> solution for STL and different when you want to provide the solution for
> *every* generic library. STL is particular in two ways: first, it has been
> in use for years, and any solution needs to fit seamlessly into the
> existing code (even if the code doesn't adhere to the best practices of
> generic programming); second, STL uses operators heavily. I expect no other
> generic library to make such extensive use of operators.

That's a very surprising statement. Many applications of genericity
seem to fall into mathematical domains.

> I have never tried to implement support for any type of concepts, so I am
> only looking at the problem from end user's perspective; arguments like
> "pseudo-signatures make it easier to generate archetypes" do not appeal to
> me that much (which admittedly may be an ignorant approach).
> Informally, I can say that I expect of an iterator a post- and
> pre-increment, comparison, and dereference. With pseudo signatures I
> express it as:
> Iter& operator++(Iter);
> Iter operator++(Iter, int); // note the dummy int
> bool operator==(Iter const&, Iter const&); // bool or convertible to bool?
> ValueType<Iter>& operator*(Iter const&);
> But how do I say "convertible to bool"?

You just said it :-)

> With usage-patterns, I type:
> Iter& == { ++it };
> Iter == { it++ };
> bool = { it == jt }; // convertible
> ValueType<Iter>& == { *it };
> To me, the latter notation appears more appealing: it is shorter, it gives
> me a concise way of specifying "has exactly this type" or "is implicitly
> convertible to" or "is explicitly convertible to".

But you don't want to say those things. When you say "is implicitly
convertible" and you don't have the pseudo-signature loose/tight
mechanism behind it, the obvious, clean way to express your algorithms
doesn't compile, and you need to uglify them by inserting explicit

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