g++ 2.95.2 accepts an ambiguous template overload
Martin v. Loewis
Mon Mar 6 01:51:00 GMT 2000
> the code below compiles (and resolves to the second foo<>()) with
> g++ 2.95.2. I'm not sure that this is the correct behavior -
> specifically, I don't see that the second foo<>() is more
> specialized than the first according to the partial ordering rules.
Thanks for your bug report. I recall that you provided similar reports
in the past; however, this time, I cannot follow your logic at all.
> 1) synthesize a unique type, say U, substitute it for the template
> parameter and perform argument deduction against the other template
> for template <T> foo (T):
> substitute foo(U) -> deduce foo<U>(const U&), deduced type is U, no
> conversion required (identity conversion, 220.127.116.11, p3, bulet 1 applies)
> hence foo<T>(T) is at least as pecialized as foo<T>(const T&)
I still have my doubts whether 18.104.22.168 really refers to 22.214.171.124 when
# if, and only if, the deduction succeeds and the deduced parameter
# types are an exact match
Why could this not refer to 126.96.36.199, as well? -- But I trust John
Spicer when he says that was the intent.
Even if this is true: The 'deduced parameter type' is 'const U&', the
argument type is 'U', so a qualification conversion is necessary,
i.e. it is not an exact match. The wording 'exact match' clearly
refers to conversion sequences found in overload resolution;
13.3. does not list conversion in template type arguments as an
application of overload resolution.
> I've discussed this with John Spicer of EDG who's of the opinion
> that the call is unambiguous: he doesn't think that 188.8.131.52, p3
> should be considered in step 1 above.
I agree with him.
> I also talked to HP (aCC 3.14.10 rejects the call as ambiguous) and
> they follow the same line of reasoning as myself.
You can't run through the world and convert every compiler vendor to
your interpretation of C++ :-)
> I believe that the partial ordering rules are underspecified and
> need to be clarified, however, I would appreciate your opinion
> before submitting an issue.
I definitely agree there is an issue here, I always meant to submit
one myself. Also see
I'd suggest that we draft one together - there is no point in having
two issues (IMO).
More information about the Gcc-bugs