AMDG On 05/23/2011 02:34 PM, Vicente Botet wrote:
I like how concepts are materialized using a template class that implements the default behavior of the concept and that can be specialized to map type to concepts. I understand that you need a second step to introduce the functions themselves specializing concept_interface.
What I don't understand is the overloading issues. Could you use a concrete example to try to clarify the problems you have addressed?
Okay. Problem 1: Name hiding for member functions. typedef mpl::vector< callable<int(int)>, callable<double(double)>
test_concept;
If we just use the basic definition of concept_interface, the second overload will hide the first since the inheritance structure looks like: struct callable1 { int operator()(int); }; struct callable2 : callable1 { double operator()(double); }; For free functions, I had a problem akin to name hiding when I defined a single namespace scope overload with concept_interface arguments. Using an inline friend function that takes the derived type works with some care to avoid duplicate definitions. You can check the tests for details on what I expect to work. Most of the tests for specific concepts have a test_overload test case. In Christ, Steven Watanabe