Talk:Virtual method table

From Wikipedia, the free encyclopedia

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)

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

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)

[edit] 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)

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)

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

Thanks for adding the examples. By the way, I don't think it was necessary to replace the VC8 version with gcc3; I just suggested gcc4 because it's one compiler that I knew for sure doesn't do things the old way. They both seem to do things essentially the same way (is VC8 optimizing out D::B1's f2 because it can never be called virtually except through a B2?), so either one makes the point equally well. (And thanks for making me take a look at how VC8 does it--otherwise, it might have been a while before I noticed how much better the debugger has gotten for exploring vtables, rtti and exception stuff, etc.) Falcotron 20:05, 11 July 2006 (UTC)

I opted for gcc because I think referencing to free software would be better, especially in a free encyclopedia ;) --isbor 18:00, 14 July 2006 (UTC)

One thing: The functions are called b1 and b2 in the code, f1 and f2 in the layout. I'll fix that. Falcotron 20:05, 11 July 2006 (UTC)

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)

[edit] Rewrite

Inspired by isbor's new examples and explanations, I reorganized the page, rewrote chunks of it, and expanded various parts. Hopefully most of what I added or changed is both correct (although someone should look it over and make sure I got the right number of *'s in the pseudocode and so forth), readable (again, someone check), and non-controversial. There are a few things I wanted to point out specifically:

• I removed the "see also" link to virtual inheritance, because vtables have nothing to do with virtual inheritance in particular (as opposed to single inheritance or non-virtual multiple inheritance).

• The last two paragraphs may be too combative (in which direction?) or too wishy-washy. Or maybe both. Clearly the vtable is an intentional compromise; it gets part of Smalltalk's dynamism for much less cost, using a very C-hacker-style design. But without quoting D&E extensively (and explaining why Java and D have kept essentially the same tradeoff), I'm not sure how to get this across. Falcotron 00:11, 12 July 2006 (UTC)

[edit] Errors

some of your examples have minor errors. for example

*((d->"pointer to virtual method table of D (for B1)")[12])(d)

you say this is supposed to call B1::f1() but in reality it calls D::f2()