Virtual Functions

Fall 2008

Dr. David A. Gaitros

dgaitros@admin.fsu.edu
 Virtual Functions

Most of the time the compiler “binds” a

function call to it’s definition after
which no changes are allowed. This
means that in order to accommodate
all scenarios, you have to write your
software from the start to account for
them.
Changes to requirements required that
you modify the code.
with Virtual functions we can
accommodate changes in a more
convenient fashion.
 Virtual Functions

• Example taken from the Savitch Book:

class Sale
{
public:
Sale();
Sale(double thePrice);
double getPrice() const;
virtual double bill() const;
double savings(const Sale& other) const;
private:
double price;
};
Note the word “virtual” before the
declaration of double bill() const;
This means that at a later date, a
class that inherits the class Sale
can redefine this member function.
 Virtual Functions

• Here is what the original member

implementation looks like:

double Sale::bill() const

{
return price;
}
• Here is what a new class that inherits the
class looks like that redefines the member
function bill.

namespace SavitSale
{
class DiscountSale: public Sale
{
public:
DiscountSale();
double getDiscount()const;
void setDiscount (double d);
double bill() const;
private:
double discount;
};
} // end SavitSale
 Virtual Functions

• A virtual function is indicated by

including the modifier virtual in
the member function declaration.
• If a function is virtual and a new
definition of the function is given
in a derived class, then for any
object of the derived class, that
object will always use the new
definition. Even if it is invoked in
the inherited function. This is
called late binding.
 Virtual Functions

• Virtual function in base class:

– "Automatically" virtual in derived
class
• Derived class declaration (in
interface)
– Not required to have "virtual"
keyword
– But typically included anyway,
for readability
• The “virtual” term tells the
compiler to wait to define it until
it is called.
 Virtual functions

• Clear advantages to virtual functions

as we’ve seen
• One major disadvantage: overhead!
– Uses more storage
– Late binding is "on the fly", so programs
run slower (Much slower)
• So if virtual functions not needed,
should not be used. If you know all of
the functionality, go ahead and
program it.
 Virtual Destructors

• Recall: destructors needed to de-

allocate
dynamically allocated data
• Consider:
Base *pBase = new Derived;
…
delete pBase;
– Would call base class destructor even
though
pointing to Derived class object!
– Making destructor virtual fixes this!
• Good policy for all destructors to be
virtual in production programming
 Inner Workings of Virtual
Functions
• Don’t need to know how to use it!
– Principle of information hiding
• Virtual function table
– Compiler creates it
– Has pointers for each virtual member
function
– Points to location of correct code for that
function
• Objects of such classes also have
pointer
– Points to virtual function table
 Abstract Classes

• Pure virtual functions are defined as

those functions that have no exact
definition at the time of compile.
• Example ( Myers’ Employee)
#ifndef _EMPLOYEE_H
#define _EMPLOYEE_H class Employee
{
public:
virtual void PrintCheck()=0;
protected:
float netPay;
Employee();
Employee(char* n, char* a, char* ssn);
char name[30];
char address[80];
char socSecNumber[12]; };
 Abstract Classes

• Note the “=0” in the PrintCheck

function declaration. This tells
compiler that there will be no
implementation seen at this time.
• Any class with at least one pure
virtual Function is known as an
“Abstract Class”.
• Abstract classes can be used to
build pointers to a class which
you may want to define at a later
time.
• Templates are coming!