what is vtable exactly?is it a structure or an array?

[ypjofficial]

Hello All,
I have read in many c++ literature that vtable is nothing but an array
of pointer to virtual functions inside a class.And the class where the
virtual function/s are declared stores the vfptr i.e the pointer to
vtable internally.
What confuses me is
if vtable is an array of pointer to virtual functions then as per the
properties of the array all the entries inside the array must be
same.i.e all the pointers should be of similar type.and this will put
restriction on the declaration of the virtual functions as they must
have same singnature as per my point.

eg. class base
{
public:
virtual void fun(int,int);
virutal int fun2(char);
};
now according to the definition of vtable(i.e array of pointers to
virtual functions)
what will be the syntax for the array? as single array can't hold
entries with different datatypes.
the pointer to first virtual function is something like
void (base::*fptr1)(int,int) and for second its like
int (base::*fptr2)(char)
how come a single array like vtable will stored these two totally
different entires?

but a structure can stores mulitple datatypes.
So is Vtable a structure or an array? if its array then can anyone give
me its definition?

Thanks and regards,
Yogesh Joshi


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Neelesh Bodas]

Hello All,
What confuses me is
if vtable is an array of pointer to virtual functions then as per the
properties of the array all the entries inside the array must be
same.i.e all the pointers should be of similar type.and this will put
restriction on the declaration of the virtual functions as they must
have same singnature as per my point.

1. C++ std doesnot say anything about implementation of virtual
functions. The compilers are free to implement it by any (correct)
mechanism. (However, practically majority of the (or is it 'all' ? )
compilers that exist today implement virtual functions using vtable
mechanism.)

2. The type restrictions that you are talking about exist for a
programmer when he wants to write a C++ code which will get
type-checked during compilation. Such restrictions donot exist for the
compiler. Specifically, the compiler doesnot generate a C++ code
corresponding to array of function pointers - it simply spits out the
assembly code corresponding to indexing into an array of addessses. So
the issues of type-checking donot really come in the picture.

Of couse, I have not really seen the implemenation and so I might not
be accurate. Comments are welcome.

 

[Luke Meyers]

I have read in many c++ literature that vtable is nothing but an array
of pointer to virtual functions inside a class.And the class where the
virtual function/s are declared stores the vfptr i.e the pointer to
vtable internally.

Not to give you yet another piece of C++ literature to reference, but I
found Stroustrup's explanation in "The Design and Evolution of C++"
pretty straightforward.

What confuses me is
if vtable is an array of pointer to virtual functions then as per the
properties of the array all the entries inside the array must be
same.i.e all the pointers should be of similar type.and this will put
restriction on the declaration of the virtual functions as they must
have same singnature as per my point.

but a structure can stores mulitple datatypes.
So is Vtable a structure or an array? if its array then can anyone give
me its definition?

I think you're getting confused because you're trying to carry over
rules about the C++ language to the domain of compiler implementation
and runtime architecture. The vtable is an area in memory. Call it an
array if you want. C++ doesn't let you allocate heterogeneous arrays
directly, but you can always get around this if you really want to.
Just allocate a chunk of memory, manage your pointers very carefully,
cast if ya gotta, and you really have complete control. But "you" in
this case is the compiler implementor, who may or may not even be using
C++.

The point is, it's implementation-defined. All that's required is that
some mechanism be provided that supports the virtualization behaviour
required in the standard. And that's all you should count on, or worry
about, unless you have a reason to delve into compiler internals or the
like.

Luke


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Earl Purple]

Hello All,
I have read in many c++ literature that vtable is nothing but an array
of pointer to virtual functions inside a class.And the class where the
virtual function/s are declared stores the vfptr i.e the pointer to
vtable internally.

The v-table is beyond C++. You cannot access it directly, or get a
pointer to a v-table.

The writers of the compiler may well implement it the same way they
implement an array of function pointers and the C++ literature that
indicates as such may either be aimed at compiler-writers or may be
illustrating how one could simulate a v-table (eg if coding in another
language such as C).


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Neelesh Bodas]

Hello All,
What confuses me is
if vtable is an array of pointer to virtual functions then as per the
properties of the array all the entries inside the array must be
same.i.e all the pointers should be of similar type.and this will put
restriction on the declaration of the virtual functions as they must
have same singnature as per my point.

1. C++ std doesnot say anything about implementation of virtual
functions. The compilers are free to implement it by any (correct)
mechanism. (However, practically majority of the (or is it 'all' ? )
compilers that exist today implement virtual functions using vtable
mechanism.)

2. The type restrictions that you are talking about exist for a
programmer when he wants to write a C++ code which will get
type-checked during compilation. Such restrictions donot exist for the
compiler. Specifically, the compiler doesnot generate a C++ code
corresponding to array of function pointers - it simply spits out the
assembly code corresponding to indexing into an array of addessses. So
the issues of type-checking donot really come in the picture.

Of couse, I have not really seen the implemenation and so I might not
be accurate. Comments are welcome.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Michiel.Salters]

1. C++ std doesnot say anything about implementation of virtual
functions. The compilers are free to implement it by any (correct)
mechanism. (However, practically majority of the (or is it 'all' ? )
compilers that exist today implement virtual functions using vtable
mechanism.)

2. The type restrictions that you are talking about exist for a
programmer when he wants to write a C++ code which will get
type-checked during compilation. Such restrictions donot exist for the
compiler. Specifically, the compiler doesnot generate a C++ code
corresponding to array of function pointers - it simply spits out the
assembly code corresponding to indexing into an array of addessses. So
the issues of type-checking donot really come in the picture.

Except when it spits out something else, of course. The main reason for
that is pointer adjustment. Calling a Base method with a Derived* is
legal
but in assembly you might need to add or subtract a few bytes to get
the Base* needed. This is worse when Base is a virtual base class.
These
adjustments typically end up in the vtable as well (since it's already
in
the CPU cache at this point, or is needed very soon)

A good compiler might also spit out a few guard entries at the end, so
that
any (forced) attempt to use a Derived method with a Base* is caught.
And
of course many compilers use similar stubs to deal with pure virtual
functions, so a call from the ctor fails predictably.

A compiler also can mix different pointer sizes. It only needs to map
virtual void foo() to a byte offset in the vtable.If there's a 32-bit
pointer
and a 64-bit pointer in there, it'll probably use offset 6. Arrays
don't work
that way

HTH,
Michiel Salters

 

[kanze]

I have read in many c++ literature that vtable is nothing but
an array of pointer to virtual functions inside a class. And
the class where the virtual function/s are declared stores the
vfptr i.e the pointer to vtable internally.

What confuses me is if vtable is an array of pointer to
virtual functions then as per the properties of the array all
the entries inside the array must be same. i.e all the
pointers should be of similar type.and this will put
restriction on the declaration of the virtual functions as
they must have same singnature as per my point.

The vtable (or vtbl) is part of what the compiler generates, and
not a C++ structure. On most machines, at the hardware level, a
pointer is a pointer, regardless of what it points to. And the
vtable is an array of these banalized pointers -- in a modern
implementation, typically one of the entries will not point to a
function at all, but to the data structures used for RTTI
(typeid and dynamic_cast). When a document says that the vtable
is an array of pointers to the virtual functions, it doesn't
mean that this is the type of the array, as in C++; it simply
means that (most of) the actual banalized pointers in the array
happen to point to the virtual functions.

If the C++ compiler is generating C code, then it has two
alternatives: it can generate a struct for each class, and use
that, or it can generate code as if it were an array of some
generic function pointer type, e.g. void (*)(), and cast as
needed.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[mlimber]

So is Vtable a structure or an array?

[snip]

The short answer: MYOB. It's implementation defined and not explicitly
accessible to your C++ program. See this FAQ (and the preceding one)
for some details:

http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4

Cheers! --M


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Dudle.June]

every pointers has exactly same size
a pointer array usually has a type of void *
it can contain every kind of pointers
so ...


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Meador Inge]

The v-table is beyond C++. You cannot access it directly, or get a
pointer to a v-table.

That is not 100% true. One could figure out how a particular compiler
implements the v-table and access it using various casts and pointer
arithmetic. Not that I would suggest doing such a thing, but it is
possible nonetheless.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[JustBoo]

That is not 100% true. One could figure out how a particular compiler
implements the v-table and access it using various casts and pointer
arithmetic. Not that I would suggest doing such a thing, but it is
possible nonetheless.

That is how Microsoft COM works. It "walks" the vtable. IIRC COM is an
external process so it has to get hold of the vtable just like any
programmer would have to. It helps a great deal to know how this
mechanism works.

To the OP, ignore people who tell you to "MYOB" or it's out of your
control so don't bother. People like that, regardless of their title
and/or education, are NOT engineers, software or otherwise.

Not all those who wander are lost. - J.R.R. Tolkien

 

[mlimber]

That is how Microsoft COM works. It "walks" the vtable. IIRC COM is an
external process so it has to get hold of the vtable just like any
programmer would have to. It helps a great deal to know how this
mechanism works.

To the OP, ignore people who tell you to "MYOB" or it's out of your
control so don't bother. People like that, regardless of their title
and/or education, are NOT engineers, software or otherwise.

In my response, I wrote:

"The short answer: MYOB. It's implementation defined and not explicitly
accessible to your C++ program. See this FAQ (and the preceding one)
for some details:
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4"

Since your comments are at least directed at me, please allow me to
respond.

The "MYOB" in my response was half joking. Of course, in some
relatively rare scenarios it might be necessary to figure out how a
compiler implements virtual functions and make use of that information
(n.b., compilers aren't required to use vtables at all and can
implement virtual functions with some other mechanism). However, as I
said, the language does not make that information *explicitly*
available to the user, and so the user *must* do some
platform-dependent pointer manipulation to figure out where the vtable
is and how to use it (assuming it exists at all!).

Therefore, since this newsgroup is exclusively concerned with
*standard* C++ language and libraries
(http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9), such
manipulations are, according to the FAQ, off-topic here and should be
taken to a more specific newsgroup that can treat them more adequately.

As far as implementing COM, Microsoft is free to make use of
non-standard information because it also controls the compiler. Another
company creating a COM-esque technology for some third-party
compiler(s) might pull the same sort of non-standard tricks, only to
find out on the next release of their compiler(s) that their tricks for
manipulating the vtable no longer work. That is because they used a
non-standard implementation detail from one version of their compiler
that the Standard allows the compiler vendor to change at will without
becoming non-conformant.

Finally, with regard to the aspersions and calumnies cast about in your
last sentence, I would humbly recommend that you dismount from your
elevated equine.

Cheers! --M

 

[Martin Bonner]

every pointers has exactly same size

Not true in general.
a) On word addressed machines, void* and (unsigned) char * are longer
than other pointers because they contain the offset within the word.
b) In segmented architectures (like 16-bit Intel) it was quite common
for pointers to data and pointers to functions to be different lengths.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Francis Glassborow]

every pointers has exactly same size
a pointer array usually has a type of void *
it can contain every kind of pointers
so ...

Actually your premise is false. Pointers to different types are not
required to be the same size. In addition a void* is not a correct
pointer type for a function pointer. When all is said and done compilers
implement late binding by creating internal tables of addresses, one per
class in a polymorphic hierarchy. The compler ensures that the same
function signature is applicable to the same slot in each of the tables.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[william.wu1982]

May anyone tell me what exactly the pointer is ?


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Mike Wahler]

May anyone tell me what exactly the pointer is ?

Which pointer? If you really meant to ask, what *a* pointer is,
it's an obect or value which represents a memory address.

-Mike

 

[Michiel.Salters]

May anyone tell me what exactly the pointer is ?

No. We can't. It depends on a lot of factors, and we don't have a
crystal ball.
In fact, the next time you compile the profiler-optimizer may decide
not to
use a pointer at all.

HTH,
Michiel Salters


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[ypjofficial]

Hello All,

Thanks for all your help.
This discussion really help me understand the concept of the virtual
functions mechanisms.

Actually the reason behind asking this question is exactly what JustBoo
pointed out.I was loooking for interoperatibily behind the c++ and C
when using the COM objects and how to access c++ vfptr from C..

I really appreciate all your help and guidance..
Hoping to get more help from this community in future..

Thanks and Regards,
Yogesh Joshi