VPTR and VTABLE

[doublemaster007]

Hi..

Every class which has a virtual function has Vtable, and every object
of it has vptr..Does that mean..
For class it will be annotated to static array of pointers [vtbl] and
a non static pointer (vptr) which points this vtbl..

Am i talking right?

 

[Victor Bazarov]

Hi..

Every class which has a virtual function has Vtable,

That's a common implementation of virtual functions nowadays. It is not
mandated nor is it guaranteed by the Standard.

> and every object
of it has vptr..Does that mean..
For class it will be annotated
"Annotated"?

> to static array of pointers [vtbl] and
a non static pointer (vptr) which points this vtbl..

Am i talking right?

Uh... What are you trying to say? Perhaps you should just draw a
picture...

A good explanation of how this works is given in "Inside the C++ Object
Model" by Stanley Lippman (IIRC).

V

 

[Maxim Yegorushkin]

That's a common implementation of virtual functions nowadays. It is not
mandated nor is it guaranteed by the Standard.

Is there any different implementation?

 

[Victor Bazarov]

Is there any different implementation?

I don't know of any. But the absence of proof is not the proof of absence.

V

 

[robertwessel2]

Is there any different implementation?

Even if no implementation uses a different mechanism than the
traditional vtable, small (virtual) classes can often be entirely
inlined in the right circumstances (obviously where the type is known
by some analysis of the flow graph), and the vtable (and perhaps much
else) can be omitted. So at best there's a vtable for a virtual
class, unless some compiler uses some other scheme, or a compiler
decides it can omit it for other reasons. IOW, don’t count on it.

 

[Maxim Yegorushkin]

Even if no implementation uses a different mechanism than the
traditional vtable, small (virtual) classes can often be entirely
inlined in the right circumstances (obviously where the type is known
by some analysis of the flow graph), and the vtable (and perhaps much
else) can be omitted. So at best there's a vtable for a virtual
class, unless some compiler uses some other scheme, or a compiler
decides it can omit it for other reasons. IOW, don’t count on it.

True. However, this is a general optimization which could be applied to
pretty much arbitrary objects and members. Not specific to virtual
functions and vtables.

 

[Maxim Yegorushkin]

I don't know of any. But the absence of proof is not the proof of absence.

I wonder how they came up with this implementation.

Probably, they thought it would be nice to have (run-time) polymorphism
like in other popular OO languages at that time, like Smalltalk. So, the
next question could probably have been how it was currently done in C.
Well, in C it is a common pattern to declare a structure of function
pointers (vtable concept) and have a pointer to such a structure in an
object (vtable pointer concept). The would be one instance of that
structure for every different object type. Next, they probably thought
that it would be nice if the compiler could generate these function
pointer structures and stick the pointer into object automatically. To
do so there needed to be a way to let the compiler know that a (member)
function needed to be in that structure. One straightforward way was to
mark/annotate that function with a keyword, like sticking a virtual in
front of the function declaration. This could have been how virtual
keyword for functions came about. They did that and they saw that it was
good. And then they forgot to document that in the standard so that
people would guessing in the newsgroups till the end of times, and there
would be one more item on the list when defining a C++ ABI

 

[doublemaster007]

Hi..

Every class which has a virtual function has Vtable,

That's a common implementation of virtual functions nowadays.  It is not
mandated nor is it guaranteed by the Standard.

 > and every object

of it has vptr..Does that mean..
For class it will be annotated

"Annotated"?

 > to static array of pointers [vtbl] and

a non static pointer (vptr) which points this vtbl..

Am i talking right?

Uh...  What are you trying to say?  Perhaps you should just draw a
picture...

I just wanted to know the types of vtbl and vptr..to know whatever i
have understood is correect.
So could you pls tell me the types of vptr and vtbl.

As per my understanding vtbl is static array of function pointer
[static because its in class level]
vptr is non static pointer [since every object has its copy]

A good explanation of how this works is given in "Inside the C++ Object
Model" by Stanley Lippman (IIRC).

After reading this book only i got this doubt...

 

[Victor Bazarov]

[..]
As per my understanding vtbl is static array of function pointer
[static because its in class level]
vptr is non static pointer [since every object has its copy]

Well, this is basically correct. Except that neither vtbl, nor vptr are
visible to the user of the class (or even the class itself) through the
language means. There is no portable way to say 'MyClass::__vtbl' and
get the [pointer to the] array, or 'MyClassInstance.__vptr' and get the
local copy of the actual virtual function table pointer. [Note: the
syntax is made up to illustrate the point]

V

 

[James Kanze]

[..]
As per my understanding vtbl is static array of function pointer
[static because its in class level]
vptr is non static pointer [since every object has its copy]

Well, this is basically correct. Except that neither vtbl,
nor vptr are visible to the user of the class (or even the
class itself) through the language means. There is no
portable way to say 'MyClass::__vtbl' and get the [pointer to
the] array, or 'MyClassInstance.__vptr' and get the local copy
of the actual virtual function table pointer. [Note: the
syntax is made up to illustrate the point]

More to the point, they may not have a type which can be
expressed in C or C++. All you can really say is that the vptr
points to some class specific meta information (called the
vtable or vtbl) and that this meta information includes all the
information necessary for virtual function calls and
RTTI---considerably more, in fact, than just pointers to
functions. (The names, and the idea that the vtbl is just a
table of pointers to functions, come from the earliest versions
of CFront: before multiple inheritance and RTTI were introduced
to the language, the vtbl was just a table of pointers to
functions, and CFront used C as its intermediate language, and
in this generated C, the names were __vptr and
__vtbl__classname, or something like that.)