the code produces following error: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; }
error C2660: 'derived::foo' : function does not take 0 arguments
and it seems very silly to mewhy 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?
Last edited by nadroj; 11-30-2007 at 01:05 AM.
duh!
i had to do this in derived class, and it works now!
and i am not very happy about thisCode:class derived : public base { public: // this solves the problem using base::foo; void foo(const string& msg) { cout << "derived: " << msg << endl; } };
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:inside the definition of 'derived' will make the 'base' class overload visible to 'derived'.Code:using base::foo;
At least that's my understanding. I could be wrong.
Edit: Doh, a fraction too slow.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
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, withBut 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.Code:using base::foo;
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
As shown in my example (well not exactly the samebut 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?
Last edited by manav; 11-30-2007 at 04:09 AM.
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.If the functions are different, why not just cast it to the base object and call the function?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
If you can modify the class(es), then do so. Otherwise, you may have to do a typecast, yes.
