Do interfaces (polymorphic class solely with pure virtual functions) have a vtable?
Since interfaces do not implement a polymorphic function themself and cant be directly constructed there would be no need for the linker to place a vtable. Is that so? Im especially concerned about the MSVC compiler.
Yes, they do. And there are a number of good reasons for that.
The first good reason is that even pure virtual methods have implementation. Either implicit or explicit. It is relatively easy to pull off a trick calling a pure virtual function, so you can basically provide a definition for one of yours, call it and see what happens. For that reason, there should be a virtual table in a first place.
There is another reason for putting a virtual table into a base class even if all of its methods are pure virtual and there are no other data members though. When polymorphism is used, a pointer to a base class is passed all around the program. In order to call a virtual method, compiler/runtime should figure out the relative offset of the virtual table from the base pointer. If C++ had no multiple inheritance, one could assume a zero offset from the abstract base class (for example), in which case it would have been possible not to have a vtable there (but we still need it due to reason #1). But since there is a multiple inheritance involved, a trick ala "vtable is there at 0 offset" won't work because there could be two or three vtables depending on a number (and type) of base classes.
There could be other reasons I haven't though of as well.
Hope it helps.
From a purely C++ point of view it's an academic question. Virtual functions don't have to be implemented with vtables, if they are there is no portable way to get at them.
If you're particular concerned about the MSVC compiler you might want to decorate your interfaces with __declspec(novtable).
(In general, in common implementations, an abstract class may need a vtable, e.g.:
struct Base {
Base();
virtual void f() {}
virtual void g() = 0;
};
void h(Base& b) {
b.f(); // Call f on a Base that is not (yet) a Derived
// vtable for Base required
}
Base::Base() {
h(*this);
}
struct Derived : Base {
void g() {}
};
int main() {
Derived d;
}
)
The vtable is not necessary, but rarely optimized out. MSVC provides the __declspec(novtable) extension, which tells the compiler explicitly that the vtable can be removed. In the absence of that, the compiler would have to check itself that the vtable is not used. This is not exceptionally hard, but still far from trivial. And since it doesn't provide real speed benefits in regular code, the check is not implemented in any compiler I know.
Related
In most books and articles the only 'safe' (or at least the only advised) way of doing multiple inheritance is virtual inheritance with pure abstract base classes (which you could call virtual interfaces).
The reason is mostly stated as to avoid the Diamond Problem where one could create ambiguities for value of data members or for the implementation status of non-pure virtual functions.
Pure abstract base class don't suffer from both (no data members, no non-pure virtuals) and virtual inheritance even resolves the ambiguity of the actual memory address of the base class.
But given this explanation: If ambiguity only arises from forms of 'state' (e.g. data members, static function variables), then isn't a state-less non-abstract (maybe even with all 'final' methods) class equally safe to be the base class in a multiple inheritance hierarchy?
What possible problem am I missing?
PS: In case the answer is "If there is no virtual method, then you could use composition anyway": Besides the academic interest, I have a case where I need the property of member functions to be able to shadow free, global C-style functions, so I can't access them via a pointer-to-composition-object.
Virtual inheritance already achieves the desired safety by avoiding duplicate copies of non-static members. Variables and functions are the same in this regard: even if a base class is stateless, its non-static member functions are ambiguous if it is a base class more than once.
Virtual inheritance also handles overriding intelligently:
struct B {
virtual ~B()=default;
virtual void f()/*=0*/;
};
struct X : virtual B {};
struct Y : virtual B {
void f() override;
};
struct D : X,Y {};
B& b();
void g() {
b().f(); // calls Y::f
}
It doesn’t matter whether B::f is pure-virtual or not.
So being stateless is not the important part. Moreover, if the base is stateless, having final members would prevent the most obvious use case of default stub implementations. (The only other possibility would be to depend on the value of this; otherwise the functions could be static.) So I wouldn’t necessarily encourage making a class stateless because it is intended for virtual inheritance (rather than simply because minimizing state is a generally good idea).
So you’re correct that non-pure-virtual functions can be safe, but that’s true even if the base is stateful. There are still limits to the safety of multiple inheritance, of course, like ambiguity if an overload set accepts multiple direct bases.
Normally calling virtual functions from constructors is considered bad practice, because overridden functions in sub-objects will not be called as the objects have not been constructed yet.
But, Consider the following classes:
class base
{
public:
base() {}
~base() {}
private:
virtual void startFSM() = 0;
};
class derived final : public base
, public fsm_action_interface
{
public:
derived() : base{}
, theFSM_{}
{ startFSM(); }
/// FSM interface actions
private:
virtual void startFSM()
{ theFSM_.start(); }
private:
SomeFSMType theFSM_;
}
In this case class derived is marked as final so no o further sub-objects can exist. Ergo the virtual call will resolve correctly (to the most derived type).
Is it still considered bad practice?
This would still be considered bad practice as this sort of this almost always indicates bad design. You'd have to comment the heck out of the code to explain why this works in this one case.
T.C.'s comment above reinforces one of the reasons why this is considered bad practice.
What happens if, a year down the line, you decide that derived
shouldn't be final after all?
That said, in the example above, the pattern will work without issue. This is because the constructor of the most derived type is the one calling the virtual function. This problem manifests itself when a base class's constructor calls a virtual function that resolves to a subtype's implementation. In C++, such a function won't get called, because during base class construction, such calls will never go to a more derived class than that of the currently executing constructor or destructor. In essence, you end up with behavior you didn't expect.
Edit:
All (correct/non-buggy) C++ implementations have to call the version of the function defined at the level of the hierarchy in the current constructor and no further.
The C++ FAQ Lite covers this in section 23.7 in pretty good detail.
Scott Meyers also weighs in on the general issue of calling virtual functions from constructors and destructors in Effective C++ Item 9
Regarding
” Normally calling virtual functions from constructors is considered bad practice, because overridden functions in sub-objects will not be called as the objects have not been constructed yet.
That is not the case. Among competent C++ programmers it’s normally not regarded as bad practice to call virtual functions (except pure virtual ones) from constructors, because C++ is designed to handle that well. In contrast to languages like Java and C#, where it might result in a call to a method on an as yet uninitialized derived class sub-object.
Note that the dynamic adjustment of dynamic type has a runtime cost.
In a language oriented towards ultimate efficiency, with "you don't pay for what you don't use" as a main guiding principle, that means that it's an important and very much intentional feature, not an arbitrary choice. It's there for one purpose only. Namely to support those calls.
Regarding
” In this case class derived is marked as final so no o further sub-objects can exist. Ergo the virtual call will resolve correctly (to the most derived type).
The C++ standard guarantees that at the time of construction execution for a class T, the dynamic type is T.
Thus there was no problem about resolving to incorrect type, in the first place.
Regarding
” Is it still considered bad practice?
It is indeed bad practice to declare a member function virtual in a final class, because that’s meaningless. The “still” is not very meaningful either.
Sorry, I didn't see that the virtual member function was inherited as such.
Best practice for marking a member function as an override or implementation of pure virtual, is to use the keyword override, not to mark it as virtual.
Thus:
void startFSM() override
{ theFSM_.start(); }
This ensures a compilation error if it is not an override/implementation.
It can work, but why does startFSM() need to be virtual? In no case do you actually want to actually call anything but derived::startFSM(), so why have any dynamic binding at all? If you want to have it call the same thing as a dynamically binded method, make another non-virtual function called startFSM_impl() and have both the constructor and startFSM() call it instead.
Always prefer non-virtual to virtual if you can help it.
class base{
public:
virtual void fn() {
}
};
class der1 : public base {
void fn() {
}
};
class der2 : public der1 {
virtual void fn() {
}
};
I have another question.In definition of class der1, I have not mention "virtual" while redefining function fn. Has it any effect while creating V table
As already mentioned, vtable is a compiler/platform specific implementation detail, so there is no general answer.
I have another question.In definition of class der1, I have not mention "virtual" while redefining function fn. Has it any effect while creating V table
Since the function fn() has been defined as virtual in the base class, all subclass implementations are also virtual by definition (thus overriding the base class implementation), regardless of whether they are explicitly declared so. So the vtable will contain them (if the specific compiler generates one).
You can easily test this by making base::fn() pure virtual. If declaring der1::fn() virtual made a difference, you could not instantiate der1 without it.
So, as the pedantic answers implied: the C++ language does not mention v-tables, it's an implementation details that all major compilers used, as it's relatively simple and very efficient (because it's so used, optimizations are well-known).
With that said, the typical answer is that there will be one v-table per class containing virtual functions. Some may be optimized out, if proved to be unused.
Typically, it could be unnecessary to generate a v-table for an abstract class, as it cannot be instantiated. However calling virtual functions in constructors and destructors is still allowed (though the effects are not always those expected), so compilers usually generate a v-table and simply set the entries to the pure virtual functions to null.
Therefore, your answer is probably 3.
The following implies a compiler such as GCC which implements the Itanium C++ ABI.
You can actually verify this 3 by generating a library and dumping the symbols (v-tables and typeinfo symbols are generated for classes with virtual functions):
$ nm somelib.so | grep Foo
00000000012a48b0 V _ZTIN3FooE
0000000000e0fca0 V _ZTSN3FooE
00000000012a4620 V _ZTVN3FooE
$ nm somelib.so | grep Foo | c++filt
00000000012a48b0 V typeinfo for Foo
0000000000e0fca0 V typeinfo name for Foo
00000000012a4620 V vtable for Foo
The prefixes to look for are _ZTIN, _ZTSN and _ZTVN for (resp.) the typeinfo, typeinfo name and vtable.
There can be no concrete answer for this because Virtualism is left out as an implementation detail of compilers.
The C++ standard does not talk about vptr or vtable at all. The answer for this can vary from each compiler to compiler.
How many V table will be created in the following code?
The question can not be answered.
Nor do you want to know, nor should you care. It makes no difference in how your code is used or works.
I have another question.
Ok Listening.
In definition of class der1, I have not mention "virtual" while redefining function fn.
Because the definition of 'void fn()' is exactly the same as in the base class it inherits the virtual attribute of the function it is overriding. Thus it is also virtual.
Has it any effect while creating V table
There is no way to tell. As V-Table have nothing to do with the C++ language (they are what the compiler does behind the code, if it even uses a V-table (which it may not)).
There are many resources online about VTables. They commonly have the same statement regarding them:
"Whenever a class itself contains virtual functions or overrides virtual functions from a parent class the compiler builds a vtable for that class. This means that not all classes have a vtable created for them by the compiler. The vtable contains function pointers that point to the virtual functions in that class. There can only be one vtable per class, and all objects of the same class will share the same vtable."
So why exactly does this mean that not all classes have a vtable created for them by the compiler? Is it because somc classes don't have virtual functions?
Precisely. Some classes don't have a vtable because they don't have any virtual methods.
Virtual methods are methods for which your compiler cannot generate a direct call because it varies depending on the implementation of the class. Vtables are a kind of lookup table that solve this problem by delaying the decision of which implementation to call during the run time of your program: instead of generating a function call, your compiler generates a method lookup on the vtable, then calls the returned method.
Take this example:
class Foo
{
public:
virtual void vMethod()
{
std::cout << "Foo::vMethod was called!" << std::endl;
}
};
class Bar : public Foo
{
public:
virtual void vMethod()
{
std::cout << "Bar::vMethod was called!" << std::endl;
std::cout << "This is not the same as Foo::vMethod." << std::endl;
}
};
Foo* foo = new Bar;
foo->vMethod();
This will print Bar's message. In most non-trivial scenarios, your compiler cannot know in advance the type of the object on which a virtual method is called. As mentioned above, the vtable solves the problem by providing a uniform lookup mechanism to find method implementations, no matter the type of an object.
A vtable pointer must exist in every instance of a class (which requires the size of a pointer of additional memory, likely to be 4 or 8 bytes), and some insignificant amount of statical memory somewhere in your program's address space. This may not seem a lot to you (and indeed many people would agree), but this can be cumbersome in certain scenarios (like embedded systems where memory is extremely limited). Having vtables for each class would violate the general C++ principle that you pay only for what you use, and therefore the compiler doesn't generate any vtable if it doesn't have to.
Not having a vtable has the notable side effect of disabling runtime type information. If you need to use RTTI in your code, your classes must have at least one virtual method. The convention is to mark the destructor virtual in these cases.
Actually, nothing in C++ requires that any class has a vtable - it's entirely an implementation issue. However, a class with virtual functions must somehow support polymorphic function calls, and this will always require a table/map of some sort. This table/map will be created by the compiler for classes that have polymorphic functions, and might (depending on compiler quality) be created for those that don't.
In addition, some classes don't have a vtable because is explicitly removed, see __declspec(novtable) (compiler specific)
I recently came to know that in C++ pure virtual functions can optionally have a body.
What are the real-world use cases for such functions?
The classic is a pure virtual destructor:
class abstract {
public:
virtual ~abstract() = 0;
};
abstract::~abstract() {}
You make it pure because there's nothing else to make so, and you want the class to be abstract, but you have to provide an implementation nevertheless, because the derived classes' destructors call yours explicitly. Yeah, I know, a pretty silly textbook example, but as such it's a classic. It must have been in the first edition of The C++ Programming Language.
Anyway, I can't remember ever really needing the ability to implement a pure virtual function. To me it seems the only reason this feature is there is because it would have had to be explicitly disallowed and Stroustrup didn't see a reason for that.
If you ever feel you need this feature, you're probably on the wrong track with your design.
Pure virtual functions with or without a body simply mean that the derived types must provide their own implementation.
Pure virtual function bodies in the base class are useful if your derived classes wants to call your base class implementation.
One reason that an abstract base class (with a pure virtual function) might provide an implementation for a pure virtual function it declares is to let derived classes have an easy 'default' they can choose to use. There isn't a whole lot of advantage to this over a normal virtual function that can be optionally overridden - in fact, the only real difference is that you're forcing the derived class to be explicit about using the 'default' base class implementation:
class foo {
public:
virtual int interface();
};
int foo::interface()
{
printf( "default foo::interface() called\n");
return 0;
};
class pure_foo {
public:
virtual int interface() = 0;
};
int pure_foo::interface()
{
printf( "default pure_foo::interface() called\n");
return 42;
}
//------------------------------------
class foobar : public foo {
// no need to override to get default behavior
};
class foobar2 : public pure_foo {
public:
// need to be explicit about the override, even to get default behavior
virtual int interface();
};
int foobar2::interface()
{
// foobar is lazy; it'll just use pure_foo's default
return pure_foo::interface();
}
I'm not sure there's a whole lot of benefit - maybe in cases where a design started out with an abstract class, then over time found that a lot of the derived concrete classes were implementing the same behavior, so they decided to move that behavior into a base class implementation for the pure virtual function.
I suppose it might also be reasonable to put common behavior into the pure virtual function's base class implementation that the derived classes might be expected to modify/enhance/augment.
One use case is calling the pure virtual function from the constructor or the destructor of the class.
The almighty Herb Sutter, former chair of the C++ standard committee, did give 3 scenarios where you might consider providing implementations for pure virtual methods.
Gotta say that personally – I find none of them convincing, and generally consider this to be one of C++'s semantic warts. It seems C++ goes out of its way to build and tear apart abstract-parent vtables, then briefly exposes them only during child construction/destruction, and then the community experts unanimously recommend never to use them.
The only difference of virtual function with body and pure virtual function with body is that existence of second prevent instantiation. You can't mark class abstract in c++.
This question can really be confusing when learning OOD and C++. Personally, one thing constantly coming in my head was something like:
If I needed a Pure Virtual function to also have an implementation, so why make it "Pure" in first place ? Why not just leaving it only "Virtual" and have derivatives, both benefit and override the base implementation ?
The confusion comes to the fact that many developers consider the no body/implementation as the primary goal/benefit of defining a pure virtual function. This is not true!
The absence of body is in most cases a logical consequence of having a pure virtual function. The main benefit of having a pure virtual function is defining a contract: By defining a pure virtual function, you want to force every derivative to always provide their own implementation of the function. This "contract aspect" is very important especially if you are developing something like a public API. Making the function only virtual is not so sufficient because derivatives are no longer forced to provide their own implementation, therefore you may loose the contract aspect (which can be limiting in the case of a public API).
As commonly said :
"Virtual functions can be overrided, Pure Virtual functions must be overrided."
And in most cases, contracts are abstract concepts so it doesn't make sense for the corresponding pure virtual functions to have any implementation.
But sometimes, and because life is weird, you may want to establish a strong contract among derivatives and also want them to somehow benefit from some default implementation while specifying their own behavior for the contract. Even if most book authors recommend to avoid getting yourself into these situations, the language needed to provide a safety net to prevent the worst! A simple virtual function wouldn't be enough since there might be risk of escaping the contract. So the solution C++ provided was to allow pure virtual functions to also be able to provide a default implementation.
The Sutter article cited above gives interesting use cases of having Pure Virtual functions with body.