Virtual function polymorphism dilemma.

Does anyone know if virtual functions implicitly call the base class's implementation of said function at all?

For my homework, I have a base class called Package and a child called TwoDayPackage. Package defines a virtual function called calculateCost() which returns a double value in the expression of weight (in ounces) times the cost per ounce. The child class implementation is supposed to add a flat fee on to that. However, as I'm dealing with virtual polymorphism, I'm wondering if there's an alternative to this:

Code:

---

virtual double calculateCost()
{
return (Package::calculateCost()+flatFee);
}

---

The above is what TwoDayPackage defines. I don't know if this seems the right way to do this though. My assignment is to modify my previous homework assignment by virtual-izing the functions, but despite being virtual, TwoDayPackage seems to disregard Package's implementation if I take out the call to the base function call and just give me the flat fee only, as I've seen in the test program I made to debug it.

So, by your observation, virtual functions do not "implicitly call the base class's implementation of said function at all".

Well, I want it to add the derived class variable "flatFee" to the return value of the base class's implementation, but somehow I feel explicitly calling Package::calculateCost() in the child class calculateCost() seems redundant with virtual functions. The thing is, I don't know any other way to modify it to add on to the base function return value. It just seems an awful lot like redefining the function as opposed to overriding it.

Quote:

---

Originally Posted by Chris87

Well, I want it to add the derived class variable "flatFee" to the return value of the base class's implementation, but somehow I feel explicitly calling Package::calculateCost() in the child class calculateCost() seems redundant with virtual functions. The thing is, I don't know any other way to modify it to add on to the base function return value.

---

In this case calling the base class function is the correct thing to do. If the base class had been designed a little differently by providing a virtual function that did nothing but was called from Package::calculateCost, then you could have written an override for that function instead of return the flat fee and do nothing else.

Quote:

---

Originally Posted by Chris87

It just seems an awful lot like redefining the function as opposed to overriding it.

---

It is an override since it will be called when calculateCost is called on an object of a derived class, through a Package pointer or reference.

Awesome, thanks! I just didn't want the code to look rather... stupid.