Talk:Virtual method table

message: 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)
replies: text: I have changed the title to "virtual method table". --Knorxx 12:06, 3 October 2005 (UTC)
thread_title:  Title 

message: 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)
replies: text: 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)
replies: text: Changed examples to reflect g++/gcc behaviour. Could someone please verify? --isbor 07:31, 8 July 2006 (UTC)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Example 

message: 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)
thread_title: Rewrite

message: 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()
A problem in the Multiple inheritance and thunks section is that I don't believe you can dynamic_cast from a base class to a derived class due to the type-safety checking that dynamic_cast performs.  This should probably be changed to static_cast, which does not do such checking and therefore allows potentially dangerous casts in that direction that could result in unfinished objects. Skijmpr (talk) 18:53, 30 October 2008 (UTC)
thread_title: Errors

message: In the memory layout for the object b2, it has been shown that destructor of the class B2 exists in the VTABLE. But, in the B2 class declaration, no destructor is defined. Is the compiler generated destructor virtual by default?
Gowthamgowthamgowtham 15:33, 18 August 2007 (UTC)
thread_title:  Question 

message: How is runtime binding implemented in Java-land? Thanks. 83.67.217.254 19:16, 26 August 2007 (UTC)
thread_title:  How about Java? 

message: This article badly needs illustrative images to explain the things that is hard to explain in text.
If anybody can provide such images/find the proper way of requesting them, please do.--Henke37 21:11, 16 September 2007 (UTC)
thread_title:  Lack of charts 

message: I think that a comparison with Objective-C would be nice since both it and C++ are extensions to C (and the dynamic nature of Obj-C is directly applicable to a discussion of v-tables in C++).  —Preceding unsigned comment added by 131.107.0.73 (talk) 19:42, 31 October 2007 (UTC)
thread_title:  Comparison with Objective-C 

message: No illustrations or pictures? Hope someone to draw some pictures to help us understand better! 221.239.34.194 (talk) 04:43, 2 August 2008 (UTC)
thread_title: No Illustrations? BAD...

message: I am not satisfied with reference [2]. It is outdated, predates any optimizing compiler, and is based on simulations on a fictuous processor (the P96). Also, it is likely that, except for trivial functions, the cost of an indirect call on a REAL processor is negligible compared to the evaluation of the arguments and to what the function actually does. This obsolete (and bad) reference only helps during myths about c++ performance.  —Preceding unsigned comment added by 69.90.176.110 (talk) 12:07, 15 October 2008 (UTC)
thread_title:  Bad reference 

message: I want to express, the introduction (cat/speak/meow/roar) is really great. This has helped me understand the matter for the first time. --ThorstenStaerk (talk) 08:35, 21 July 2009 (UTC)
thread_title:  Introduction 

message: What on earth does the following mean? "When an object is created, a pointer to this vtable, called the virtual table pointer or vpointer, is added as a hidden member of this object (becoming its first member unless it's made the last[2])." The parenthetical remark seems to be saying that "Something is X, unless, of course, it isn't." Which conveys nothing. What is really meant here?  —Preceding unsigned comment added by 173.50.151.91 (talk) 22:27, 30 September 2009 (UTC)
thread_title:  Unclear wording 

message: Currently, this article states the following
:A virtual method table, virtual function table, dispatch table, or vtable, is a mechanism used in a programming language to support dynamic dispatch (or run-time method binding).
Is dynamic dispatch the same as run-time method binding? Or does this statement want to point out that vtables are used for different purposes? --Abdull (talk) 20:55, 1 October 2010 (UTC)
thread_title:  ''dynamic dispatch'' == ''run-time method binding''? 

message: A virtual call requires at least an extra indexed dereference, and sometimes a "fixup" addition, compared to a non-virtual call, which is simply a jump to a compiled-in pointer. It's not precise as it's suggests the pointer fixup is a disadvantage of virtual functions compared to non-virtual ones. But even if you call a "normal" function you may need the pointer fixup simply to provide the method with the memory layout it knows so it is able to access the correct fields. The vpointer is just one of possible fields it may need to access. An example:
#include <iostream>
class A1
{
public:
	void* a1() { return this; }
	int value_a1; 
};
class A2
{
public:
	void* a2() { return this; }
	int value_a2;
};
class B : public A1, public A2
{
};
int main()
{
	B b;
	std::cout << "this in a1(): " << b.a1() << "\nthis in a2(): " << b.a2() << std::endl;
}
No virtual functions here, no overridden functions even, but if you compile and run it (tested with g++ 4.4.5) the "thises" displayed will differ (unless you remove the fields, then no fixup is needed). I think this sentence and possibly the ending of the previous section need to be edited. Lampak (talk) 22:55, 6 February 2011 (UTC)
thread_title:  Pointer fixup is not a virtual thing 

message: In the section Invocation, the information about how the correct vtable is located is omitted. This information is central to the topic and should be added the the article! If anyone know this, please improve the article by expanding it on this point!
That is, how is pointer value at the position marked with "/*pointer to virtual method table of D (for B1)*/" computed? 
This requires something similar to a hash map lookup, right? (Which can be optimised in a lot of cases of course.)
Liiiii (talk) 15:16, 4 August 2014 (UTC)
thread_title:  Locating the correct vtable?