[cfe-dev] PATCH: C++ Function Overloading (v2)

Argiris Kirtzidis akyrtzi at gmail.com
Thu Oct 16 20:35:55 PDT 2008

Hi Doug,

I recently thought about overload resolution again and I have some 
While I understand the necessity of the OverloadType, is 
OverloadedFunctionDecl really necessary ?

It seems to me that overload resolution is part of semantic analysis 
(the Sema), and OverloadedFunctionDecl is like implementation details of 
Sema "leaking" into the AST.
OverloadedFunctionDecl will primarily be used by Sema, and expressions 
referencing it will get replaced and resolved to one FunctionDecl except 
probably when the expression is part of a template.
In the case that the AST clients get an expression referencing 
OverloadedFunctionDecl, it's unlikely that it will be useful to them, 
without getting it resolved by the same semantic analysis as that of Sema's.

How about if a reference of overloaded function "f", results in a 
OverloadExpr (with OverloadType), that contains the "f" IdentifierInfo 
and a 'void*' opaque value meant to be used by Sema (or in general, the 
Action implementation that created the OverloadExpr) ?
The advantage of this is that Sema has full control and flexibility over 
the overload resolution mechanism, e.g. it can change it completely and 
it will have no impact on the AST or the AST clients.


Doug Gregor wrote:
> Here's a slightly revised version of the function overloading patch.
> It depends on the most recent version of the overloaded function
> declarations patch, here:
>   http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-September/002779.html
> Changes from the previous version:
>   - The various small fixes for C++ support (string literals, bool)
> aren't in here; I've already committed those.
>   - Integral promotion has been fixed, and integral bitfield promotion
> is now implemented
>   - Better tests
>   - Better names for the new functions
> There are still big pieces missing (derived-to-base pointer
> conversions, reference binding, user-defined conversions and
> converting constructors), but the framework is here and it overloads
> C-ish types.
>   - Doug
> ------------------------------------------------------------------------
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list