In following case, virtual is used to solve the diamond problem to have sub-object of class A shared with B and C.
For example:
class A { };
class B : virtual public A { };
class C : virtual public A { };
class D : public B, public C { };
Does this type of inheritance will be resolved at compile-time or run-time? I mean, how different is the meaning of virtual when used on functions and classes? Is there a concept of dynamic binding when virtual is used to inherit from base class?
Inheritance doesn't have to be "resolved", as you put it, so the question isn't very clear.
The important difference is between ordinary inheritance and virtual inheritance. If you inherit ordinarily, i.e. B : A, C : A, then the class D : B, C has two subclasses of type A, namely D::B::A and D::C::A. On the other hand, if B and C inherit virtually from A, then the ultimate subclass composition will be deferred until you define the final type. That is, B : virtual A and C : virtual A themselves each have a virtual subclass A which would become real if you were to instantiate either B or C. On the other hand, if you derive from the classes further, then the most derived class will contain only one subclass of type A.
Perhaps you may like to consider the analogy with member functions. If each derived class adds a member function of the same name as a base function, you end up with several distinct functions. On the other hand, if the base function is virtual, then you only ever have one function, which is defined in the most derived class. You still have some sort of function in each intermediate class (assuming the function isn't pure-virtual), but only the final class defines the "active" definition.
Virtual inheritance has an effect on constructors, namely that the virtual-base constructor (i.e. A() in the example) is called directly by the most derived class, i.e. D, and not by B or C. If you will, this is because only D "knows" that it contains only one A-subclass, so it is directly "responsible" for it. B and C just hold a virtual placeholder that gives way to the ultimate, most derived class.
Accessing a member function through any base pointer/reference behaves just as expected and is resolved in the usual fashion (i.e. dynamically, in general), but that has nothing to do with virtual inheritance. The actual function lookup may be a bit more complicated as it may involve an extra level of indirection, but that doesn't change anything fundamental.
Virtual inheritance is resolved at runtime.
Virtual inheritance, just like virtual functions, means that each instance of the class has access to runtime data that describes where the virtual thing can be found.
It's described failry well at How C++ virtual inheritance is implemented in compilers?
Does this type of inheritance will be resolved at compile-time or run-time?
Inheritance defines the shape (memory footprint) of the types and it is resolved always at compile time. On the other hand, access to the members of the base type will be resolved at runtime, the reason being that intermediate types in the hierarchy cannot know where the base subobject will be laid in memory in the most derived type.
I mean, how different is the meaning of virtual when used on functions and classes?
Types and functions are different at all levels, so there is not much to say here. The only common thing is that there is a part of the work that cannot be fully resolved at compile time. In particular, the similarity is that code that uses a virtual function depends on a vptr (virtual table pointer) to find the proper vtable (virtual table) for the most derived type, and in a similar way, access to the base object requires the use of a pointer stored in each subobject of a type that derives virtually from the base.
You can read more (about a particular implementation, all this is not part of the standard) in the Itanium C++ ABI, and in particular in the Non-POD Class Types.
As a brief summary, whenever a type D inherits virtually from a type B, the D subobject will contain a hidden pointer to the B subobject. The need for that pointer arises from the fact that the relative position of the B subobject with respect to D can change with further inheritance.
It is my understanding that virtual classes resolves compile time ambiguity. For example assume that both B and C have a getSize method.
Without virtual, a call to D.getSize attempts to use the base class getSize method. Since both B and C each have a getSize method, the compiler is unable to properly resolve the ambiguity and the code will not compile.
With virtual, a call to D.getSize uses the decedent getSize method allowing the code to compile correctly.
Related
Is there a good reason why a virtual function is virtual by default in a derived class and it is not even possible to remove virtuality completely in the derived function?
The reason why I want this behaviour is the same reason I do not want every function to be virtual by default. The compiler might generate vtables which costs performance.
There should be a vtable for the base class (I want polymorphism there), but no vtable for the derived class (I do not want polymorphism there, why should I want that, only because it derives of a class with polymorphism?).
The problem I want to solve is to better understand virtual functions. I just do not get this design decision and wonder if there is any reason for this.
A vtable for a particular class has pointers to the virtual functions for that particular class. A vtable for a base class does not point to the virtual functions overridden by a derived class. There could be many derived classes, and the base class knows about precisely zero of them, so there's no way to have pointers to those functions. Only a derived class's vtable may have pointers to the derived class's functions.
The point of a virtual function is that, if you convert an object of the derived class to a base class pointer/reference, then calling any virtual function declared in the base class must call the most derived class's version of that function for that object. The only way to do that is if the vtable for that object has a pointer to the most-derived-class's version of that function. And that can only happen if the vtable for that object is the derived class's vtable.
That's how vtable's work.
If the derived class doesn't have a vtable of its own, which points to its own overridden member functions rather than the base class functions, then virtual dispatch can't work.
I do not want polymorphism there, why should I want that, only because it derives of a class with polymorphism?
But you do want polymorphism. You asked for it. If you inherit from a polymorphic base class and override one of its virtual functions, you are declaring the intent to use polymorphism. If you didn't want polymorphism, you wouldn't inherit from a polymorphic base class.
I think you are confused about what a vtable does. A vtable for a class C deriving from B basically maps functions specifiers to function pointers for class C. So if you do
B* ptr = new C;
ptr->foo();
we have to look up at runtime, which function to call. In the end, we need a function pointer to C::foo since B cannot possibly know where that lies, since it does not know about C at all. Hence, here we need C's vtable to make the call. Now you could argue that we do not need Bs vtable here. But ptr could also to an Object of type B, so there you need the B vtable.
Arguably, one could do something like this (of course, pseudo code):
virtual_call_to_foo(B* ptr) {
if(ptr->is_actually_base_class) {
ptr->B::foo(); // non-virtual call
} else {
ptr->vtable["foo"](); // indirect call
}
}
But that wouldn't be better than just also using a vtable for B since you already have the indirection there.
Further, note that a call through a pointer to C won't be virtual if C::foo is final:
B* ptr = new C;
ptr->foo(); // virtual call
static_cast<C*>(ptr)->foo(); // non-virtual call, the compiler can inline this
When a method is declared, the declaring class decides if it is virtual, according to the nature of what the method does.
When you override such a method, your overriding method is a specialized version of doing the exact same thing. Your overriding method cannot decide that it is doing something that cannot be specialized, the base class has already made that decision. The nature of the method is decided by the class that originally declared it, the base class.
Vtables are an implementation detail that should not affect any of this.
I'm curious if marking an existing derived C++ class as final to allow for de-virtualisation optimisations will change ABI when using C++11. My expectation is that it should have no effect as I see this as primarily a hint to the compiler about how it can optimise virtual functions and as such I can't see any way it would change the size of the struct or the vtable, but perhaps I'm missing something?
I'm aware this changes API here so that code that further derives from this derived class will no longer work, but I'm only concerned about ABI in this particular case.
Final on a function declaration X::f() implies that the declaration cannot be overridden, so all calls that name that declaration can be bound early (not those calls that name a declaration in a base class): if a virtual function is final in the ABI, the produced vtables can be incompatible with the one produced almost same class without final: calls to virtual functions that name declarations marked final can be assumed to be direct: trying to use a vtable entry (that should exist in the final-less ABI) is illegal.
The compiler could use the final guarantee to cut on the size of vtables (that can sometime grow a lot) by not adding a new entry that would be usually be added and that must be according to the ABI for non final declaration.
Entries are added for a declaration overriding a function not a (inherently, always) primary base or for a non trivially covariant return type (a return type covariant on a non primary base).
Inherently primary base class: the simplest case of polymorphic inheritance
The simple case of polymorphic inheritance, a derived class inheriting non virtually from a single polymorphic base class, is the typical case of an always primary base: the polymorphic base subobject is at the beginning, the address of derived object is the same as the address of the base subobject, virtual calls can be made directly with a pointer to either, everything is simple.
These properties are true whether the derived class is a complete object (one that isn't a subobject), a most derived object, or a base class. (They are class invariants guaranteed at the ABI level for pointers of unknown origin.)
Considering the case where the return type isn't covariant; or:
Trivial covariance
An example: the case where it's covariant with the same type as *this; as in:
struct B { virtual B *f(); };
struct D : B { virtual D *f(); }; // trivial covariance
Here B is inherently, invariably the primary in D: in all D (sub)objects ever created, a B resides at the same address: the D* to B* conversion is trivial so the covariance is also trivial: it's a static typing issue.
Whenever this is the case (trivial up-cast), covariance disappears at the code generation level.
Conclusion
In these cases the type of the declaration of the overriding function is trivially different from the type of the base:
all parameters are almost the same (with only a trivial difference on the type of this)
the return type is almost the same (with only a possible difference on the type of a returned pointer(*) type)
(*) since returning a reference is exactly the same as returning a pointer at the ABI level, references aren't discussed specifically
So no vtable entry is added for the derived declaration.
(So making the class final wouldn't be vtable simplification.)
Never primary base
Obviously a class can only have one subobject, containing a specific scalar data member (like the vptr (*)), at offset 0. Other base classes with scalar data members will be at a non trivial offset, requiring non trivial derived to base conversions of pointers. So multiple interesting(**) inheritance will create non primary bases.
(*) The vptr isn't a normal data member at the user level; but in the generated code, it's pretty much a normal scalar data member known to the compiler.
(**) The layout of non polymorphic bases isn't interesting here: for the purpose of vtable ABI, a non polymorphic base is treated like a member subobject, as it doesn't affect the vtables in any way.
The conceptually simplest interesting example of a non primary, and non trivial pointer conversion is:
struct B1 { virtual void f(); };
struct B2 { virtual void f(); };
struct D : B1, B2 { };
Each base has its own vptr scalar member, and these vptr have different purposes:
B1::vptr points to a B1_vtable structure
B2::vptr points to a B2_vtable structure
and these have identical layout (because the class definitions are superposable, the ABI must generate superposable layouts); and they are strictly incompatible because
The vtables have distinct entries:
B1_vtable.f_ptr points to the final overrider for B1::f()
B2_vtable.f_ptr points to the final overrider for B2::f()
B1_vtable.f_ptr must be at the same offset as B2_vtable.f_ptr (from their respective vptr data members in B1 and B2)
The final overriders of B1::f() and B2::f() aren't inherently (always, invariably) equivalent(*): they can have distinct final overriders that do different things.(***)
(*) Two callable runtime functions(**) are equivalent if they have same observable behavior at the ABI level. (Equivalent callable functions may not have the same declaration or C++ types.)
(**) A callable runtime function is any entry point: any address that can be called/jumped at; it can be a normal function code, a thunk/trampoline, a particular entry in a multiple entry function. Callable runtime functions often have no possible C++ declarations, like "final overrider called with a base class pointer".
(***) That they sometimes have the same final overrider in a further derived class:
struct DD : D { void f(); }
isn't useful for the purpose of defining the ABI of D.
So we see that D provably needs a non primary polymorphic base; by convention it will be D2; the first nominated polymorphic base (B1) gets to be primary.
So B2 must be at non trivial offset, and D to B2 conversion is non trivial: it requires generated code.
So the parameters of a member function of D cannot be equivalent with the parameters of a member function of B2, as the implicit this isn't trivially convertible; so:
D must have two different vtables: a vtable corresponding with B1_vtable and one with B2_vtable (they are in practice put together in one big vtable for D but conceptually they are two distinct structures).
the vtable entry of a virtual member of B2::g that is overridden in D needs two entries, one in the D_B2_vtable (which is just a B2_vtable layout with different values) and one in the D_B1_vtable which is an enhanced B1_vtable: a B1_vtable plus entries for new runtime features of D.
Because the D_B1_vtable is built from a B1_vtable, a pointer to D_B1_vtable is trivially a pointer to a B1_vtable, and the vptr value is the same.
Note that in theory is would be possible to omit the entry for D::g() in D_B1_vtable if the burden of making all virtual calls of D::g() via the B2 base, which as far as no non trivial covariance is used(#), is also a possibility.
(#) or if non trivial covariance occurs, "virtual covariance" (covariance in a derived to base relation involving virtual inheritance) isn't used
Not inherently primary base
Regular (non virtual) inheritance is simple like membership:
a non virtual base subobject is a direct base of exactly one object (which implies that there always exactly one final overrider of any virtual function when virtual inheritance isn't used);
the placement of a non virtual base is fixed;
base subobject that don't have virtual base subobjects, just like data member, are constructed exactly like complete objects (they have exactly one runtime constructor function code for every defined C++ constructor).
A more subtle case of inheritance is virtual inheritance: a virtual base subobject can be the direct base of many base class subobjects. That implies that the layout of virtual bases is only determined at the most derived class level: the offset of a virtual base in a most derived object is well known and a compile time constant; in a arbitrary derived class object (that may or may not be a most derived object) it is a value computed at runtime.
That offset can never be known because C++ supports both unifying and duplicating inheritance:
virtual inheritance is unifying: all virtual bases of a given type in a most derived object are one and the same subobject;
non virtual inheritance is duplicating: all indirect non virtual bases are semantically distinct, as their virtual members don't need to have common final overriders (contrast with Java where this is impossible (AFAIK)):
struct B { virtual void f(); };
struct D1 : B { virtual void f(); }; // final overrider
struct D2 : B { virtual void f(); }; // final overrider
struct DD : D1, D2 { };
Here DD has two distinct final overriders of B::f():
DD::D1::f() is final overrider for DD::D1::B::f()
DD::D2::f() is final overrider for DD::D2::B::f()
in two distinct vtable entries.
Duplicating inheritance, where you indirectly derive multiple times from a given class, implies multiple vptrs, vtables and possibly distinct vtable ultimate code (the ultimate aim of using a vtable entry: the high level semantic of calling a virtual function - not the entry point).
Not only C++ supports both, but the fact combinations are allowed: duplicating inheritance of a class that uses unifying inheritance:
struct VB { virtual void f(); };
struct D : virtual VB { virtual void g(); int dummy; };
struct DD1 : D { void g(); };
struct DD2 : D { void g(); };
struct DDD : DD1, DD2 { };
There is only one DDD::VB but there are two observably distinct D subobjects in DDD with different final overriders for D::g(). Whether or not a C++-like language (that supports virtual and non virtual inheritance semantic) guarantees that distinct subobjects have different addresses, the address of DDD::DD1::D cannot be at the same as the address of DDD::DD2::D.
So the offset of a VB in a D cannot be fixed (in any language that supports unification and duplication of bases).
In that particular example a real VB object (the object at runtime) has no concrete data member except the vptr, and the vptr is a special scalar member as it is a type "invariant" (not const) shared member: it is fixed on the constructor (invariant after complete construction) and its semantic is shared between bases and derived classes. Because VB has no scalar member that isn't type invariant, that in a DDD the VB subobject can be an overlay over DDD::DD1::D, as long as the vtable of D is a match for the vtable of VB.
This however cannot be the case for virtual bases that have non invariant scalar members, that is regular data members with an identity, that is members occupying a distinct range of bytes: these "real" data members cannot be overlayed on anything else. So a virtual base subobject with data members (members with with an address guaranteed to be distinct by C++ or any other the distinct C++-like language you are implementing) must be put at a distinct location: virtual bases with data members normally(##) have inherently non trivial offsets.
(##) with potentially a very narrow special case with a derived class with no data member with a virtual base with some data members
So we see that "almost empty" classes (classes with no data member but with a vptr) are special cases when used as virtual base classes: these virtual base are candidate for overlaying on derived classes, they are potential primaries but not inherent primaries:
the offset at which they reside will only be determined in the most derived class;
the offset might or might not be zero;
a nul offset implies overlaying of the base, so the vtable of each directly derived class must be a match for the vtable of the base;
a non nul offset implies non trivial conversions, so the entries in the vtables must treat conversion of the pointers to the virtual base as needing a runtime conversion (except when overlaid obviously as it wouldn't be necessary not possible).
This means that when overriding a virtual function in a virtual base, an adjustment is always assumed to be potentially needed, but in some cases no adjustment will be needed.
A morally virtual base is a base class relationship that involves a virtual inheritance (possibly plus non virtual inheritance). Performing a derived to base conversion, specifically converting a pointer d to derived D, to base B, a conversion to...
...a non-morally virtual base is inherently reversible in every case:
there is a one to one relation between the identity of a subobject B of a D and a D (which might be a subobject itself);
the reverse operation can be performed with a static_cast<D*>: static_cast<D*>((B*)d) is d;
(in any C++ like language with complete support for unifying and duplicating inheritance) ...a morally virtual base is inherently non reversible in the general case (although it's reversible in common case with simple hierarchies). Note that:
static_cast<D*>((B*)d) is ill formed;
dynamic_cast<D*>((B*)d) will work for the simple cases.
So let's called virtual covariance the case where the covariance of the return type is based on morally virtual base. When overriding with virtual covariance, the calling convention cannot assume the base will be at a known offset. So a new vtable entry is inherently needed for virtual covariance, whether or not the overridden declaration is in an inherent primary:
struct VB { virtual void f(); }; // almost empty
struct D : virtual VB { }; // VB is potential primary
struct Ba { virtual VB * g(); };
struct Da : Ba { // non virtual base, so Ba is inherent primary
D * g(); // virtually covariant: D->VB is morally virtual
};
Here VB may be at offset zero in D and no adjustment may be needed (for example for a complete object of type D), but it isn't always the case in a D subobject: when dealing with pointers to D, one cannot know whether that is the case.
When Da::g() overrides Ba::g() with virtual covariance, the general case must be assumed so a new vtable entry is strictly needed for Da::g() as there is no possible down pointer conversion from VB to D that reverses the D to VB pointer conversion in the general case.
Ba is an inherent primary in Da so the semantics of Ba::vptr are shared/enhanced:
there are additional guarantees/invariants on that scalar member, and the vtable is extended;
no new vptr is needed for Da.
So the Da_vtable (inherently compatible with Ba_vtable) needs two distinct entries for virtual calls to g():
in the Ba_vtable part of the vtable: Ba::g() vtable entry: calls final overrider of Ba::g() with an implicit this parameter of Ba* and returns a VB* value.
in the new members part of the vtable: Da::g() vtable entry: calls final overrider of Da::g() (which by is inherently the same as final overrider of Ba::g() in C++) with an implicit this parameter of Da* and returns a D* value.
Note that there is not really any ABI freedom here: the fundamentals of vptr/vtable design and their intrinsic properties imply the presence of these multiple entries for what is a unique virtual function at the high language level.
Note that making the virtual function body inline and a visible by the ABI (so that the ABI by classes with different inline function definitions could be made incompatible, allowing more information to inform memory layout) wouldn't possibly help, as inline code would only define what a call to a non overridden virtual function does: one cannot based the ABI decisions on choices that can be overridden in derived classes.
[Example of a virtual covariance that ends up being only trivially covariant as in a complete D the offset for VB is trivial and no adjustment code would have been necessary in that case:
struct Da : Ba { // non virtual base, so inherent primary
D * g() { return new D; } // VB really is primary in complete D
// so conversion to VB* is trivial here
};
Note that in that code an incorrect code generation for a virtual call by a buggy compiler that would use the Ba_vtable entry to call g() would actually work because covariance ends up being trivial, as VB is primary in complete D.
The calling convention is for the general case and such code generation would fail with code that returns an object of a different class.
--end example]
But if Da::g() is final in the ABI, only virtual calls can be made via the VB * g(); declaration: covariance is made purely static, the derived to base conversion is be done at compile time as the last step of the virtual thunk, as if virtual covariance was never used.
Possible extension of final
There are two types of virtual-ness in C++: member functions (matched by function signature) and inheritance (match by class name). If final stops overriding a virtual function, could it be applied to base classes in a C++-like language?
First we need to define what is overriding a virtual base inheritance:
An "almost direct" subobject relation means that a indirect subobject is controlled almost as a direct subobject:
an almost direct subobject can be initialized like a direct subobject;
access control is never a really obstacle to access (inaccessible private almost direct subobjects can be made accessible at discretion).
Virtual inheritance provides almost direct access:
constructor for each virtual bases must be called by ctor-init-list of the constructor of the most derived class;
when a virtual base class is inaccessible because declared private in a base class, or publicly inherited in a private base class of a base class, the derived class has the discretion to declare the virtual base as a virtual base again, making it accessible.
A way to formalize virtual base overriding is to make an imaginary inheritance declaration in each derived class that overrides base class virtual inheritance declarations:
struct VB { virtual void f(); };
struct D : virtual VB { };
struct DD : D
// , virtual VB // imaginary overrider of D inheritance of VB
{
// DD () : VB() { } // implicit definition
};
Now C++ variants that support both forms of inheritance don't have to have C++ semantic of almost direct access in all derived classes:
struct VB { virtual void f(); };
struct D : virtual VB { };
struct DD : D, virtual final VB {
// DD () : VB() { } // implicit definition
};
Here the virtual-ness of the VB base is frozen and cannot be used in further derived classes; the virtual-ness is made invisible and inaccessible to derived classes and the location of VB is fixed.
struct DDD : DD {
DD () :
VB() // error: not an almost direct subobject
{ }
};
struct DD2 : D, virtual final VB {
// DD2 () : VB() { } // implicit definition
};
struct Diamond : DD, DD2 // error: no unique final overrider
{ // for ": virtual VB"
};
The virtual-ness freeze makes it illegal to unify Diamond::DD::VB and Diamond::DD2::VB but virtual-ness of VB requires unification which makes Diamond a contradictory, illegal class definition: no class can ever derive from both DD and DD2 [analog/example: just like no useful class can directly derive from A1 and A2:
struct A1 {
virtual int f() = 0;
};
struct A2 {
virtual unsigned f() = 0;
};
struct UselessAbstract : A1, A2 {
// no possible declaration of f() here
// none of the inherited virtual functions can be overridden
// in UselessAbstract or any derived class
};
Here UselessAbstract is abstract and no derived class are too, making that ABC (abstract base class) extremely silly, as any pointer to UselessAbstract is provably a null pointer.
-- end analog/example]
That would provide a way to freeze virtual inheritance, to provide meaningful private inheritance of classes with virtual base (without it derived classes can usurp the relationship between a class and its private base class).
Such use of final would of course freeze the location of a virtual base in a derived class and its further derived classes, avoiding additional vtable entries that are only needed because the location of virtual base isn't fixed.
I believe that adding the final keyword should not be ABI breaking, however removing it from an existing class might render some optimizations invalid. For example, consider this:
// in car.h
struct Vehicle { virtual void honk() { } };
struct Car final : Vehicle { void honk() override { } };
// in car.cpp
// Here, the compiler can assume that no derived class of Car can be passed,
// and so `honk()` can be devirtualized. However, if Car is not final
// anymore, this optimization is invalid.
void foo(Car* car) { car->honk(); }
If foo is compiled separately and e.g. shipped in a shared library, removing final (and hence making it possible for users to derive from Car) could render the optimization invalid.
I'm not 100% sure about this though, some of it is speculation.
If you do not introduce new virtual methods in your final class (only override methods of parent class) you should be ok (the virtual table is going to be the same as the parent object, because it must be able to be called with a pointer to parent), if you introduce virtual methods the compiler can indeed ignore the virtual specifier and only generate standard methods, e.g:
class A {
virtual void f();
};
class B final : public A {
virtual void f(); // <- should be ok
virtual void g(); // <- not ok
};
The idea is that every time in C++ that you can invoke the method g() you have a pointer/reference whose static and dynamic type is B: static because the method does not exist except for B and his children, dynamic because final ensures that B has no children. For this reason you never need to do virtual dispatch to call the right g() implementation (because there can be only one), and the compiler might (and should) not add it to the virtual table for B - while it is forced to do so if the method could be overridden. This is basically the whole point for which the final keyword exist as far as I understand
I use polymorphism so frequently, but it suddenly dawned upon me. I have the case where my code is:
class A{
class B : public A{
class C : public A{
and I use class A as a polymorphic parameter type for passing in B or C sub types:
//Accepts B and C objects
void aMethod(A* a){
However, I gave A a virtual destructor- this is the only reason A (and B and C) contain a vtable pointer.
So my question is, if I hadn't declared A with a virtual destructor, then A wouldn't be polymorphic- I wouldn't be able to pass objects of type B or C in aMethod()??
So is non-polymorphic inheritance just about sharing code, whereas polymorphism (the base class must have a vtable) allows passing sub types as arguments of the base class type?
In this code you provide,
void aMethod(A a){
the a formal argument is not polymorphic. It's passed by value. When you pass in a B or C object as actual argument, you're just slicing it down to an A, that is, you're copying the A base class sub-object only.
Regarding
” So is non-polymorphic inheritance just about sharing code, whereas polymorphism (the base class must have a vtable) allows passing sub types as arguments of the base class type?
it combines two questions that have to be treated separately.
Inheriting from a non-polymorphic class is about sharing of code, yes, but it also introduces an is-a relationship, which can be important for e.g. passing by reference.
Inheriting from a polymorphic class (one with one or more virtual member functions) allows you to override base class functionality, or to implement it where the base class leaves that as a derived class responsibility – typically by having pure virtual member functions. This means that member functions in the base class can call your derived class’ member functions. Also, that calling member functions via a base class pointer or reference, can call your derived class’s implementations.
Non-polymorphic types also contain a subobject for each base class, and upcasts are still implicit.
You can therefore pass objects of derived classes just fine even when there is no polymorphism. The receiver will act on the base subobject, just as happens for data members and non-virtual functions of polymorphic types.
A class with its destructor the only virtual method, like your class A, is an oddity. AFAIK, such a class has no necessity in well designed code.
From your question, it is not clear whether the virtual destructor is needed (i.e. if you ever call the destructor of classes B or C through a reference or pointer to class A), but if it is, your code smells. If it is not, then simply make the destructor non-virtual.
In some books there is written that class that declares or inherits a virtual function is called a polymorphic class.
Class B doesn't have any virtual functions but passes more than one is-a test.
Class C has one virtual function but doesn't inherit.
class A {};
class B : public A {};
class C
{
public:
virtual void f () {}
};
is class B or C polymorphic ?
2003: 10.3/1 states, clearly:
A class that declares or inherits a virtual function is called a polymorphic class.
You actually said this yourself, word-for-word, so I don't really understand what the question is.
C (and its descendants, if you add any) is polymorphic; A and B are not.
Note that, in a wider OOP sense, you can always perform some "polymorphism" in that C++ always allows you to upcast; thus all objects that inherit can be treated as a different (but related) type.
However, the term "polymorphic" is defined slightly differently in C++, where it has more to do with whether you can downcast as well. If you don't want to be confusing like the C++ standard, you might call this "dynamic polymorphism".
Per the standard, "A class that declares or inherits a virtual function is called a polymorphic class."
Because neither A nor B declare or inherit a virtual function, they are not polymorphic.
C declares a virtual function, so it is polymorphic.
class C is polymorphic, meaning that using dynamic_cast or typeid on a C& will do a runtime type check, and calling member functions through a C& or C* will use virtual dispatch.
(Of course, the as-if rule allows the compiler to avoid the runtime dispatch under some condition when it knows the runtime type in advance, such as when you just created the object.)
As #Bill mentioned in a comment, that isn't just what some books say, it's the definition of polymorphic class, found in the C++ standard (section 10.3, [class.virtual]):
Virtual functions support dynamic binding and object-oriented programming. A class that declares or inherits a virtual function is called a polymorphic class.
When exactly does the compiler create a virtual function table?
1) when the class contains at least one virtual function.
OR
2) when the immediate base class contains at least one virtual function.
OR
3) when any parent class at any level of the hierarchy contains at least one virtual function.
A related question to this:
Is it possible to give up dynamic dispatch in a C++ hierarchy?
e.g. consider the following example.
#include <iostream>
using namespace std;
class A {
public:
virtual void f();
};
class B: public A {
public:
void f();
};
class C: public B {
public:
void f();
};
Which classes will contain a V-Table?
Since B does not declare f() as virtual, does class C get dynamic polymorphism?
Beyond "vtables are implementation-specific" (which they are), if a vtable is used: there will be unique vtables for each of your classes. Even though B::f and C::f are not declared virtual, because there is a matching signature on a virtual method from a base class (A in your code), B::f and C::f are both implicitly virtual. Because each class has at least one unique virtual method (B::f overrides A::f for B instances and C::f similarly for C instances), you need three vtables.
You generally shouldn't worry about such details. What matters is whether you have virtual dispatch or not. You don't have to use virtual dispatch, by explicitly specifying which function to call, but this is generally only useful when implementing a virtual method (such as to call the base's method). Example:
struct B {
virtual void f() {}
virtual void g() {}
};
struct D : B {
virtual void f() { // would be implicitly virtual even if not declared virtual
B::f();
// do D-specific stuff
}
virtual void g() {}
};
int main() {
{
B b; b.g(); b.B::g(); // both call B::g
}
{
D d;
B& b = d;
b.g(); // calls D::g
b.B::g(); // calls B::g
b.D::g(); // not allowed
d.D::g(); // calls D::g
void (B::*p)() = &B::g;
(b.*p)(); // calls D::g
// calls through a function pointer always use virtual dispatch
// (if the pointed-to function is virtual)
}
return 0;
}
Some concrete rules that may help; but don't quote me on these, I've likely missed some edge cases:
If a class has virtual methods or virtual bases, even if inherited, then instances must have a vtable pointer.
If a class declares non-inherited virtual methods (such as when it doesn't have a base class), then it must have its own vtable.
If a class has a different set of overriding methods than its first base class, then it must have its own vtable, and cannot reuse the base's. (Destructors commonly require this.)
If a class has multiple base classes, with the second or later base having virtual methods:
If no earlier bases have virtual methods and the Empty Base Optimization was applied to all earlier bases, then treat this base as the first base class.
Otherwise, the class must have its own vtable.
If a class has any virtual base classes, it must have its own vtable.
Remember that a vtable is similar to a static data member of a class, and instances have only pointers to these.
Also see the comprehensive article C++: Under the Hood (March 1994) by Jan Gray. (Try Google if that link dies.)
Example of reusing a vtable:
struct B {
virtual void f();
};
struct D : B {
// does not override B::f
// does not have other virtuals of its own
void g(); // still might have its own non-virtuals
int n; // and data members
};
In particular, notice B's dtor isn't virtual (and this is likely a mistake in real code), but in this example, D instances will point to the same vtable as B instances.
The answer is, 'it depends'. It depends on what you mean by 'contain a vtbl' and it depends on the decisions made by the implementor of the particular compiler.
Strictly speaking, no 'class' ever contains a virtual function table. Some instances of some classes contain pointers to virtual function tables. However, that's just one possible implementation of the semantics.
In the extreme, a compiler could hypothetically put a unique number into the instance that indexed into a data structure used for selecting the appropriate virtual function instance.
If you ask, 'What does GCC do?' or 'What does Visual C++ do?' then you could get a concrete answer.
#Hassan Syed's answer is probably closer to what you were asking about, but it is really important to keep the concepts straight here.
There is behavior (dynamic dispatch based on what class was new'ed) and there's implementation. Your question used implementation terminology, though I suspect you were looking for a behavioral answer.
The behavioral answer is this: any class that declares or inherits a virtual function will exhibit dynamic behavior on calls to that function. Any class that does not, will not.
Implementation-wise, the compiler is allowed to do whatever it wants to accomplish that result.
Answer
a vtable is created when a class declaration contains a virtual function. A vtable is introduced when a parent -- anywhere in the heirarchy -- has a virtual function, lets call this parent Y. Any parent of Y WILL NOT have a vtable (unless they have a virtual for some other function in their heirarchy).
Read on for discussion and tests
-- explanation --
When you specify a member function as virtual, there is a chance that you may try to use sub-classes via a base-class polymorphically at run-time. To maintain c++'s guarantee of performance over language design they offered the lightest possible implementation strategy -- i.e., one level of indirection, and only when a class might be used polymorphically at runtime, and the programmer specifies this by setting at least one function to be virtual.
You do not incur the cost of the vtable if you avoid the virtual keyword.
-- edit : to reflect your edit --
Only when a base class contains a virtual function do any other sub-classes contain a vtable. The parents of said base class do not have a vtable.
In your example all three classes will have a vtable, this is because you can try to use all three classes via an A*.
--test - GCC 4+ --
#include <iostream>
class test_base
{
public:
void x(){std::cout << "test_base" << "\n"; };
};
class test_sub : public test_base
{
public:
virtual void x(){std::cout << "test_sub" << "\n"; } ;
};
class test_subby : public test_sub
{
public:
void x() { std::cout << "test_subby" << "\n"; }
};
int main()
{
test_sub sub;
test_base base;
test_subby subby;
test_sub * psub;
test_base *pbase;
test_subby * psubby;
pbase = ⊂
pbase->x();
psub = &subby;
psub->x();
return 0;
}
output
test_base
test_subby
test_base does not have a virtual table therefore anything casted to it will use the x() from test_base. test_sub on the other hand changes the nature of x() and its pointer will indirect through a vtable, and this is shown by test_subby's x() being executed.
So, a vtable is only introduced in the hierarchy when the keyword virtual is used. Older ancestors do not have a vtable, and if a downcast occurs it will be hardwired to the ancestors functions.
You made an effort to make your question very clear and precise, but there's still a bit of information missing. You probably know, that in implementations that use V-Table, the table itself is normally an independent data structure, stored outside the polymorphic objects, while objects themselves only store a implicit pointer to the table. So, what is it you are asking about? Could be:
When does an object get an implicit pointer to V-Table inserted into it?
or
When is a dedicated, individual V-Table created for a given type in the hierarchy?
The answer to the first question is: an object gets an implicit pointer to V-Table inserted into it when the object is of polymorphic class type. The class type is polymorphic if it contains at least one virtual function, or any of its direct or indirect parents are polymorphic (this is answer 3 from your set). Note also, that in case of multiple inheritance, an object might (and will) end up containing multiple V-Table pointers embedded into it.
The answer to the second question could be the same as to the first (option 3), with a possible exception. If some polymorphic class in single inheritance hierarchy has no virtual functions of its own (no new virtual functions, no overrides for parent virtual function), it is possible that implementation might decide not to create an individual V-Table for this class, but instead use it's immediate parent's V-Table for this class as well (since it is going to be the same anyway). I.e. in this case both objects of parent type and objects of derived type will store the same value in their embedded V-Table pointers. This is, of course, highly dependent on implementation. I checked GCC and MS VS 2005 and they don't act that way. They both do create an individual V-Table for the derived class in this situation, but I seem to recall hearing about implementations that don't.
C++ standards doesn't mandate using V-Tables to create the illusion of polymorphic classes. Most of the time implementations use V-Tables, to store the extra information needed. In short, these extra pieces of information are equipped when you have at least one virtual function.
The behavior is defined in chapter 10.3, paragraph 2 of the C++ language specification:
If a virtual member function vf is
declared in a class Base and in a
class Derived, derived directly or
indirectly from Base, a member
function vf with the same name and
same parameter list as Base::vf is
declared, then Derived::vf is also
virtual ( whether or not it is so
declared ) and it overrides Base::vf.
A italicized the relevant phrase. Thus, if your compiler creates v-tables in the usual sense then all classes will have a v-table since all their f() methods are virtual.