Why is it ambiguous to call overloaded ambig(long) and ambig(unsigned long) with an integer literal?

Question

When compiling

void ambig(  signed long) { }
void ambig(unsigned long) { }

int main(void) { ambig(-1); return 0; }

I get

error C2668: 'ambig' : ambiguous call to overloaded function
    could be 'void ambig(unsigned long)'
    or 'void ambig(long)'
while trying to match the argument list '(int)'

I know I can 'fix' it by saying -1L instead of -1, but why/how exactly is this considered ambiguous in the first place?

Nev

Answer 1

You're passing an int to this overloaded function.

Although human intuition says that ambig(signed long) ought to be preferred because your input is a negative integer (which cannot be represented as such by an unsigned long), the two conversions are in fact equivalent in "precedence" in C++.

That is, the conversion int → unsigned long is considered to be just as valid as int → signed long, and neither is preferred to the other.

On the other hand, if your parameter were already a long rather than an int, then there is an exact match to signed long, with no conversion necessary. This avoids the ambiguity.

void ambig(  signed long) { }
void ambig(unsigned long) { }

int main(void) { ambig(static_cast<long>(-1)); return 0; }

"Just one of those things".

---

[C++11: 4.13/1]: ("Integer conversion rank")

Every integer type has an integer conversion rank defined as follows:

• [..]
• The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller size.
• The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.
• The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
• [..]

[ Note: The integer conversion rank is used in the definition of the integral promotions (4.5) and the usual arithmetic conversions (Clause 5). —end note ]

Overload resolution is complex, and is defined in [C++11: 13.3]; I shan't bore you by quoting a majority of it here.

Here's a highlight, though:

[C++11: 13.3.3.1/8]: If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion (13.3.3.1.1).

[C++11: 13.3.3.1/9]: If no sequence of conversions can be found to convert an argument to a parameter type or the conversion is otherwise ill-formed, an implicit conversion sequence cannot be formed.

[C++11: 13.3.3.1/10]: If several different sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence associated with the parameter is defined to be the unique conversion sequence designated the ambiguous conversion sequence. For the purpose of ranking implicit conversion sequences as described in 13.3.3.2, the ambiguous conversion sequence is treated as a user-defined sequence that is indistinguishable from any other user-defined conversion sequence134. If a function that uses the ambiguous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous.

• /10 is the case you're experiencing; /8 is the case you use with a long argument.

Saba

Wait, but int → long is always a lossless conversion. int → unsigned long is lossy half the time. How/why are they the same rank?! – Nev

Just curious: any reason not to use just -1L instead of that cast? – Kwei

@sepp2k: Wow, I see... o__o ("The Daily #$!" comes to mind...) – Nev

@Mehrdad: Third bolded bullet above. As for "why", well, who knows!? – Saba

@Mehrdad: It may be because on typical older, 16-bit systems, int → unsigned long is not lossy (I believe?). Maybe. Does seems a bit daft. – Saba

@LightnessRacesinOrbit: I thought int is signed? – Nev

@Mehrdad: It is, but sizeof(int) ≤ sizeof(long). – Saba

@LightnessRacesinOrbit: Not sure I understand your reasoning. If int is negative, the result loses that information (since it's always positive). The fact that you can cast it back to get the correct value doesn't mean the result itself has the correct value, does it? – Nev

@Mehrdad: No, but it means the information is not lost, either. It's not necessarily a narrowing conversion. Of course, it can be, which is why I think this is a bit daft. And it's unintuitive anyway. – Saba

@Mehrdad: Well if you can cast to and then from and end up at the same result, then obviously the information wasn't lost, or that would not be possible (although it should be noted that the behaviour of the return conversion (unsigned to signed) is technically implementation-defined! [C++11: 4.7/3]). :) – Saba

Answer 2

The constant -1 has the type int. So you're calling ambig with an int as an argument. ambig doesn't have an overload that accepts an int, so we'll have to look at the implicit conversions that we could do. An int can be implicitly converted to a long or an unsigned long (among other things), both of which would be valid arguments to ambig. So the compiler doesn't know which conversion to pick and you need to cast manually (or use a long constant (-1l) instead of an int constant to begin with).

The fact that -1 is a negative number doesn't factor into it because the compiler doesn't look at the arguments value, just its type.

Sovereignty

Answer 3

Because -1 is of type int. And int can be implicitly converted to either signed long or unsigned long.

Moussorgsky