on Thu Oct 11 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> 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 conversions. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost