I've read in many places (for example here) about people getting a "pure virtual method called" error and program crash at runtime. This answer says that
Most compilers assign such vtable entries to a stub which emits an error before aborting the program.
and this one even says that Itanium ABI specifies what that stub is.
The problem is: all my attempts to see this behaviour in action are caught by the compiler (GCC 6.4.1) at compile time as undefined references. For example, when calling a pure virtual function from a constructor of the abstract class, I get a warning
pure virtual ‘virtual int X::f()’ called from constructor
but at the same time simply no code at all is generated for X::f()
so this is followed by
undefined reference to 'X::f()'
from the linker and the compilation fails. This seems a pretty foolproof way of preventing the error at runtime. In which situation would my compiler actually need to generate the aforementioned stub? Or has it gotten smart enough to detect all the possible pathological situations early enough?
Usually it will be called indirectly from within a constructor. Here's a minimal example:
#include <iostream>
struct X {
virtual void foo() = 0;
void bar() { foo(); }
X() { bar(); std::cout << "X"; }
};
struct Y : X {
void foo() override {}
};
int main() {
Y y;
return 0;
}
The compiler is obligated to bind the call statically if it appears inside the c'tor directly (and hence can produce a useful error message for a pure virtual function). But when the call is indirect, from another member, it must be dynamically dispatched.
Naturally, the Y
part is not yet constructed during the construction of X
, so the whole thing collapses on itself in a blaze of undefined behavior.
Live example - With the stub at work
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With