v-pointer in a class/object?

[puzzlecracker]

I am kind of confused with the vpointer. Assuming the class has a
virtual function. Would ONE pointer (occupying 16 bits) to virtual
table be create for the class or One for each object? How does this
pointer fit into aligment properties of an object (of the class) or
class itself?

Thanks

 

[red floyd]

I am kind of confused with the vpointer. Assuming the class has a
virtual function. Would ONE pointer (occupying 16 bits) to virtual
table be create for the class or One for each object? How does this
pointer fit into aligment properties of an object (of the class) or
class itself?

An implementation is not required to provide a vptr or a vtbl. Most
implementations use them, but they are not required to.

If your implementation uses vptr, it would be the natural pointer size
for your platform (most likely *NOT* 16 bits), and each object of that
class would have the vptr. There would be one vtbl for each class, and
each object of that class would point to that vtbl.

For details of how a vptr/vtbl model works, see Lippman's "Inside the
C++ Object Model".

 

[puzzlecracker]

An implementation is not required to provide a vptr or a vtbl. Most
implementations use them, but they are not required to.

If your implementation uses vptr, it would be the natural pointer size
for your platform (most likely *NOT* 16 bits), and each object of that
class would have the vptr. There would be one vtbl for each class, and
each object of that class would point to that vtbl.

For details of how a vptr/vtbl model works, see Lippman's "Inside the
C++ Object Model".

Seems like an overhead, to have one pointer per object, that can
possibly be avoided. All object pointers to a specific derived type
have pointer to the same virtual table. Perhaps we can store that
pointer (as static variable or external) that each object of that
derived class can see/use. Is such construct available or can be
simulate it in C++? Agh, it is really a compiler issue.

Thanks

 

[Chris Thomasson]

I am kind of confused with the vpointer. Assuming the class has a
virtual function. Would ONE pointer (occupying 16 bits) to virtual
table be create for the class or One for each object? How does this
pointer fit into aligment properties of an object (of the class) or
class itself?

You can take a look at the following code for an example minimalist
implementation of vtables in C:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/1b106926ba5db19f

This shows the internals of a very-basic abstract interface technique for C.
It might help you understand the that a possible C++ implementation might
use one per-object pointer to a single per-class static/constant vtable...

 

[Chris Thomasson]

I am kind of confused with the vpointer. Assuming the class has a
virtual function. Would ONE pointer (occupying 16 bits) to virtual
table be create for the class or One for each object? How does this
pointer fit into aligment properties of an object (of the class) or
class itself?

For alignment well, it depends on how the implementation sets things up.
Sometimes, the pointer to the vtable is placed directly at the front of the
common data-structure which makes up object's of a particular class. So the
subsequent object will be aligned on at least a boundary sufficient enough
to hold that vtable pointer...

 

[James Kanze]

Seems like an overhead, to have one pointer per object, that can
possibly be avoided. All object pointers to a specific derived type
have pointer to the same virtual table. Perhaps we can store that
pointer (as static variable or external) that each object of that
derived class can see/use. Is such construct available or can be
simulate it in C++? Agh, it is really a compiler issue.

And given a pointer or a reference to the base class, how does
the compiler know which static variable to use? Other solutions
are possible; the compiler could keep a hash map mapping Base*
to vtable*, for example. But they also involve extra memory per
object; more, in fact, than just a single pointer.

The basic problem, of course, is that you do need extra
information, at run-time. And storing extra information means
using extra bits. Globally, using a vptr in the object seems to
be the most efficient solution, both in terms of space and
execution time.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Seems like an overhead, to have one pointer per object, that can
possibly be avoided. All object pointers to a specific derived type
have pointer to the same virtual table. Perhaps we can store that
pointer (as static variable or external) that each object of that
derived class can see/use. Is such construct available or can be
simulate it in C++? Agh, it is really a compiler issue.

How would the object see such a variable? Either by having a pointer to
it (same overhead but one extra indirection) or by storing that
information together with the type. The problem with the second is that
the type then would have to be known at compile-time, in which case you
no longer have run-time polymorphism and not much need for virtual
functions at all.