Talk:Virtual method table

I am not satisfied with this article. While it is technically correct, I think it could be worded better. Anyone out there want to try editing it? John 17:42, Sep 21, 2004 (UTC)

I am not satisfied with the title "virtual table". The table itself is not virtual. I suggest to move this article to "virtual method table", or may be to "virtual-method table". --Knorxx 11:28, 18 September 2005 (UTC)[reply]

I have changed the title to "virtual method table". --Knorxx 12:06, 3 October 2005 (UTC)[reply]

In fact "virtual method table" itself is bound too closely to C++, I suggest it be referenced simply as a "method table". Methods are after all polymorphic.

I agree with the unsigned comment. Also, it's misleading to say that compiled languages have to use vtables; even C++ can be implemented in other ways. And it's worth discussing the tradeoffs--you get efficiency and simple representation for SI, but extra complexity for MI, double-sized pointers-to-methods, no multimethods, etc. References to D&E, the history of cfront, Lippman's book, etc. might be useful. Falcotron 06:43, 7 June 2006 (UTC)[reply]

Example

The example takes a lot of space to show only a fraction of the useful information. There's no reason to use a deep hierarchy with 9 methods.

Without a vtable for one of the base classes (a subset of the derived vtables), it's not clear why a DES object can be used as a SymmetricAlgorithm. It also means there's no demonstration of how abstract methods are implemented (.long 0, which explains the "= 0" syntax hack).

Listing Clear in the vtable without including the declaration of it as a virtual function (presumably in Algorithm) is potentially confusing. And type_info probably shouldn't be shown without at least some explanation.

It needs to be clear that this is how a particular C++ compiler implements vtables (and which one?), and that the standard doesn't even require vtables at all.

Also, there should be some indication of how the compiler and runtime find the vtable for an object--a hidden vptr as the first member of the class (most compilers), a vptr at the end of the class and size tracking (old Apple MPW?), a pointer/offset combination (cfront 3?), or any other possibilities that I don't recall).

Finally, all of the tricky/interesting stuff has to do with multiple inheritance, and that isn't even hinted at here.

Demonstrating a dynamic cross-cast in a simple 3-class MI hierarchy in gcc 4 and in cfront 3 would cover all of these issues, without any confusion, in (probably) less space. Falcotron 06:35, 7 June 2006 (UTC)[reply]

Changed the examples. However, I have only been able to give examples based on the Microsoft C++ compiler. Will change/add examples to reflect gcc later. --isbor 16:38, 7 July 2006 (UTC)[reply]

Changed examples to reflect g++/gcc behaviour. Could someone please verify? --isbor 07:31, 8 July 2006 (UTC)[reply]

See [C++ ABI for IA-64: Code and Implementation Examples] for a good discussion of some of the issues in designing a vtable implementation. Falcotron 08:57, 7 June 2006 (UTC)[reply]