concept MyFooConcept<typename T>
{
void T::foo();
}
template<MyFooConcept T>
void foo(T t)
{
t.foo();
}
class MyClass
{
public:
void differentFoo()
{
cout << "differentFoo" << endl;
}
};
concept_map MyFooConcept<MyClass>
{
void MyClass::foo()
{
this->differentFoo();
}
}
int main()
{
MyClass m;
foo(m);
return 0;
}
- Krishna
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
ConceptGCC is doing the right thing. It is not possible to adapt
member functions using concept maps. Only free (non-member) functions
can be adapted.
The reason is primarily syntactic. The way one writes a member
function requirement in a concept is the same way that one writes a
definition of a member function outside of the class. For example,
here's a concept that requires a member function swap:
concept MemSwappable<typename T> {
void T::swap(T&);
}
Now, let's try to make int, which clearly doesn't have a member
function swap, MemSwappable:
concept_map MemSwappable<int> {
void int::swap(int&); // ill-formed
}
The problem, in this case, is that there isn't a way for the
compiler's parser to deal with int::swap today: it would be a new idea
to use member syntax on built-in types. When the types get more
complex, things become very complicated:
concept_map MemSwappable<int const *> {
void int const * ::swap(int const *&); // ill-formed
}
While it might be possible to work around the parsing issues using
typedefs, the end result is rather messy, requiring users to write
many extraneous typedefs just to make their concept maps parseable.
- Doug