Hi, the snippet bellow compiles with Visual Studio and doesn't compile with gcc-4.2. After some debating over gcc mailing list, we've nailed it to a possible misinterpretation of the standard, section 13.4, paragraph 1.
template <class T> void foo() {} void foo() {}
template <class F> void bar(F f) {} bar(&foo);
Visual Studio compiles fine, and the overload used is the non template function. But gcc chokes at the "bar" call, saying:
"error: no matching function for call to 'bar(<unresolved overloaded function type>)'"
According to the standard, an overload resolution attempt should be done if and only if it's one of the 7 cases outlined there. One of the cases is when the target of the address expression is a function's argument (case 3).
Visual Studio seems to match the call above to case 3, but GCC doesn't, maybe because the call target is a template function's argument, not a "function's argument". Now... by saying "a parameter of a function (5.2.2)", the case 3 includes both template and non template functions, or just the latter?
> Hi, the snippet bellow compiles with Visual Studio and doesn't compile > with gcc-4.2. After some debating over gcc mailing list, we've nailed > it to a possible misinterpretation of the standard, section 13.4, > paragraph 1.
> Visual Studio compiles fine, and the overload used is the non template > function. But gcc chokes at the "bar" call, saying:
> "error: no matching function for call to 'bar(<unresolved overloaded > function type>)'"
> According to the standard, an overload resolution attempt should be > done if and only if it's one of the 7 cases outlined there. One of the > cases is when the target of the address expression is a function's > argument (case 3).
No, case 3 states that the target must a function parameter type - not a function argument type. And in order for bar() to have a function parameter whose type could be matched - bar() must first be instantiated (or "specialized"). Now, instantiating bar() in this particular case, first requires deducing "&foo"'s type. And since deducing a template type parameter from the address of an overloaded function name does not lead to overload resolution (in other words, it is not one of the seven cases listed in '13.4), the use of "&foo" in this context is ill-formed. So gcc is correct.
Note that explicitly specializing bar() would provide a function parameter type that can be matched with "&foo". For example:
template <class T> void foo() {} void foo() {}
template <class F> void bar(F f) {}
int main() { bar<void(*)()>(&foo); // OK }
Explicitly specializing the function template bar() means that the call to bar() now has a function parameter type to serve as a target for "&foo". So in this case, overload resolution does take place - it succeeds - and the program is well-formed.
> Visual Studio seems to match the call above to case 3, but GCC > doesn't, maybe because the call target is a template function's > argument, not a "function's argument". Now... by saying "a parameter > of a function (5.2.2)", the case 3 includes both template and non > template functions, or just the latter?
Case 3 applies to functions and function template specializations. Case 3 does not apply to template type deduction - and since none of the other six cases do either - the original program is ill-formed.
On 22 jul, 00:49, Greg Herlihy <gre...@pacbell.net> wrote:
> No, case 3 states that the target must a function parameter type - not > a function argument type. And in order for bar() to have a function > parameter whose type could be matched - bar() must first be > instantiated (or "specialized"). Now, instantiating bar() in this > particular case, first requires deducing "&foo"'s type. And since > deducing a template type parameter from the address of an overloaded > function name does not lead to overload resolution (in other words, it > is not one of the seven cases listed in '13.4), the use of "&foo" in > this context is ill-formed. So gcc is correct.
Wouldn't be the case of eliminating from the overload set all template functions with template arguments that cannot be deduced, leaving only normal functions and specialized template functions? I cannot see any bad implications in doing this, and IMO it would work as one would expect. Was it a deliberate decision for not allowing this kind of overload resolution, or it was a situation that the committee didn't think of?
On 7 25 , 6 58 , Rodolfo Lima <rodl...@gmail.com> wrote:
> Wouldn't be the case of eliminating from the overload set all template > functions with template arguments that cannot be deduced, leaving only > normal functions and specialized template functions? I cannot see any > bad implications in doing this, and IMO it would work as one would > expect. Was it a deliberate decision for not allowing this kind of > overload resolution, or it was a situation that the committee didn't > think of?
The point is that the compiler is hard to know what specialization of `bar<>()' should be called. The actions which are described in section 13.4 must be done after template argument deducing.
Although you have explicitly instantiated one by "template void bar(void (*f)());", there are still not any approaches to select it automatcially. When the compiler saw the line "bar(&foo);', it should to determine what specialzation of bar<>() it should be instantiated (and then checks if there is aleready one). It needs to know the type of its function argument (i.e., the type of `f'). If it cannot know about the type of its function argument, the template argument deducing will be failed. At the moment, the compiler cannot find a "matching function" for calling to it. So you got the error message: "no matching function for call to ...".
Hmm... In practice, it's reasonable to search all specializations and ordinary functions and select the ordinary one if there is only one ordinary function. Perhaps it's the approach what MSVC and Comeau C++ Compiler adopted (They can compile your example without any problems). But the C++ standard didn't force them to do it. Maybe we lost some traps the committee has already concerned. I'm also curious about it.
<rodl...@gmail.com> wrote: > On 22 jul, 00:49, Greg Herlihy <gre...@pacbell.net> wrote: >> No, case 3 states that the target must a function parameter type - not >> a function argument type. And in order for bar() to have a function >> parameter whose type could be matched - bar() must first be >> instantiated (or "specialized"). Now, instantiating bar() in this >> particular case, first requires deducing "&foo"'s type. And since >> deducing a template type parameter from the address of an overloaded >> function name does not lead to overload resolution (in other words, it >> is not one of the seven cases listed in '13.4), the use of "&foo" in >> this context is ill-formed. So gcc is correct.
> Wouldn't be the case of eliminating from the overload set all template > functions with template arguments that cannot be deduced, leaving only > normal functions and specialized template functions? I cannot see any > bad implications in doing this, and IMO it would work as one would > expect. Was it a deliberate decision for not allowing this kind of > overload resolution, or it was a situation that the committee didn't > think of?
I think my earlier response failed to consider the possibility that type deduction alone may be enough to resolve "&foo's" type when passed as function pointer argument. And in fact §14.8.2.2 seems to confirm as much. So although I was technically correct that no overload resolution takes place in this situation, I was incorrect in thinking that overload resolution was the only way to match &foo to a function pointer type.
So I now think gcc should accept the original program as valid.
