class Parent
{
public:
virtual bool Method1(int, a, int b, int c);
virtual bool Method1(int, a, int b);
}
class Child : public Parent
{
public:
virtual bool Method1(int, a, int b);
void OtherMethod()
{
bool b = Method1(1,2,3); // VC++ Error: fuction does not take 2 argument
}
}
inheritance with several identical functions names (diff. signatures)
Author
Sorry bout the topics name which is unclear.
I got the following (C++)
Yes, it's normal. Name lookup will find a matching name for Method1 in Child, so it will never look in Parent, even though the function found does not have a matching signature. The function with three parameters has been hidden. Use a using statement to unhide it:
Σnigma
class Parent{public: virtual bool Method1(int a, int b, int c); virtual bool Method1(int a, int b);};class Child : public Parent{public: using Parent::Method1; virtual bool Method1(int a, int b); void OtherMethod() { bool b = Method1(1,2,3); // VC++ Error: fuction does not take 2 argument }};Σnigma
Have you tried using the namespace resolution operator?
Instead of Method1, you would use Child::Method1(param1, param2);
Instead of Method1, you would use Child::Method1(param1, param2);
Author
Great, I did not know that I could use "using" for that purpose. I had only managed with prefixing like the other posters suggested.
Thanks !
Thanks !
This is the first time I've heard of this behavior and it seems broken to me. Clearly the OP's sample only intended to over-ride the Method1(int, int) method, and had he not overloaded it would it not be true that both mothods from the parent class been included in the Child class's Virtual Function Table? Which would reference the parent's implimentation?
Perhaps my understanding is murky (its been awhile since I've done much work with virtual functions) but if my assesment is correct, is there some reason that the C++ spec has decided that this is "correct" behavior, or is it simply a shortcoming? Is it something that's scheduled to be fixed?
Perhaps my understanding is murky (its been awhile since I've done much work with virtual functions) but if my assesment is correct, is there some reason that the C++ spec has decided that this is "correct" behavior, or is it simply a shortcoming? Is it something that's scheduled to be fixed?
Quote:Original post by Ravyne
Perhaps my understanding is murky (its been awhile since I've done much work with virtual functions) but if my assesment is correct, is there some reason that the C++ spec has decided that this is "correct" behavior, or is it simply a shortcoming? Is it something that's scheduled to be fixed?
According to Meyers in 'Effective C++ (Third Edition)',
Quote:The rationale behind this behaviour is that it prevents you from accidently inheriting overloads from distant base classes when you create a new derived class in a library or application framework.
It's often a pain, but it's trivial to resolve.
EDIT: And from what I know of C++, it seems consistent with the name lookup rules used throughout the language. For example, this won't compile either:
int foo(int x) { return x; }void bar() { int foo = 0; std::cout << foo(42); }
This happens because the compiler will only look in one scope at a time. Once it finds the identifier it's looking for in any scope it won't look in any more - wether it can use what it's found or not.
Compounding on MumbleFuzz; yes sometimes it seems odd. But notice that if it were the other way around, there would be no way to explicitly stop it from happening. This way around, you have a choice.
Compounding on MumbleFuzz; yes sometimes it seems odd. But notice that if it were the other way around, there would be no way to explicitly stop it from happening. This way around, you have a choice.
Author
Quote:Original post by Deyja
This happens because the compiler will only look in one scope at a time. Once it finds the identifier it's looking for in any scope it won't look in any more - wether it can use what it's found or not.
While I agree with the principle (that you stop searching when you found it), I thought it (the compiler) wouldn't considered it resolved to function. It has resolved it's name, yes, but I thought resolving to a function would take into consideration the whole signature, that is the name AND the type/number of parameters.
Looks like I was wrong :)
Thanks.
Janta
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement