It is recommended to refer Virtual Functions and Runtime Polymorphism as a prerequisite of this. Below is an example program to demonstrate run time polymorphism.
Time taken: 2613 nanoseconds
See this for above result.
When a method is declared virtual, compiler secretly does two things for us:
- Defines a VPtr in first 4 bytes of the class object
- Inserts code in constructor to initialize VPtr to point to the VTable
What are VTable and VPtr?
When a method is declared virtual in a class, compiler creates a virtual table (aka VTable) and stores addresses of virtual methods in that table. A virtual pointer (aka VPtr) is then created and initialized to point to that VTable. A VTable is shared across all the instances of the class, i.e. compiler creates only one instance of VTable to be shared across all the objects of a class. Each instance of the class has its own version of VPtr. If we print the size of a class object containing at least one virtual method, the output will be sizeof(class data) + sizeof(VPtr).
Since address of virtual method is stored in VTable, VPtr can be manipulated to make calls to those virtual methods thereby violating principles of encapsulation. See below example:
CDerived::Foo() called CBase::Foo() called
We are able to access vPtr and able to make calls to virtual methods through it. The memory representation of objects is explained here.
Is it wise to use virtual method?
As it can be seen, through base class pointer, call to derived class method is being dispatched. Everything seems to be working fine. Then what is the problem?
If a virtual routine is called many times (order of hundreds of thousands), it drops the performance of system, reason being each time the routine is called, its address needs to be resolved by looking through VTable using VPtr. Extra indirection (pointer dereference) for each call to a virtual method makes accessing VTable a costly operation and it is better to avoid it as much as we can.
Usage of VPtr and VTable can be avoided altogether through Curiously Recurring Template Pattern (CRTP). CRTP is a design pattern in C++ in which a class X derives from a class template instantiation using X itself as template argument. More generally it is known as F-bound polymorphism.
Time taken: 732 nanoseconds
See this for above result.
Virtual method vs CRTP benchmark
The time taken while using virtual method was 2613 nanoseconds. This (small) performance gain from CRTP is because the use of a VTable dispatch has been circumvented. Please note that the performance depends on a lot of factors like compiler used, operations performed by virtual methods. Performance numbers might differ in different runs, but (small) performance gain is expected from CRTP.
Note: If we print size of class in CRTP, it can bee seen that VPtr no longer reserves 4 bytes of memory.
cout << sizeof(Image
) << endl;
Questions? Keep them coming. We would love to answer.
This article is contributed by Aashish Barnwal. If you like GeeksforGeeks and would like to contribute, you can also write an article and mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above
- Command Pattern
- Observer Pattern | Set 1 (Introduction)
- Observer Pattern | Set 2 (Implementation)
- Singleton Design Pattern | Implementation
- Decorator Pattern | Set 1 (Background)
- The Decorator Pattern | Set 2 (Introduction and Design)
- Decorator Pattern | Set 3 (Coding the Design)
- Strategy Pattern | Set 1 (Introduction)
- Strategy Pattern | Set 2 (Implementation)
- Adapter Pattern
- Iterator Pattern
- Flyweight Design Pattern
- Implementing Iterator pattern of a single Linked List
- Singleton Design Pattern | Introduction
- Java Singleton Design Pattern Practices with Examples