The C++ standard is written in such a way that a vtable as the first member of a polymorphic class instance is the obvious way to satisfy the standard's demands. I don't think there is any mainstream C++ implementation that doesn't use vtables, although some older C++ compilers used a slightly different layout.

The fact that inside a single CU an optimizing compiler can determine the targets of polymorphic dispatch statically is unrelated, because most usage scenarios (more than one CU, external modules) preclude such optimizations anyway.

vtables aren't undefined, they are implementation defined and part of the C++ ABI. As soon as you expose something through the C++ ABI the compiler has to use the ABI's definitions.

People might bring up that the only ABI that is "stable" is Itanium, while MSVC has historically broken ABI stability quite regularly until fairly recently (2017, iirc?).

That said, so much software on Windows relies on vtable layout that breaking their particular implementation in the ABI would be a massive breaking change, so it's unlikely that it will happen.

I'm not a Windows programmer,but IIRC vtable layout is very thightly tied to COM so I doubt that MS has broken or will break this specific bit of the ABI anytime soon.

The layout of objects, including dynamic objects, is implementation defined.

Accessing them through reinterpret_cast is however undefined. Don't expect that compilers won't screw you over this.