It's not particularly terrifying - it's just an array of pointers, and it's well known how it's implemented for the main compilers. As I've pointed out elsewhere I don't think it's necessary though, and it definitely creates a dependency on the compiler that may or may not be acceptable.
I don't believe the VTable can be so simple when you have, i.e. multiple classes implementing different mixtures of common interfaces and inherited methods. All lookups have to work the same across all the different interface implementers.
C++ doesn't have interfaces. The vtables for any given class in at least the common implementations just adds function pointers for every new virtual member function for each subclass.
Since you (in C++) can't cast between "sibling" types and expect it to work, that's enough - each new subclass has a vtable that shares the base with all classes inheriting from the same parent, but adds different sets of new virtual member functions.
In languages with interfaces, or that are more dynamic, you typically have tree common choices:
* Add a dispatch method and call that (really expensive, but extremely flexible)
* Add an indirection and put a pointer to a vtables for each interface in the main vtable (first place I encountered that was in a paper that named it "Protocol Extension" by Michael Franz, who implemented it for Oberon)
* Make the vtable include the superset of all possible methods. My (experimental, incomplete) Ruby compiler does that. It makes the vtables larger, and at some point you'll want to assign some methods to a slower but more compact path, but it works surprisingly well.
reply