[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Refinement combined with nested requirement |
From: Bonderer Rolf (rolfbo_at_[hidden])
Date: 2006-07-07 13:35:42
Hi,
I came across another interesting example. The basic idea can be expressed with the following simple (and possibly strange) example:
#include<concepts>
#include<iostream>
void show(double t) {std::cout<<t<<std::endl;}
auto concept A<typename type>
{
void show(type t);
};
//Now comes the important part: Refinement and nested requirement simultaneously!
auto concept B<typename type> : A<type>
{
where A<type>;
};
template<B type>
void test(type t)
{
show(t);
}
int main() {
double t=1.;
test(t);
}
//end of program
The program, as presented here, looks a bit stupid of course. But in more complex situations such refinement patterns might be observed. In fact, the compiler considers the function call "show" as ambiguous and yields the following error message:
test.cpp: In function ‘void test(type)’:
test.cpp:31: error: call of overloaded ‘show(type&)’ is ambiguous
test.cpp:8: note: candidates are: void B<type>::show(const type&)
test.cpp:8: note: void A<type>::show(const type&)
test.cpp: In function ‘void test(type) [with type = double]’:
test.cpp:36: instantiated from here
test.cpp:31: error: no matching function for call to ‘show(double&)’
test.cpp:8: note: candidates are: void B<type>::show(const type&)
test.cpp:8: note: void A<type>::show(const type&)
The question is if such situations are just the result of poor programming. On the other hand, in praxis it might be difficult to circumvent such situations. I think that it would be convenient if the compiler would ignore nested requirements (where A<type>) if a concept is derived from that very requirement (...:A<type>). In other words, I think that, in such situations, the compiler should automatically chose the function B<type>::show.
What do you think?!
Kind regards,
Rolf Bonderer