Is there a way to prevent the vtable from being emitted in c++?

Question

I'm making a library which requires that classes must inherit other classes to do something specific. However, this is not simple polymorphism. These classes are code generators of virtual functions, with no data and which rely on CRTP, so they themselves don't need a vtable.

Is there a way to stop the vtable from being emitted for these classes? I'd assume that the virtual function pointers would be passed the the derived class, and the virtual destructor would just skip over these classes. Sort of like melding the classes together into one.

If nothing general is available across the C++ domain, then maybe specific to clang, gcc and vc?

Example:

#include<iostream>

template <typename D, typename B>
struct jelly : B
{
  virtual void do_stuff() { static_cast<D*>(this)->D::do_some_other_stuff(); }
};

template <typename D>
struct jelly<D, void>
{
  virtual void do_stuff() { static_cast<D*>(this)->D::do_some_other_stuff(); }
};

struct A : jelly<A, void>
{
  void do_some_other_stuff() { std::cout << "A::do_some_other_stuff()\n"; }
};

struct B : jelly<B, A>
{
  void do_some_other_stuff() { std::cout << "B::do_some_other_stuff()\n"; }
};

int main()
{
  A a;
  a.do_stuff();  // output: A::do_some_other_stuff()
  B b;
  b.do_stuff();  // output: B::do_some_other_stuff()
  A& aa = b;
  aa.do_stuff(); // output: B::do_some_other_stuff()
}

Just to clarify, this is just an example. It does run, but the number of classes that jelly represents is actually 3 different ones. One that is inherited explicitly by the dev using the jelly library, and 2 others that are done implicitly, before inheriting back into the dev's own classes. It is because of the number of classes would increase 3x that it has become to worry me, and is why I am asking this question.

Answer 1

The only known to me compiler extension to do this is MSVC's __declspec(novtable):

This form of __declspec can be applied to any class declaration, but should only be applied to pure interface classes, that is, classes that will never be instantiated on their own. The __declspec stops the compiler from generating code to initialize the vfptr in the constructor(s) and destructor of the class. In many cases, this removes the only references to the vtable that are associated with the class and, thus, the linker will remove it. Using this form of __declspec can result in a significant reduction in code size.

If you attempt to instantiate a class marked with novtable and then access a class member, you will receive an access violation (AV).

This modifier is implied when you use MSVC's __interface keyword.

Answer 2

If you declare a member function to be virtual, that class must have whatever machinery the implementation deems necessary to accomplish what C++ requires that virtual functions do. But this also means that the type is now polymorphic, which requires that the type be able to do what C++ requires that polymorphic types can do. Specifically, typeid and dynamic_cast.

That's important. A class which derives from a polymorphic type is itself polymorphic, whether it overrides any virtual functions or not. This means that you must be able to get the type information from an instance of that class. Whether you actually do it is irrelevant; you could, and therefore the machinery must exist to allow it.

For vtable implementations, this typically means that every polymorphic type needs to have a unique vtable object. The vtable would have an index or pointer to some type-specific information, in addition to the pointers to virtual functions. Since vtables tend to be pretty tiny, having another vtable around isn't particularly onerous. Indeed, the type identification information itself is generally more significant than the vtable.

Now, compilers have options that allow you to remove all vestiges of run-time type identification. Specifically, typeid doesn't work anymore, and dynamic_cast never throws and thus needs not verify the cast, it is no longer necessary for the compiler to give A a different vtable from jelly<A>. However, the main target of the feature is the table of type_info objects and other identifying information. So I can't speak to the effects of this feature on vtable generation.

Ultimately however, there isn't much you can do. Those classes are probably going to get vtables, and that's that.

Answer 3

You do:

template <typename D, typename B>
struct jelly : B
{
  virtual void do_stuff() { D::do_some_other_stuff(); }
};

Then you do:

struct B : jelly<B, A>
{
  void do_some_other_stuff() { std::cout << "B::do_some_other_stuff()\n"; }
};

Which means that struct B depends on jelly<B, A>. That, in turn needs to call a B(aka D) function do_some_other_stuff, but B is not yet defined. Maybe you need to move void do_stuff outside of the class declaration. Anyway, it shouldn't get inlined as you're declaring it virtual.

Also, you're using

struct A : jelly<A, void>

Which translates to:

struct jelly : void
{
  virtual void do_stuff() { A::do_some_other_stuff(); }
};

How do you expect to inherit from void?

Style note: don't use struct just to avoid public. Don't use typename D when there should be a class (because you're inheriting) and not just any typename. Don't use names A, B, C, D, type some more descriptive. Is struct jelly : B inheriting from typename B or from struct B?