Polymorphism

Assuming this is one of those "standard" situations where HourlyWorker inherits from Employee, the first question is if the Employee::print method is virtual? Assuming it is, and both versions have the same prototype (I''m not sure if the inheriting override must also be declared virtual; look it up), then I have no idea why you''re having the problem you are.

(In other words, something''s wrong somewhere).

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

instead of &varName try just varName. I do not think ref. params are the same as pointer *''s, but if they are then you are sending the object at that location, not sending the location. Try it.

Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"

ok, let me clear some things up real quick that I didn''t specify. This is a book example on polymorphism. Apparently, print() is not virtual and the signatures are the same, and it''s trying to show why not making print() virtual in this case proves to be an error. Now that I''ve stated that, I still do not understand what I stated above.

Virtual methods are declared in base classes. They are designed to be inherited and overriden by superclasses. Any method of a class is fully specified by its class name; ie, Employee::print is a totally different function from Person::print, especially if the two classes are not related in any way. (This, btw, is why you can''t assign a method to a generic function pointer). The virtual keyword modifies the vtable in such a way as to redirect a call to the appropriate version based on the object base type.

Hope that made sense.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

ok, I understand virtual functions to a degree. I learned Java before C++, so inheritance and classes aren''t new, they are the first things I learned. Unfortunately, pointers are very new, and I do not understand the above. At the end of that sequence, I am thinking that *ePtr is equal to *hPtr, and therefore *ePtr->print(), should call Hourly::print()

quote:

---

Original post by subnet_rx
...*ePtr is equal to *hPtr

---

Actually, pointers are hardly ever equal to each other; they point at the same thing. In this case, you redirected a pointer to an Employee to point at an HourlyWorker, apparently legal (since HourlyWorker inherits from Employee, right?) However since the print method is not virtual, the pointer, when tying to resolve the method call, encountered Employee::print().

In any case, it has illustrated the point that omitting the virtual keyword is an error that can introduce hard to track down bugs.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

ok, that clears some things up. But why wouldn''t *hPtr call Employee::print()? I mean, I know it should call HourlyWorker::print(), but ePtr is pointing to the same address as hPtr, so the compiler should see them as the same thing.

I think I''m just going to continue reading and see if this clears itself up in another example, b/c right now, I''m thinking about reading the Pointer chapter for 6th time this week. Everytime I think I know what a pointer is doing, the book uses it in some weird way so that I don''t know what it''s doing.

AH, I see what is messing you up... Let me see if I can explain (not sure if I can word this well enough to be any use and still keep it brief)

Basically, you''re thinking of a member function incorrectly. When your code is compiled and linked and you call a non-virtual member function of a given class: the only things that matter for determining the function to be called is the type of the pointer that you''re using to make that call, the name of the function, and the parameters to that function. Those 3 things are the only way that the compiler really knows what function to call.

It has to do with how code and data are seperated and how functions are called. A C/C++ function is really just a matter of:

-pushing variables onto the stack
-jumping execution to the address of the function
-popping variables from the stack

So what function is called is based on the name of that function. When you''re talking about a member function, you''ve really just added a namespace to the function (the class name) and added a hidden parameter (the this pointer). So when you issue the ePtr->print() call at the end of your example, the two things that tell the compiler what function to call are the type of ePtr (Employee*),the name of the function (print).

I''m not sure if this clarified anything, it''s way oversimplified, but I hope it did.

yes perfectly. If I understand you correctly, your saying when I created the variable, it is of that type, no matter what address it points to. This seems logical, and I thank you for the explanation. I now know to go back to variables, and look up more on them. I'd like to know if this applies to all types and how to convert them properly if I need to or even if it's possible. Nevertheless, you got me going in the right direction. thx! exactly what I needed.

Edited by - subnet_rx on December 23, 2001 12:25:55 PM