When overloading a templated function, how should the compiler chose which version of the function to call if it has the option to either:
The rules for overload resolution go something like this:
Pick the best viable candidate via:
a. Choose the one with the best conversion sequence (think of this as "doing the least necessary work to convert from the argument types to the parameter types")
b. Choose the non-function template over the function template
c. Choose the most specialized function template
Let's go into these on a case by case basis. For your function calls:
func(1);
After (2), we have one viable candidate, func<int>
. func(Parent )
is not a viable candidate, since Parent
is not constructible from int
, so we're done and call the function template.
func(Parent());
We have two viable candidates: func<Parent>
and func(Parent )
. Both take the exact same arguments so the conversion sequences are identical. So we end up in step 3b: we choose the non-template over the template, and we call func(Parent )
.
func(Child());
We have two viable candidates: func<Child>
and func(Parent )
. In the former case, the argument type is Child
so it's an exact match for what we're passing in (no conversion necessary). In the latter case, the argument type is Parent
so we'd have to perform a derived-to-base conversion. Since the function template has a better conversion sequence (i.e. no conversion necessary), it is considered the best viable overload. You could call func(Parent )
- that is a viable candidate, but it's not the best viable candidate. func<Child>
is a better match.
Is there any way to force the compiler to call
func(Parent)
when passed aChild
?
You could either cast the Child
to a Parent
yourself:
Child c;
func(static_cast<Parent>(c));
Or you could write another overload that takes a Child
, which would be preferred only in the 3rd case (and only viable in the 3rd case):
void func(Child );
Or rewrite your function template so as to not take any class in that hierarchy:
template <typename T,
typename = std::enable_if_t<
!std::is_convertible<T*, Parent*>::value
>>
void func(T );
The latter solution (called SFINAE) would remove func<Child>
from the set of viable candidates, so that the only viable candidate becomes func(Parent )
.
In order to be able to get anything done, the standard invented a list of goodness, and the order in which different things would be tried. There are series of lectures on C9 from STL that go into this in length.
First, the template instantiates a solution for each of the three cases.
The second version picks func(Parent)
because it matches exactly, and wins over the template. The third call takes the templated version over a conversion which is considered "less good".
My only thought on preventing this would be to do some horrible SFINAE that tests for every T that it can't be inherited from Parent
using type traits. Concepts in C++17 might allow for something slightly less convoluted.
See
Stephan T. Lavavej: Core C++, 2 of n - Template Argument Deduction
Stephan T. Lavavej: Core C++, 3 of n - Overload Resolution