[cfe-dev] PATCH: C++ Function Overloading (v2)
Argiris Kirtzidis
akyrtzi at gmail.com
Tue Oct 21 15:51:40 PDT 2008
Doug Gregor wrote:
>
>> Then OverloadedFunctionDecl has a different issue, consider this:
>>
>> void f(char); #1
>> void f(int); #2
>>
>> template<class T> void g(T t)
>> {
>> f(t); #3 //dependent
>> }
>>
>> void f(float); #4
>>
>> void h()
>> {
>> g(2.3); #5
>> f(2.3); #6
>> }
>>
>>
>> At #3 there's an OverloadedFunctionDecl for the template to reference. But
>> what about #4 ?
>> If it gets added to the same OverloadedFunctionDecl then #5 will incorrectly
>> pick it up, while we do want #6 to pick it up.
>> Will there be two OverloadedFunctionDecls, one for the template and another
>> for normal lookup in #6 ? That seems to defeat its purpose.
>>
>
> I figured we would have two OverloadedFunctionDecls. I don't think it
> defeats the purpose, because the AST is storing the set of overloaded
> functions that it saw.
>
With "defeats the purpose" I mean that OverloadedFunctionDecl would be
most useful if it was shared ('f' gets overloaded so 'f' gets replaced
and the AST refers to this OverloadedFunctionDecl from now on), but,
instead, each expression gets its own OverloadedFunctionDecl object.
So what is the advantage of using
- CallExpr -> DeclRefExpr -> OverloadedFunctionDecl (unique for this
expression)
instead of
- CallExpr -> OverloadedFunctionExpr
?
The second avoids the ownership issues of the first (plus it's a bit
more compact).
Another related question:
I assume that all FunctionDecls that would be found via ADL in the
template definition context will also be found via ADL in the template
instantiation context, is this correct ?
And consider another way that having OverloadedFunctionDecl complicates
things:
namespace A {
void f(int); #1
}
void f(char); #2
void g() {
using namespace A; #3
f(0);
}
#4
At #3, 'f' becomes an overloaded function (#1 and #2)
At #4, 'f' is not an overloaded function.
If an OverloadedFunctionDecl is created at #3, then it should be
reverted for #4.
Much simpler is to just inquire the IdentifierResolver about the set of
overloaded functions at each context, and avoid any
OverloadedFunctionDecl manipulation.
-Argiris
More information about the cfe-dev
mailing list