class B {
virtual int foo();
};
class D : public B {
virtual int foo() { cout<<"D\n"; }
};
int B::foo()
{
/* how do i tell if this->foo() is overridden by a subclass, or if it will */
/* simply recurse into B::foo()? */
this->foo();
}
main()
{
D d;
d.B::foo();
}

- 423
- 3
- 11
-
3There's probably no reliable way. Why would you want to? – Oliver Charlesworth Dec 29 '10 at 17:14
-
I agree with Oli- just call d.foo() like a normal person. – Puppy Dec 29 '10 at 17:32
-
1I want to supplement my answer with some additional personal points of views. I try my best never to question why someone is wanting to do something. I cannot possibly know why they want to do something, all I know is that they asked a question. I think it's ok to try and solve their issue AND provide an alternative they might not of thought of, but statements like "do it like a normal person" are neither constructive or helpful. – Andrew T Finnell Dec 29 '10 at 17:37
-
@Andrew: I would have written my comment much more snappily, but, well, you gotta make so many characters. Besides, as someone who is on the other end of such comments all the time and is definitely not a normal person, I feel quite confident in knowing when such comments are humourous and when not. – Puppy Dec 29 '10 at 17:39
-
@DeadMG Plain text sometimes is so hard to convey emotion and humorous context, so I apologize. We should hug. :) I think I've just read too many questions lately where people criticize their reasons for doing something. If we are on this website I'd say its far none of us are normal. :) – Andrew T Finnell Dec 29 '10 at 17:46
-
1it's pointless to question why i want to do this. saying "just call d.foo()" is a retarded answer. i could spend an hour explaining why doing this would be helpful in my situation, and that would enable you to cite ways to accomplish what i want in some other way. but i already know how to accomplish what i want by engineering around this limitation of c++. so there is no need to waste everyone's time with a bunch of chatter. – deltamind106 Dec 29 '10 at 18:16
-
It is too late to retract my defense comment based on his use of the word "retarded" :) I guess my main problem is that, I have a hard accepting "it can't be done" seeing as so much CAN be done, and you could write your own RTTI in C++ if need be. The real answer is, it can be done but it will complicate your code to the point that it's better to do something else. – Andrew T Finnell Dec 29 '10 at 18:22
-
I wouldn't agree that this is a limitation of C++. What you're trying to do actually runs counter to just about every plea to reason that exists. All well and good being curious if it can be done, but that it can't should not lead you to conclude that the language is "limited". I actually can't think of one in which such a construct would be possible. – Edward Strange Dec 29 '10 at 18:23
-
lol i don't think c++ is a limited language, bad choice of words on my part. ironic because actually i think c++ is too broad a language. but that is a another debate. – deltamind106 Dec 29 '10 at 18:35
5 Answers
Answer: you can't.
I'd expand if there was anything to expand upon.

- 40,307
- 7
- 73
- 125
One approach is to make foo()
pure virtual function in B
, and also define it. That way you make sure that the derived classes of B
must define foo()
. Here is B,
class B
{
public:
virtual int foo() = 0; //pure virtual function
};
//pure virtual function also has a default implementation!
int B::foo()
{
std::cout << "B" << std::endl;
this->foo(); //this will call the overridden foo() in the derived class!
return 0;
}
If a derived class of B doesn't implement foo(), then you cannot even create instance of such derived class!
See the complete working code at ideone : http://www.ideone.com/m8O2s
By the way, my personal opinion would be, such design of classes is bad to begin with. What if you call B::foo()
from the derive class foo()? Recursive?

- 353,942
- 115
- 666
- 851
-
This makes it so he can't instantiate an instance of B. We don't know if he still wants to create objects of type B. – Andrew T Finnell Dec 29 '10 at 18:04
-
yes of course i realize there are a bunch of ways to engineer around it, but my question is if there is a way built in to the C++ rtti to do what i want. – deltamind106 Dec 29 '10 at 18:09
I hate even providing this.. but here it is
int B::foo()
{
std::cout << "B" << std::endl;
if (typeid (*this) != typeid(B))
this->foo();
return 0;
}
Edit
I want to prove that it works in MSVC++ 2010.
#include "stdafx.h"
#include <iostream>
class B {
public:
virtual int foo();
};
class D : public B {
public:
virtual int foo() {
std::cout<<"D\n"; return 0;
}
};
int B::foo()
{
std::cout << "B" << std::endl;
/* how do i tell if this->foo() is overridden by a subclass, or if it will */
/* simply recurse into B::foo()? */
if (typeid (*this) != typeid(B))
this->foo();
return 0;
}
int main(int argc, _TCHAR* argv[])
{
D d;
d.B::foo();
B b;
b.foo();
return 0;
}
Output
B
D
B
Proof it won't always work
Change D to this and it won't work anymore
class D : public B { };

- 13,417
- 3
- 33
- 49
-
That doesn't work. It's not telling if foo() is overridden, and in fact if it isn't your code will infinitely recurse on any call to foo() on a D object; exactly what the OP wants to avoid. It actually doesn't help you find out anything beyond whether or not the B that foo() is being called on is actually a more specified version or not...that's it. Points would be more meaningful if people didn't just hand them out before checking the validity of the answer. – Edward Strange Dec 29 '10 at 17:42
-
@ Noah Roberts You are correct, if D does not override B::foo it will recurse. This can also be solved by using stack unwinding. Create a variable on the stack that sets a flag in thread local storage once entering B::foo(), if B:foo() is entered again through the same stack, and attempts to create another variable, it can check to see if the flag has been set and then exit. Once the stack unwinds the destruction of the variable can unset the flag. My solution solves the exact problem he gave, which is my fault as I didn't read into other scenarios that could have occurred. – Andrew T Finnell Dec 29 '10 at 17:51
The safest way is by not overriding foo() at all, but allow overriding of an OnFoo() function which is called from the baseclass if you cannot trust your programmers. MFC does a lot of this to ensure some default behaviour (rather than protect against recurision).
Then, also at a static level, anything that implements OnFoo() is easily spotted with a 'Find in files'.
E.g. (not tested for syntax/compilation and not threadsafe)
class B
{
public:
B()
{
m_bInFoo=false;
}
int foo()
{
if( !m_bInFoo )
{
m_bInFoo=true;
int nRet = OnFoo();
m_bInFoo=false;
return nRet;
}
return 0;// probably throw exception
}
protected:
// inherited classes override OnFoo(), and never call OnFoo();
virtual int OnFoo(){ return 0 };
private:
bool m_bInFoo;
}

- 2,279
- 22
- 31
As others have pointed out, there is no reliable way to do this. I urge you to rethink your design...

- 4,839
- 3
- 28
- 51
-
well, yes, it would be nice if i could redesign the previous developer's awkward code, but alas that is not in the cards right now. – deltamind106 Dec 29 '10 at 18:54