Virtual function efficiency and the 'final' keyword

Question

Consider a program that has a class Foo containing a function Foo::fn declared like this:

virtual void fn();

and

Answer 1

I've not EVER cared about the size of the vtable. It is typically relatively small, and there is only one per class declaration. What is much more bothersome is extra space taken up in the class instances, since, except for singleons, class instances are often many of. So adding extra elements into a class, in some way or another, will definitely affect the amount of memory. If it's REALLY bothering you that the vtable is too large, then doing some redesign so that there aren't so many different virtual member functions (perhaps splitting the class hierarchy into several classes) or fewer derived classes. But really, even if you have hundreds of classes, each with a hundred virtual member functions, it's still relatively small - 200 classes with 100 members would take up 20000 * 8 bytes per entry [64-bit architecture] -> 160KB. Surely the 20000 functions [yes, in theory, you only need ONE new function per derived class to need a new vtable, but that is rather a silly design, so unlikely in reality]

The purpose of the final keyword is to ensure that you don't derive from it further - this is useful for example if you have a basic class hierarchy where some particular function should not be "changed". Say for example you have:

class user_base
{
    public:
      virtual bool check_password(); {... magical code .. };
      virtual bool is_super_user() = 0;
};

class superuser : public user_base
{
    public:
      virtual bool check_password() final  
        { .... magical code ...
          ... extra checks to ensure no remote login... 
        }
      virtual bool is_super_user() final { return true; }

 };

 class user : public user_base
 {
  public:
      virtual bool is_super_user() final { return false; }
 };

You have to trick around a bit to ensure that user_base isn't used as a base-class for a fake_super_user, and of course, there are other BIG security issues with such a design, but it gives you some idea.

Answer 2

If fn is defined as final in Bar, the compiler can dispatch calls to fn through a pointer or reference to Bar statically since it knows that Bar::fn is the final overrider. For example, this program fragment:

struct Foo {
  virtual void fn();
};

struct Bar : Foo {
  void fn() final override;
};

void with_foo(Foo& o) { o.fn(); }
void with_bar(Bar& o) { o.fn(); }

compiles to (See gcc.godbolt.org for details):

with_foo(Foo&):
    subq    $8, %rsp
    movq    (%rdi), %rax
    call    *(%rax)
    addq    $8, %rsp
    ret

with_bar(Bar&):
    subq    $8, %rsp
    call    Bar::fn()
    addq    $8, %rsp
    ret

the call in with_foo is dynamically dispatched (call *(%rax) is an indirect call) through the vtable, but the call in with_bar statically dispatches to Bar::fn().

The simplest method to make Bar::fn be the final overrider of Foo::fn without changing behavior is to define it to statically call Foo::fn:

struct Bar : Foo {
  void fn() final override { Foo::fn(); }
};