[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Re: Refinement combined with nested requirement |
From: Doug Gregor (dgregor_at_[hidden])
Date: 2006-07-07 17:27:21
On Jul 7, 2006, at 1:35 PM, Bonderer Rolf wrote:
> Hi,
>
> I came across another interesting example. The basic idea can be
> expressed with the following simple (and possibly strange) example:
> [snip example]
> 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?!
I think you are right, and ConceptGCC is wrong. I imagine we will run
into this situation quite often with big refinement hierarchies.
B<type>::show and A<type>::show are the same function, because B is a
refinement of A and therefore everything in A is also in B. The bug
here comes from an implementation artifact... I've added the test
case to my bug list, and will take a shot a fixing it early next
week. Thanks again!
Doug