What does that have to do with function overloading?

Question

This is basically a copy from the example given in Item 21. Overriding Virtual Functions in Herb Sutter's book Exceptional C++.

#include <iostream>
#include <complex>
using namespace std;
class Base
{
public:
    virtual void f(int);
    virtual void f(double);
    virtual ~Base() {};
};

void Base::f(int) { cout << "Base::f(int)" << endl; }
void Base::f( double ) { cout << "Base::f(double)" << endl; }

class Derived: public Base {
public:
    void f(complex<double>);
};

void Derived::f(complex<double>) { cout << "Derived::f(complex)" << endl; }

int main()
{
    Base* pb = new Derived;
    pb->f(1.0);
    delete pb;
}

The code prints Base::f(double) and I have no problems with that. But I couldn't understand the explanation given by the author on the top of page 122 (emphasis is mine):

Interestingly, even though the Base* pb is pointing to a Derived object, this calls Base::f( double ), because overload resolution is done on the static type (here Base), not the dynamic type (here Derived).

My understanding is that the call pb->f(1.0) is a virtual call and Base::f(double) is the final overrider for f(double) in Derived. What does that have to do with function overloading?

This title is not very useful. Imagine what you would think if you saw it in search results. — R. Martinho Fernandes, May 19 '14 at 15:02

Jon · Accepted Answer · 2014-05-19T13:39:41.243

The delicate part here is that virtual methods are a mechanism to dispatch the function call, while overloading is a feature that affects the resolution of the call.

That is, for any call the compiler needs to figure out which method should be called (resolve it); afterwards, and in a logically distinct operation, it needs to generate code that calls the correct implementation of that method (dispatch it).

From the definitions of Base and Derived given above we can easily reason that if f(double) is called on a Base* then the call should be dispatched to any derived override (if applicable) in preference to the base implementation. But answering that is answering a question totally different than

When the source says pb->f(1.0), which of the methods named f should be used to resolve the method call?

As Sutter explains, the spec says that when resolving the call the compiler will look at the methods named f declared on the static type pointed to by pb; in this case, the static type is Base* so overloads (not overrides!) declared on Derived will not be considered at all. However, if the method that the call resolves to is virtual then the possible implementation provided on Derived will be used as expected.

And really it has to be that way -- you might not have the source code for the declaration of the actual derived virtual function, and indeed that overriding function might not have been written yet, so (a) you couldn't get its default anyway and (b) even if you could it would probably be deeply surprising for your default to change dynamically at run time to values you could never test against. -- BTW one thing I would improve about the text you quoted from me is that it's more correct to say "name lookup" rather than "overload resolution" but the analysis is correct and the result the same. — Herb Sutter, May 19 '14 at 17:05

dlf · Answer 2 · 2014-05-19T13:45:07.577

The reason this example is interesting is because, if pb were a Derived* instead of a Base*, or if the compiler could somehow use the dynamic type rather than the static type for performing overload resolution, it would match the call to pb->f(1.0) to void Derived::f(complex<double>) (complex<double> can be implicitly constructed from double). This is because the presence of a function named f in a derived class effectively hides any base class overloads with the same name, even if their argument lists are different. But since the static type of pb is actually Base*, this doesn't happen.

score 0 · Answer 3 · answered May 19 '14 at 19:29

In this example, despite the repeated occurrence of virtual, there is no method overriding at all; the method f in the derived class overrides neither of the ones in the base class, because the argument types do not match. Given this circumstance, there is no way the call of pb->f could ever invoke the (unique) method Derived::f. Overload resolution/name lookup (which only considers methods of the static type of pb->f) must choose between the two methods declared as Base::f, and in the example it will choose the one with argument type double. (At runtime this might end up calling an override, if one is defined in a different derived class than Derived, and if the example is modified so that pb could possibly point to an object of such another derived class.)

A separate issue is that the methods named f in Base and Derived would not be simultaneously considered for overload resolution if f is called from an expression of (static) type Derived either, this time because the methods in the base class are hidden by the declaration of f in Derived, so they are not available for such calls. I think this hiding can be avoided by declaring using Base::f;,which "lifts" the methods Base::f into Derived as if they were also declared there (but I admit not knowing the details of this mechanism; I suppose the lifts would then be overrides of the virtual base method with the same argument type, but it makes little difference because the lifts refer to the implementation in the base class anyway.)

What does that have to do with function overloading?

3 Answers3

Linked