[Fwd: g++ 2.95.2 bug]

[Martin Sebor]

Hi,

I have subsequently found further ambiguities in the results reported by
g++ and edg (as well as several other compilers) when it comes to
function template overloading which make it apparent that this part of
the standard may not be as
clear as it should be. Perhaps an CWG issue is in order?

Martin


The following program produces the results summarized in the table below
when compiled like so:

$ CC                        t.cc  # case 1
$ CC -DCONST=const          t.cc  # case 2
$ CC               -DVAR=ia t.cc  # case 3
$ CC -DCONST=const -DVAR=ia t.cc  # case 4
     

$ cat t.cc

#ifndef CONST
#define CONST
#endif
     
#ifndef VAR
#define VAR "x"
#endif
     
template <class T>
int foo (CONST T*) { return 0; }
     
template <class T>
int foo (CONST T&) { return 1; }
     
int main () {
    int ia [2];
    return foo (VAR);
}
     
     
    +---+-----+-----+---+---+---+---+---+---+---+
    |   |  options  |        compiler           |
    +---+-----+-----+---+---+---+---+---+---+---+
    | # |CONST| VAR | A | C | E | G | I | M | S |
    +---+-----+-----+---+---+---+---+---+---+---+
    | 1 |     | "x" | 0 | + | 0 | - | - | - | - |
    +---+-----+-----+---+---+---+---+---+---+---+
    | 2 |const| "x" | 0 | - | - | - | - | - | - |
    +---+-----+-----+---+---+---+---+---+---+---+
    | 3 |     |  ia | 1 | + | 0 | - | - | - | - |
    +---+-----+-----+---+---+---+---+---+---+---+
    | 4 |const|  ia | 1 | - | - | 1 | - | - | 1 |
    +---+-----+-----+---+---+---+---+---+---+---+
     
    0 - program compiles and returns 0 when run
    1 - program compiles and returns 1 when run
    + - program compiles (return value unknown)
    - - program generates an ambiguity error
    C - Comeau 4.2.42 (Online Evaluation)
    E - edg 2.42
    G - g++ 2.95.2
    M - MSVC 6.3


To : sebor at roguewave dot com, <jhs at edg dot com>
Subject : Re: g++ 2.95.2 bug
>From : "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
Date : Sat, 11 Dec 1999 23:15:03 +0100
CC : gcc-bugs at gcc dot gnu dot org, pedretti at roguewave dot com
References : <3841A688.8468C9F1@roguewave.com> <199911300000.BAA01030@mira.isdn.cs.tu-berlin.de> <384449F1.5B7C5A24@roguewave.com>

> 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 14.5.5.2/3, 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 14.5.5.2/2, 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:

14.8.2.1 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

14.8.2.2 Deducing template arguments taking the address of a function
       template
  No, we are not attempting to take the address of a function

14.8.2.3 Deducing conversion function template arguments
  No, we are not dealing with conversion functions here

14.8.2.4 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 14.8.2.1/2. 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.

TIA,
Martin