Overloading a method in a child class invalidates the parent version of the method

[Sirmont]

Good day all,

I am trying to overload (change the argument list) the method of a parent class within the child class. When I do that, the parent class version of the method stops being "declared". I am very surprised by this and am wondering if it's a compiler bug or within the C++ specs. If it is part of the specs, anyone know why it's like that?

Here's some sample code:

class Parent
{
public:
    void Test() {}
};
 
class Child : public Parent
{
public:
    int Test(int Value) {return(Value);}
};
 
int main(int argn, char *argc[])
{
    Child a;
    a.Test();
]
 

Which gives the error:

Error    1    error C2660: 'Child::Test' : function does not take 0 arguments    e:\nexgen\tests\test\test\main.cpp    45
 

I don't see why this wouldn't be allowed, it's not like they only differed by return type: there's no ambiguity.

Thanks guys!
J-O

[scruggsy]

I am not certain why the overloaded function hides the base class function in cases like this, but it does. I'm sure there is a reason.

If you need to resolve the problem, you can do this:

class Child : public Parent
{
public:
  using Parent::Test;
  int Test(int Value) {return(Value);}
};

[weaknessforcats]

Research the Rule of Dominance.

Wirthin a given scope, the local variable dominates a variable outside that scope.
[code]
int a = 10;
void AFunction()
{
int a = 5;
cout << a; //you see 5
}

The same is true with class methods. Whenever you have a derived class method, that method dominates. The donimation is based on the method name only and not the arguments. Therefore, the derived class hides the base class method.
This is not good because your derrived objects can't use the base class method unless you code:

void Base::AMethod(int x)
{
 
}
void Derived::AMethod(int a, int b))
{
       Base::AMethod(b); //recover base class logic
 
}
 

The problem is in whether the call to Base::AMethod is a pre-condition or a post-condition. That is, do you do it before or after the Derived class logic. Or both places? Now you have ambiguity and that spells poor design.

That means you cannot overload methods between classes. Inside the same class is OK but once you change scope, the dominance rule kicks in.

With an override (same method name and same arguments), you have exactly the same situation. But when you do this, it is presumed the override is done on a virtual method. This will correctly build the VTBL for the derived object. Otherwise, the derived method will still hide the base method and you lose base class functionality in the derived object.

[Sirmont]

Thanks guys.

Weaknessforcats, you answer is quite clear and complete, thank you very much.