This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++, this, more_specialized(), and fn_type_unification()
- To: oldham at codesourcery dot com
- Subject: Re: g++, this, more_specialized(), and fn_type_unification()
- From: Jason Merrill <jason at redhat dot com>
- Date: 16 Feb 2001 10:10:33 +0000
- Cc: gcc at gcc dot gnu dot org
- References: <200102160530.VAA21066@oz.codesourcery.com>
>>>>> "Jeffrey" == Jeffrey Oldham <oldham@codesourcery.com> writes:
> When gcc/cp/call.c:joust() calls gcc/cp/pt.c:more_specialized(), the
> last "len" parameter is the result of subtracting the number of
> ?converted arguments? and [function has a "this" member].
> Empirically, it seems that the number of converted arguments does not
> include the "this" parameter so the subtraction does not make sense.
Actually, it does include the 'this' parameter. Thus the machinations at
the top of joust to deal with comparing static and non-static member
functions.
> Also confusing is that the "this" parameter is removed from the
> parameter declarations list by fn_type_unification(), which is called
> only a series of calls
> gcc/cp/pt.c:more_specialized() calls
> gcc/cp/pt.c:get_bindings_real() calls
> gcc/cp/pt.c:fn_type_unification().
> Is this analysis correct? Is modifying the more_specialized()
> invocation to remove the Iverson predicate acceptable?
No.
> Why does removing "this" occur so much later?
Because the list of parms isn't available until later. We are removing
'this' from a list only just extracted from the function decl. Note that
we do the same in get_bindings_real for the target signature.
Would this comment in joust be more useful?
/* Tell the deduction code how many real function arguments we saw,
not counting the implicit 'this' argument.
[temp.func.order]: The presence of unused ellipsis and default
arguments has no effect on the partial ordering of function
templates. */
Jason