[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