cost of Virtual-and-final function at base class (vtable/virtual-cost)

Question

Is there any vtable/virtual cost for a virtual final function (final at base class)?

class B{
    public: virtual void fFinal() final{ .... do something  ..... }
    public: void fCheap() { .... do something ..... }
    public: virtual void fVirtual() { .... do something ..... }
};
class C : public B{
    public: virtual void fVirtual() { .... do something ..... }
};

Will the cost of fFinal() = cost of fCheap() or fVirtual()?

I am going to use final+virtual to prevent human-error ("Don't override me").
fCheap() is not so safe, because I can still hide the parent's function.

These below links don't provide answer.

• What's the point of a final virtual function?
• Does the cost of virtual functions increase with the number of classes in the inheritance tree?
• http://en.cppreference.com/w/cpp/language/final

Answer 1

As far as I can tell, it is unspecified how virtual functions mechanism is implemented by any particular compiler. It is most likely that they put a pointer to vtable into the class if it has at least one virtual function even if this virtual function is marked as final.

I've tested a simplifed example based on your code snippet:

class Base {
    public:
        virtual void foo() final {}
};

static_assert(sizeof(Base) > 1, "No pointer to vtable");

Seems that both gcc 6.3 and clang 4.0 add a pointer to vtable.

It means that the rules which govern usual virtual functions apply for a function which marked both virtual and final in the base class. As a consequence, Base class grows in size and, and when you call foo via the pointer/reference to Base class or some class derived from Base, you pay some additional cost for being redirected through the vtable.

Answer 2

From a purely theoretical point of view without taking compiler optimiziation into account, fCheap() is indeed fastest. Both fFinal() and fVirtual() incur the cost of an added lookup/indirection because they have to be called through the vtable. Also object size will increase because of the vtable, but that has nothing to do with final. You pay the cost in size as soon as your class (or one of its bases) has any virtual functions at all.

Enter modern optimizers, i.e. devirtualization. The cost of increased object size won’t go away. The cost of the virtual calls might. Declaring a virtual function and immediately making it final makes it relatively easy for the compiler to proof at compile time exactly which function will be called. Bets are the fFinal() call will be devirtualized to a normal function call[1]. If that can happen for FVirtual() as well entirely depends on the situation at the call site.

In general virtual call overhead is small. I wouldn’t worry about it too much unless you have conrete evidence from profiling your actual code that this is a performance bottleneck.

Update

[1] How likely you are to win the bet depends on your compiler, its version and configuration. The only way to make sure is to look at the assembly generated from your actual code. I wouldn’t dare to make a general statement here. I played around a bit with recent GCC and Clang at -O3 in the Compiler Explorer. In every example I tried fFinal() was inlined (granted, they were kind of trivial). So, obviously, both compilers had no problem proofing away even more than virtuality. :)