Share this post

Link to post

Share on other sites

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.

0

Share this post

Link to post

Share on other sites

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.