Thread: Vtables and Virtuals

Do you really have to know or care about the vtable and how it works when none of that knowledge actually helps you write well structured object-oriented C++? Once you learn how the Microsoft vtable works then you have to learn how the <insert_compiler_dev> vtable works. The best way to visualize the vtable in MS compilers is to put a watch on a class instance and dig down into the resulting tree of 'stuff'.

The important part here is that you understand the concept of polymorphism and the power and flexibility that it offers.

Originally Posted by brewbuck

I think maybe the confusion is that he's thinking "Well, stupid compiler, can't it SEE that the thing is a Derived even though it's being pointed to by a Base *?" Yes, it can see that... And it might even forgo the virtual call in that case... But in most cases the compiler CANNOT see that.

Here, maybe this will hammer it in:

Code:

int main()
{
    Base *b;

    if (rand() % 2 == 0)
        b = new Base();
    else
        b = new Derived();

    b->Print();
}

Okay, NOW the compiler CANNOT possibly know the type of the object -- I'm determining it RANDOMLY. In THIS case how is the compiler supposed to know what type the object is?

mmn...you're right on that one. And yeah, I get the point now...
actually the if statement kinda did it...
thanks TStop and BBuck, appreciate it .

Originally Posted by Bubba

Do you really have to know or care about the vtable and how it works when none of that knowledge actually helps you write well structured object-oriented C++? Once you learn how the Microsoft vtable works then you have to learn how the <insert_compiler_dev> vtable works. The best way to visualize the vtable in MS compilers is to put a watch on a class instance and dig down into the resulting tree of 'stuff'.

The important part here is that you understand the concept of polymorphism and the power and flexibility that it offers.

yeah, I have to or I won't have peace of mind...
but I heard that they ask in this interviews.....

Originally Posted by brewbuck

I think maybe the confusion is that he's thinking "Well, stupid compiler, can't it SEE that the thing is a Derived even though it's being pointed to by a Base *?" Yes, it can see that... And it might even forgo the virtual call in that case... But in most cases the compiler CANNOT see that.

Here, maybe this will hammer it in:

Code:

int main()
{
    Base *b;

    if (rand() % 2 == 0)
        b = new Base();
    else
        b = new Derived();

    b->Print();
}

Okay, NOW the compiler CANNOT possibly know the type of the object -- I'm determining it RANDOMLY. In THIS case how is the compiler supposed to know what type the object is?

Actually..maybe I don't understand it yet..not fully anyways (I'm close though)

the book here says...at execution
the pointer Base* is dereferenced to get to the object...then from the object it goes to vtable..and from the vtable to the function pointer.
The book described it as triple indirection...
but the question is..if Base * is dereferenced to get to the object it points to...is it not clear enough which function to call?

Originally Posted by tabstop

Not yet. Not until the run-time system actually examines that object (whether via vtable or otherwise) to determine what type of object it is. Dereferencing the pointer merely gives you the physical location of the object, not what kind of thing it is.

oh right..great thanks! I guess it was that close.
Now to attempt some questions and move on to Templates :'(

Thanks a lot friends .