How is ambiguity determined in the overload resolution algorithm?

Question

I'm trying to understand the overloading resolution method.

Why is this ambiguous:

void func(double, int, int, double) {}
void func(int, double, double, double) {}

void main()
{
    func(1, 2, 3, 4);
}

but this isn't?

void func(int, int, int, double) {}
void func(int, double, double, double) {}

void main()
{
    func(1, 2, 3, 4);
}

In the first case there are 2 exact parameters matches and 2 conversions against 1 exact match and 3 conversions, and in the second case there are 3 exact matches and 1 conversion against 1 exact matches and 3 conversions.

So why is one ambiguous and one is not? What is the logic here?

Interesting edge case, but purely academic. If I'd see this used in production code someone would get fired. — Blindy, Mar 17 '15 at 03:20
C++ ISO may talk about this.Someone may give us reference later. — Ron Tang, Mar 17 '15 at 03:23
@Blindy Talk to him, yes. In a serious way, yes. But fire him? — glglgl, Mar 17 '15 at 09:53
Drawing the connection with Java: the JLS will not consider 2 conversions and 1 conversion to be a difference. It will only distinguish between *having-to-convert* and *not-having-to-convert*. http://stackoverflow.com/questions/22991150/when-using-overloading-with-type-promotion-why-method-calling-is-ambiguous — Jeroen Vannevel, Mar 17 '15 at 21:35

Pradhan · Accepted Answer · 2015-07-11T18:42:43.230

The overload resolution rules only define a partial order on the set of all matches - if an overload F1 is not a better match than F2, it does not imply that F2 is a better match than F1. The exact partial order can be thought of as comparing two points in k dimensions, where the number of arguments is k. Lets define this partial order on points in k-dim space - (x_1, x_2,..., x_k) < (y_1, y_2,..., y_k) if x_i <= y_i for all i and x_j < y_j for at least one j. This is exactly the partial order on candidate non-template functions defined by the standard.

Lets look at your examples :

void func(double, int,    int,    double) {}
                  vvv     vvv       vvv
                 better  better    equal
void func(int,    double, double, double) {}
          vvv                       vvv
         better                    equal

So neither overload is strictly better than the other.

In your second example:

void func(int,   int,   int,   double) {}
          vvv    vvv    vvv     vvv
         equal  better better  equal
void func(int, double, double, double) {}
          vvv
         equal

Now, the first overload is better than the second in all but one argument AND is never worse than the second. Thus, there is no ambiguity - the partial order does indeed declare the first one better.

(The above description does not consider function templates. You can find more details at cppreference.)

I was almost sure that partial ordering is defined like a lexicographical comparison, so if first argument of `f()` is better than the first argument of `g()` then `f()` is "better" than `g()` (otherwise look at second etc). But is seems that's not the case, good answer! — vsoftco, Apr 11 '15 at 00:14

score 13 · Answer 2 · answered Mar 17 '15 at 03:38

The wording from the standard (§[over.match.best]/1) is:

[...] let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the type of the i-th parameter of viable function F.
[...] a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then
— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2)

In your first case, the two functions fail the first test. For the first argument, the first function (taking double) has a worse conversion sequence than the second. For the second argument, the second function has a worse conversion sequence than the first (again, the int has to be promoted to double in one case, but not the other).

Therefore, neither function passes the first rule, and the call is ambiguous.

Between the second pair of functions, every argument to the the first function has at least as good of a conversion as the matching argument to the second function. We then go on to the second rule, and find that there is at least one argument (two, as a matter of fact) for which the first function has a better conversion (identity instead of promotion) than the second.

Therefore, the first function is a better match, and will be selected.

score 0 · Answer 3 · answered Jun 10 '15 at 04:42

Ambiguity is determined by the ranking:

Exact match: no conversion required, lvalue-to-rvalue conversion, qualification conversion, user-defined conversion of class type to the same class
Promotion: integral promotion, floating-point promotion
Conversion: integral conversion, floating-point conversion, floating-integral conversion, pointer conversion, pointer-to-member conversion, boolean conversion, user-defined conversion of a derived class to its base

Exact match wins vs Promotion which wins vs Conversion.

In the example:

void func(int, bool, float, int){cout << "int,bool,float,int" << endl;}
void func(int, bool, int, int){cout << "int,int,int,int" << endl;}

int main()
{
    func(1,1,3.4,4);
}

Argument 1(1) is an exact match on both
Argument 2(1) is an exact match on both
Argument 3(3.4) can be converted into float and int - Ambiguity Neither is better.
Argument 4(4) is an exact match on both

But if we did this: func(1,1,3.4f,4);
(3.4f) is now an exact match!
void func(int, bool, float, int) then wins the battle.

How is ambiguity determined in the overload resolution algorithm?

3 Answers3

Linked