g++ 2.95.2 bug

John H. Spicer jhs@edg.com
Sun Dec 12 06:40:00 GMT 1999

"Martin v. Loewis" wrote:
> > It looks like a g++ bug to me.
> >
> > The analysis done by Martin Loewis is correct as far as it goes, but it
> > fails to take into account partial ordering.  When two candidates are
> > indistinguishable for overload resolution purposes, the partial ordering
> > rules are applied to see if one template should be preferred over another.
> >
> > These template actually are ordered relative to one another because top
> > level references are ignored for puposes of partial ordering comparision.
> > So you end up comparing f(T) with f(T*), and f(T*) is selected as being
> > more specialized than f(T).
> Hi John,
> I was almost convinced by this line of reasoning, and had started
> implementing it, when I tried to justify it in the wording of the C++
> standard.
> Apparently, your claim is that
>  template <class T> int foo (T*);
> is more specialized than
>  template <class T> int foo (T&t);
> According to, we have to synthesize unique types for the
> template parameters of the more-specialized function. Let's synthesize
> a type A1. This gives us a signature of "int foo (T1*)".
> According to, we now have to perform "argument deduction
> against (14.8.2)" the template 'int foo (T&)'. 14.8.2 first tells us
> what to do with explicit template arguments; we have none. Then we
> have to chose a subsection. Is it:
> Deducing template arguments from a function call:
>   No, we don't have a call, and we don't have actual arguments whose
>   types we could use
> Deducing template arguments taking the address of a function
>        template
>   No, we are not attempting to take the address of a function
> Deducing conversion function template arguments
>   No, we are not dealing with conversion functions here
> Deducing template arguments from a type
>   Yes, we have a template, and we have a function type (namely int
>   ()(A1*)). So we compare 'T&' with 'A1*', and deduction fails.
> Therefore, neither of the template functions is more specialized than
> the other.
> Perhaps you are refering to the removal of toplevel of toplevel
> references in As I've explained, that does not apply for
> partial ordering.
> Please note that this is already an issue;
> http://www.informatik.hu-berlin.de/~loewis/corer8.html#23
> Unfortunately, the working group classified most of it a NAD; and has
> not responded to the sub-issue 2.
> If I'm still missing something, please let me know.

The deduction is done as if the function was being called.  This should be
stated more clearly, but is implied by where it says "and the
deduced parameter types are an exact match".  This statement would not
be necessary if the deduction were being done on the basis of a type.

Also, note that the example following paragraph 5 illustrates that "T" and
"T&" are not partially ordered relative to one another, which is the
consequence of top-level references being removed.

This should be stated more clearly in the standard.


More information about the Gcc-bugs mailing list