• Advertisement
Sign in to follow this  

inheritance with several identical functions names (diff. signatures)

This topic is 4281 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Sorry bout the topics name which is unclear. I got the following (C++)
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
    }
}
Is that normal ? Thank you for reading ! Janta

Share this post


Link to post
Share on other sites
Advertisement
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:
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Have you tried using the namespace resolution operator?

Instead of Method1, you would use Child::Method1(param1, param2);

Share this post


Link to post
Share on other sites
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 !

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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);
}
The compiler won't search outside the local scope for further instances of 'foo' once it encounters the int.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement