Re: Data structures for efficient overload resolution

Steve Horne <stephenhorne100@aol.com>
Tue, 18 Mar 2008 07:23:56 -0700 (PDT)

          From comp.compilers

Related articles
Data structures for efficient overload resolution stephenhorne100@aol.com (Steve Horne) (2008-03-11)
Re: Data structures for efficient overload resolution barry.j.kelly@gmail.com (Barry Kelly) (2008-03-14)
Re: Data structures for efficient overload resolution stephenhorne100@aol.com (Steve Horne) (2008-03-15)
Re: Data structures for efficient overload resolution barry.j.kelly@gmail.com (Barry Kelly) (2008-03-17)
Re: Data structures for efficient overload resolution cdodd@acm.org (Chris Dodd) (2008-03-17)
Re: Data structures for efficient overload resolution stephenhorne100@aol.com (Steve Horne) (2008-03-18)
Re: Data structures for efficient overload resolution stephenhorne100@aol.com (Steve Horne) (2008-03-18)
Re: Data structures for efficient overload resolution gneuner2@comcast.net (George Neuner) (2008-03-18)
Re: Data structures for efficient overload resolution stephenhorne100@aol.com (Steve Horne) (2008-03-22)
| List of all articles for this month |

From: Steve Horne <stephenhorne100@aol.com>
Newsgroups: comp.compilers
Date: Tue, 18 Mar 2008 07:23:56 -0700 (PDT)
Organization: Compilers Central
References: 08-03-049 08-03-057 08-03-063 08-03-069
Keywords: types
Posted-Date: 18 Mar 2008 23:35:09 EDT

On Mar 18, 12:07 am, Chris Dodd <cd...@acm.org> wrote:


> The usual way to do this is to compare each function against the list
> of best matches for each argument irrespective of which function they
> came from. That way you get O(nm) complexity in the number of
> candidates and number of arguments. So after looking at #2, you'll
> have (c, c) as your best match argument types and no function that
> matches it. #3 will then match.


Interesting. If I'm reading correctly, you're basically saying that
for the candidate to be an unambiguous best match, all parameters must
have the best match types. Otherwise, the candidate is either one of
several ambiguous matches or incompatible.


Based on this, the resolution process wouldn't know the difference
between an unmatched call and an ambiguous call, and it wouldn't be
able to list the valid candidates for ambiguous cases, but it would
handle correct cases correctly and detect all errors. When an error is
found, error reports can be based on an alternative resolution process
- keeping the main resolution process efficient.


I like it.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.