funcs with same names - in base and derived classes

Code:

---

#include <iostream>
#include <string>
using namespace std;

class base
{
public:
        void foo() { cout << "base" << endl; }
};

class derived : public base
{
public:
        void foo(const string& msg) { cout << "derived: " << msg << endl; }
};

int main()
{
        derived d;
        d.foo();

        return 0;
}

---

the code produces following error:
error C2660: 'derived::foo' : function does not take 0 arguments
and it seems very silly to me :( why just cant the compiler use the base class version?

sorry, its been so long since ive used OOP with C++.
a quick fix is to cast d to base, ie: ((base) d).foo();, but that kind of defeats the purpose of polymorphism.

search around for class design and function overloading until someone can give you a more accurate answer. maybe it has to be something to do with virtual?

duh!
i had to do this in derived class, and it works now!

Code:

---

class derived : public base
{
public:
// this solves the problem
        using base::foo;
        void foo(const string& msg) { cout << "derived: " << msg << endl; }
};

---

and i am not very happy about this :( although it works fine now!

The reason is that you aren't overriding the base class foo function there, you're actually trying to overload it. However the overloads in 'base' aren't being considered in calls to foo for 'derived' objects.
Adding:

Code:

---

using base::foo;

---

inside the definition of 'derived' will make the 'base' class overload visible to 'derived'.
At least that's my understanding. I could be wrong.

Edit: Doh, a fraction too slow.

you are right!
that's what i found after a bit searching.
see previous post.

So, all happy now, right? Not looking for something like virtual functions, are you?

Elysia, virtual functions? Hmmmm ....
Actually the function in base class was virtual earlier.
And I suspected it to be the cause of problem and removed virtual from the definition.

Virtual functions only work as they should if you have two identical functions in two or more classes, each derived from each other, or from a base class.

Yes, this is called "hiding" - if you implement a function with the same name in the derived class, but with different "signature" [different return type or arguments], then the base class function is "hidden" from the derived class. You can, as shown, "unhide" it by explicitly tell the compiler that you want to use this function, with

Code:

---

using base::foo;

---

But it's a bad idea in general - it's better to make it clearer that they are different functions by having different names, particularly if you want to use both.

Or implement both functions in the base-class - maybe with one of the forms using a "pure virtual" setting, if that's what makes more sense.

It really depends on what you are doing.

--
Mats

As shown in my example (well not exactly the same ;) but you got the point I hope).
There was a situation during a project ...
The base class function would take no arguments and would do the same
that a derived class function was also doing (but required arguments, that I did not have) !
The problem was that I only had access to an initialized object that was derived.
And i thought I could access the base function using derived object but ...
As shown in my post it does not work unless you change the derived class source.
Which I had chosen not to do in my project ;)

As nadroj suggested. Would a typecast be clean solution to the problem?

If the functions are different, why not just cast it to the base object and call the function?

Quote:

---

If the functions are different, why not just cast it to the base object and call the function?

---

Using a different name would be better. Having to explicitly cast an object of a derived class to an object of its base class in order to invoke a member function means that the hierarchy does not conform to the Liskov substitution principle.

I agree, but I assume in this example, that the OP cannot change the derived class and thus needs to find another way.

Well, if you can't change the base class, and also not change the derived class, what's going on? It's a badly designed class in the first place if it hides the base's methods.

Edit: Yes, I'm well aware that sometimes you can't change someone elses class, etc.

--
Mats

If you can modify the class(es), then do so. Otherwise, you may have to do a typecast, yes.