Jump to content
  • Advertisement
Sign in to follow this  
ms75214

virtual function

This topic is 2351 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

Let's say you have a virtual function in C++. Also you have a derived class that implements it. How do you call the base class version?




Share this post


Link to post
Share on other sites
Advertisement
I believe the instance of the class is passed automatically via "this" pointer. If you stop your program in the debugger, you'll notice each member function carries an extra argument called "this" which is the pointer to the class.

Share this post


Link to post
Share on other sites

[quote name='rip-off' timestamp='1323967958' post='4894208']
Like so: Base::myFunction(/* arguments ... */);


How does the instance of the class get passed?
[/quote]
By putting the object on the left hand side and using the . or -> operator, like you usually would.
[source]
myInstance.Base::myFunction(...);
myPointer->Base::myFunction(...);
[/source]
Although, if you are already inside a member function of the object in question, then you don't need the object on the left hand side, as in rip-off's answer.

Share this post


Link to post
Share on other sites

If at all possible, try to ensure that your design doesn't require this. It muddles the logic, complicates debugging, and can cause some maintenance issues.


Someone had rated this comment down but I rated it back up, because I have had to work with code that relied on this type of invocation and it was indeed a pain.

The design was something like this:
* There is a class that receives events and updates its internal state in response, and you can then query its internal state.
* There are classes derived from this one that contain their own implementation of the virtual function that receives the event, so they have an opportunity to update some more state and then they call the parent's version of the virtual function.
* There are actually chains of classes following this paradigm, when more and more state is required.

The big problem with this scheme is that the class hierarchy might be Base <- Derived1 <- Derived2 <- Derived3 and now I want to have something that makes use of Derived3, but even if I am not interested in the state of Base, Derived1 and Derived2, I still have to pay the cost of having them around (both memory and CPU).

We eventually managed to move away from this paradigm and into a "signals and slots" one where the events are implemented as signals and you register whichever listeners you need. Listeners keep their internal state, and a listener might actually require some other listener to be present because it needs to query its internal state. This design is much better than the old one in many ways, and I suspect that this would be true of other situations where you are tempted to invoke your parent's implementation of a virtual function.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!