What is the need of virtual base classes in c plus plus?

Answer 1

Virtual functions are advantageous in that they allow us to write code in a more generic fashion more easily than would otherwise be possible. More importantly, without virtual functions, polymorphic behaviour would be impossible to achieve.

Consider the following example:

#include<iostream>

struct instrument

{

virtual ~instrument() {}

virtual void play () =0;

};

void foo (instrument& a, instrument& b)

{

a.play();

b.play();

}

struct drum : instrument

{

void play () override { std::cout << "Playing a drum\n"; }

};

struct guitar : instrument

{

void play () override { std::cout << "Playing a guitar\n"; }

};

int main()

{

drum d;

guitar g;

foo(d, g);

}

Output:

Playing a drum

Playing a guitar

There are several things to note about this program. As you know, in C++, all types must be declared before they can be used. However, note that the foo function was defined before the drum and guitar classes were declared and yet it was perfectly able to invoke their specific methods even without a forward declaration. This is made possible because the function knows about the instrument class and that's all it really needs to know about; the instrument class exposes the precise interface required by the foo function.

Note also that the instrument class has a virtual destructor. Unless a class is marked final, a virtual destructor tells us that we may derive a new class from this class. In other words, it tells us that this class can be used as a base class. It is important to note that every class that declares one or more virtual methods MUST also have a virtual destructor. I shall explain why shortly.

The instrument::play() method is a virtual method. The '=0' suffix denotes that the function is pure-virtual. Not all base classes require pure-virtual methods, but in this case we do because the instrument class is a conceptual class rather than a concrete class. That is, it is an abstract object; one we can imagine exists but cannot physically exist in reality. By declaring at least one pure-virtual method, we prevent end-users from constructing objects from the class.

A pure-virtual method may or may not be implemented by its base class, but it must be implemented by its derivatives otherwise they become abstract themselves. By contrast, virtual methods must be implemented in the base class but need not be implemented by the derived classes.

Whenever we declare a method virtual, we guarantee that the most-derived override for that method will always be invoked. Thus when we construct a drum object, its play() method becomes the most-derived override. This is how the foo function was able to invoke drum::play() despite the fact it only knew of the existence of the instrument::play() method. Indeed, the foo function doesn't even know that a refers to a drum any more than b refers to a guitar. All it needs to know is that they are both types of instrument and that is guaranteed by the compiler because both drum and guitar are derived from instrument.

While it is true that every drum is an instrument, it is not true that every instrument is a drum (it could be a guitar). How does the foo function know which of the two overrides to invoke? That's precisely the type of problem virtual functions help to resolve. Every class in a hierarchy has a virtual function table (or v-table) which maps the virtual functions of the base class to the most-derived overrides of those functions. Thus when play() is invoked against an object, the class v-table determines the correct function address according to the actual runtime type of the object.

While the v-table does consume additional memory over and above the size of the class members, the cost is minimal (approximately two words per virtual method). However, sometimes it becomes necessary to "switch on" the runtime type of an object in order to evoke specific behaviour. For instance, suppose our drum object has the following interface:

struct drum : instrument

{

void play () override { std::cout << "Playing a drum\n"; }

void play_rimshot () { std::cout << "Playing a rimshot\n"; }

void play_side_stick () { std::cout << "Playing a sidestick\n"; }

};

The play_rimshot and play_sidestick methods are too specialised to be placed in the instrument class. The instrument class exists to provide a common interface to all instruments but you cannot play a rimshot or sidestick upon a guitar. If these methods were part of the instrument interface then they'd also be part of the guitar interface.

One way to invoke these specific behaviours is to dynamically cast the instrument to a drum. If the cast succeeds, you can definitely invoke these methods. If not, then you cannot. But runtime type information is expensive and is often the result of poor design. It is not that there's anything wrong with having such specialised methods, it is only that accessing them from a generic interface is generally the wrong way to go about invoking them. In this particular case all we really need to do is derive a new class from the drum class to cater for these more specific methods:

struct rimshot : drum

{

void play() override { "Playing a rimshot\n"; }

};

struct sidestick : drum

{

void play() override { "Playing a sidestick\n"; }

};

Even though these classes did not exist when we first wrote our foo function, the function can still cater for them:

rimshot r;

sidestick s;

foo (r, s);

In other words, virtual functions have not only enabled runtime polymorphism without the need for runtime type information, they have also provided some measure of future-proofing our code; we do not need to continually maintain the foo function in order to cater for new behaviours.

Answer 2

A pure vitual function is a function declared in base class that has no definition relative to base class .In that cases compiler requires each derived class either to define the function or to redeclare it as a pure virtual function.The class with pure virtual functions cannot be used to declare any objects any objects of its own.

A pure virtual function is a "do-nothing function"

declaration :

virtual void funtionname()=0;

Answer 3

To ensure the base class cannot be instantiated. Any class with a pure-virtual function becomes abstract; you are expectedto derive new classes from an abstract class and you mustprovide an implementation for the pure-virtual method, either in the derived class itself or in one of its derivatives. A derived class that does not implement a pure-virtual function inherited from its base class becomes abstract itself. Derived classes may also declare their own pure-virtual methods, which also renders them abstract.

Abstract classes merely provide the basis upon which to create fully-implemented classes. The least-derived class is the least-specialised. As classes becomes more derived, they become more specialised. When a specialised class fully implements all the pure-virtual functions below it (either through inheritance or by providing the implementation itself), that class can finally be instantiated as an object.

Note that although the class that declares a pure-virtual function can also provide an implementation for it, the derived class (or one of its derivatives) must override that implementation. Default pure-virtual implementations cannot be inherited by derived classes, but the overrides can call them, just as they can with non-pure virtual functions.

Answer 4

A virtual base class is a class, much like any other, but one that can be shared amongst two or more derivatives.

Consider the following:

class A{};

class B: public A{};

class C: public A{};

class D: public B, public C{};

In the above hierarchy, class D indirectly inherits two instances of A, one form B and the other from C. Not only does this introduce an ambiguity within D (you must explicitly state which instance of A you are referring to), it increases the memory footprint of D because all members of A are effectively duplicated, but will be out of sync with each other. Sometimes this may actually be desirable, but more often than not you will want both instances to be in sync. However, since B and C will typically have no knowledge of each other's existence, any changes made to A through either B or C will not be propagated to the other instance of A. This situation can be resolved by inheriting A virtually, rather than directly, in both B and C. Thus:

class A{};

class B: public virtual A{};

class C: virtual public A{};

class D: public B, public C{};

Note that the virtual keyword can be placed before or after the inheritance access specifier, it makes no difference.

Now D will directly inherit just one instance of A, which is then shared by both B and C. Not only does this reduce the memory footprint accordingly, it eliminates all ambiguity.

Moreover, any class that subsequently inherits from D will itself inherit A directly, and share that one instance with D, B and C.

You will often hear talk of the "dreaded diamond" in relation to virtual base classes. The term comes from the fact that the hierarchy of classes A, B, C and D form the four corners of a kite (a diamond shape) with A at the top corner, and D at the bottom, with B and C on either side. While the diamond formation is fairly accurate in terms of representing the class hierarchy with virtual inheritance enabled, it cannot be described as "dreaded" in any way shape or form. If anything, it is desirable.

The original configuration forms a three-tiered 'V' shape with two A's at the top, followed by B and C in the middle tier and D at the bottom. But even this configuration cannot be described as dreaded. For instance, consider the following complex structure that employs both virtual and non-virtual base classes A:

class A{};

class B1: public virtual A{}

class B2: public virtual A{}

class B3: private A{}

class C: public B1, public B2, public B3{}

Here we have class C which forms both a diamond (with B1, B2 and virtual A) which itself forms one side of a V formation (with B3 and non-virtual A on the other side). While an unusual structure, it is by no means an uncommon structure. B1 and B2 share a common instance of A, while B3 has a completely separate instance of A. Note that B3 also inherits A privately, thus eliminating any ambiguity with respect to C. But ambiguity is not to be dreaded either -- it's simply a matter of being explicit about which instance of A you refer to with respect to C.

Ultimately, virtual base classes simply permit the most-derived class to inherit directly from a lesser-derived class that it would otherwise inherit indirectly. Although they are mainly used in multiple inheritance "diamond" formations to eliminate ambiguous multiple instances, they can also be used in single inheritance hierarchies as well:

class A{};

class B: virtual public A{};

class C: public B{};

Here, C inherits A directly, which is then shared with B. Although this type of inheritance might seem unusual, the implication is that B can also be used in multiple inheritance hierarchies with other classes that also inherit A virtually. Indeed, the only way to eliminate the virtual base class in a single-inheritance hierarchy is to completely duplicate class B without the virtual keyword, which only serves to increase maintenance whenever either version of B is altered. If anything, that would be far more "dreaded" than any misplaced notion of a "dreaded diamond".

Answer 5

Virtual functions are base class functions that are expected to be overridden by derived classes. The base class essentially provides a generic interface to all its derivatives, while the derived classes themselves provide the more specific implementations of those methods. Calling the base class method therefore invokes the derived class method, automatically, without any need to know the specifics of that derivative. This is how polymorphism works, and is one of the fundamental principals of object-oriented programming.

For instance, a base class named shape could have a virtual draw method which can be overridden by derived classes such as circle and square. Thus if you have a collection of derived shapes, it is not necessary to know the exact type of the shapes in the collection in order to invoke their specific draw methods, you simply call the base class method, the only class and method your function needs to know about. Runtime polymorphism takes care of the specifics because virtual calls are routed to the appropriate instance method via the v-table, or virtual table.

To appreciate the benefit, imagine what you would do if virtual functions were not permitted. The only way for the base class to invoke derived class behaviour is if the base class knows all about its derivatives. While that is certainly possible, it also means that every time you develop a new derivative you must update the base class in order to handle it. Aside from the increased maintenance cost this incurs, this would make it impossible for 3rd party developers to derive new classes from your base classes because the base class won't know anything about the specifics of those derivatives.

With virtual functions you don't need to predict what derivatives might exist in the future. The base class only needs to know that a generic interface exists while the derivatives themselves handle the more specific implementation of that interface.