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) |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.