Doubts regarding vtable and vpointer

Question

0.00/5 (No votes)

See more:

Hello Friends,

can you please help me in understanding vtable and vptr.

<a href="http://www.learncpp.com/cpp-tutorial/125-the-virtual-table/">http://www.learncpp.com/cpp-tutorial/125-the-virtual-table/</a>[<a href="http://www.learncpp.com/cpp-tutorial/125-the-virtual-table/" target="_blank" title="New Window">^</a>]

I found above link pretty useful but few doubts

1)if i have code as follwos how many vtable will be created

C++

class base
{
public:
    virtual void display()
    {
        cout<<"i am in base";
    }
};
class derieved :public base
{
public:
    void display()
    {
        cout<<"i am in derieved";
    }
}

2)How vptr will be placed with class object(memory layout)

3)if there are 5 object created then how they will be linked with vtable and vpointer

Best Regards,
Vikas Mishra

Posted 20-Aug-12 5:05am

tasumisra

Updated 20-Aug-12 5:33am

Wes Aday

v2

Add a Solution

3 solutions

Solution 2

Just to add one more interesting thing. Visual studio debugger can show the virtual functions associated with objects. when you add object in to watch you can see an item with name __vfptr it will contains the address of table (also with a name like class::vftable something like that)

jkchan
http://cgmath.blogspot.com[^]

Posted 20-Aug-12 18:12pm

jk chan

Solution 3

Thank you so much Guys for this great explanation...I will initiate one more topic with object slicing with Virtual function.

Posted 20-Aug-12 19:06pm

tasumisra

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

nv3 · Accepted Answer · 2012-08-20T06:03:00

Solution 1

Objects of both classes, base and derived, will in most implementation have a vtable pointer at the very start of the object's memory. (Although that is implementation dependent and not guaranteed by the C++ standard).

The vtable pointer of a base object points to base's vtable. This vtable will contain a pointer to base::display.

The vtable pointer of a derived object points to derived's vtable. This vtable will contain a pointer to derived::display in the slot, in which bases's vtable contains a pointer to base::display.

You can create any amount of objects of a class and they all contain a pointer to the same vtable, as there is only one vtable per class.

Thinks get considerably more complicated when using multiple inheritance, but at least in this example things are still relatively simple.

Hope that helps.

Posted 20-Aug-12 6:03am

nv3

Comments

pasztorpisti 20-Aug-12 13:24pm

5ed, and adding some more for the OP: when you inherit from multiple classes you object can have multiple vtable pointers, don't wanna know how because it isn't useful and can be compiler specific. With single line inheritance the vtable pointer is always at the beginning of your object - windows COM builds upon this heavily. Some more about how the vtable pointer gets to the beginning of your object: I will use your code as an example with your "base" and "derived" classes. When you create an instance of your derived class, the order of constructor calls is done starting from the base classes to the most derived classes. when the constructor of your base class is called, the beginning of the constructor contains a piece of automatically generated code that fills out the vtable pointer of your object to point to the vtable of the base class, then your code in the base constructor is executed. After this the constructor of derived is executed. The very beginning of the dervied constructor also contains automatically generated code that changes the vtable pointer from the base vtable pointer to the derived vtable pointer, after this your code in the derived constructor is executed. Warning!!! When the base constructor is executed the vtable pointer points to the base vtable and not to the derived vtable. why??? Because it makes no sense to call a virtual function in your derived class before the derived constructor is executed, a derived virtual method might want to use derived calss members that will be initialized only later in the derived constructor!!! For this simple reason if you call a virtual method form the base constructor it will execute the implementation that you have written in your base class even if you have overridden it in your derived class!!! calling a pure virtual method from the base class will cause compile error, but: if you pass the this pointer from your base constructor for example to a static global function somewhere in your code, that other function can call the pure virtual methods of the base class and at this time that causes a "pure virtual function call" runtime error!!! because you called the pure virtual method of a half-constructed object. My advice: never call virtual functions from construcotors!!! The same is true for destrucotrs for the very same reason!!!

EDIT: As you might noticed, using the vtable in the base class is dangerous and you might not want to use it at all. If you don't want to use it, then it has no point to fill it out because the derived constructor will do the job later. For this reason there is a __declspec(novtable) in VC++ that can be used to turn off vtable pointer initialization in abstract base classes when you are serious about optimization.

Sergey Alexandrovich Kryukov 20-Aug-12 13:38pm

I 5ed it, too, but, if I'm not much mistaken, such layout is only possible when there is no multiple inheritance...
Good notes, by the way.
--SA

pasztorpisti 20-Aug-12 14:10pm

A single inheritance is the building block of multiple inheritance, the sub objects of a complex class are built up similarly. The only exception is virtual inheritance where its not clear which derived class should initialize the virtual part of the object. In that case each owner has a pointer to the virtual part and there is a flag that indicates whether the virtual part has already been initialized or not coz every sub objects tries to initialize it at some point. What happens when multiple subobjects with a common virtual base override different (or maybe the same) virtual methods of a virtual base... Good question! Maybe a compile time error or compiler crash... :-) But in general I'm against virtual inheritance, in my opinion its avoidable and I recommend avoiding it!

I didnt remember how virtual base classes are initialized: http://msdn.microsoft.com/en-us/library/38tx22fy.aspx
But still dont know what happens when we mix in virtual function overrides in the derived subclasses.

Sergey Alexandrovich Kryukov 20-Aug-12 15:45pm

Here is the thing: I remember that when we discovered C++ vtable in order to better implement weak form of multiple inheritance (to implement interface implementations in a smart way), we found that in multiple inheritance, the pointers to the same object as the pointers of different base types, physically point to different point withing the same vtable. After discussion, we came to the conclusion that such situation is unavoidable with multiple inheritance, and not the case with single inheritance. By the way, it means that proper type cast in multiple inheritance actually shifts the pointer accordingly. Come to think about, it looks pretty logical. Interesting, isn't it.

To make it more interesting, one my friend, experimental physicist, never worked as a professional developer (I think because he programs my better then they :-), analyzed that multiple inheritance mechanism and found it very inflexible (nothing new so far). He invented an alternative method based on one extra level of indirection (in general case, two tables instead of one vtable) and argued that the performance toll is insignificant next to the benefit. One of the benefits looks like that: in multiple inheritance, the inheritance can be virtual or not, but this is defined in some base class and cannot be changed later, by subclassing. In hist approach, declaring of the inheritance as virtual or not is itself a subject of late binding; that is, it is decided at the point where a derived class is created and can be changed back and forth in further inheritance. Who can bit that? In my view, this is certainly one way of going out of one of multiple-inheritance dead ends...

--SA

Sergey Alexandrovich Kryukov 20-Aug-12 15:45pm

Here is the thing: I remember that when we discovered C++ vtable in order to better implement weak form of multiple inheritance (to implement interface implementations in a smart way), we found that in multiple inheritance, the pointers to the same object as the pointers of different base types, physically point to different point withing the same vtable. After discussion, we came to the conclusion that such situation is unavoidable with multiple inheritance, and not the case with single inheritance. By the way, it means that proper type cast in multiple inheritance actually shifts the pointer accordingly. Come to think about, it looks pretty logical. Interesting, isn't it?

To make it more interesting, one my friend, experimental physicist, never worked as a professional developer (I think because he programs my better then they :-), analyzed that multiple inheritance mechanism and found it very inflexible (nothing new so far). He invented an alternative method based on one extra level of indirection (in general case, two tables instead of one vtable) and argued that the performance toll is insignificant next to the benefit. One of the benefits looks like that: in multiple inheritance, the inheritance can be virtual or not, but this is defined in some base class and cannot be changed later, by subclassing. In hist approach, declaring of the inheritance as virtual or not is itself a subject of late binding; that is, it is decided at the point where a derived class is created and can be changed back and forth in further inheritance. Who can bit that? In my view, this is certainly one way of going out of one of multiple-inheritance dead ends...

--SA

pasztorpisti 20-Aug-12 16:09pm

I got the pointer shift to the subobject while casting, but why do the subobject vtables have to point into the middle of a bigger table? Who is the owner of the bigger table? What is it used for?

Sergey Alexandrovich Kryukov 20-Aug-12 16:40pm

I'm sure I could explain it, but it needs some thinking... :-)
--SA

pasztorpisti 20-Aug-12 16:58pm

I think the handling of vtables in case of multiple inheritance can be compiler dependent. I remember that I checked the assembly for one scenario in visual studio and it looked like this: I had 2 base classes A and B, both of these having many virtual functions, to make things more interesting I had a virtaul method in both A and B with the same signature that can be overridden by a single method in a derived class. C inherited both A and B, overridden some virtual methods of each class and also introduced a few more virtual methods. In binary it looked like this: C had 2 vtables pointers, one for A, and one for B. The virtual methods introduced in C were just appended to the vtable of A like in single line inheritance. The constructor of C replaced both vtable pointer during construction, the vtable of A was replaced to the extended version of course that contains the newly introduced virtual methods of C. But these 2 tables dont have to be merged. I still dont understand when is it needed to use a merged table. Or maybe you used a different compiler that solved the problem differently. This is a problem that can be solved in different ways.

BTW: An interesting thing came to my mind regarding the cast/pointer shift (it might be interesting for others): once I did some optimization by replacing some codepieces to branchless code, and examined the assembly of the code and found a very annoying thing: If you use static cast between two types and the compiler knows that the this pointer must be shifted between the two pointer types (in some cases of multiple inheritance), then it generates branched code because the NULL pointer must be handled specially! If the pointer is NULL then it mustnt be shifted! Grrrrrrr!!! ;-)

Sergey Alexandrovich Kryukov 20-Aug-12 18:17pm

You are right about compiler dependency, of course, but there are certain constraints to any thinkable implementation (I'm talking a single-vtable system in case of multiple inheritance here). I refer to the Microsoft VC++ v.6.
Your explanation of null as a special case look quite natural...

Generally, this is why people are going out from C++ kind of multiple inheritance. One way is the shift to the weak form of multiple inheritance (multiple for pure interfaces, single for a base type). It does not actually solve many problems; this is rather "stay-out-of-trouble" approach then a real resolution of a crisis. Ada 95 (first OOP one) offered interesting approach; inheritance is always singular, and multiple is simulated asymmetrically, only for the pair of "parent" classes (only one is technically a base) in the following way: one class is a base one, another is a discriminant of the derived type; and, importantly, the syntax in the user of the derived type looks like in multiple inheritance (but the nature of the typing in like a discriminant class would be a composed attribute). This is good enough. Besides, I think, anyone would agree to limit the number of multiple bases by 2, because other types, if needed, could be added on separate steps of inheritance. To me, it would not be even the annoyance, next to the benefits.

In the approach of IBM Research, Subject-Oriented Programming or Separation-Of-Concerns approach, later reduced to Aspect-oriented programming, there was talking of "dynamic inheritance", but I don't thing the OOP notion of inheritance could be legitimately applied here...

--SA

pasztorpisti 20-Aug-12 19:57pm

There are some cases where multiple inheritance is very useful. The only thing I dont like when multiple inheritance is overused (its easy to abuse unfortunately :-D) and in that case the need for virtual inheritance often comes into picture, it also makes the language much more complex. I guess they wanted to avoid this in C# and java by allowing multiple inheritance from interfaces only. Still, sometimes I see here and there that some ppl miss multiple inheritance for example from C#.
/off
When it comes to paradigms a few of my function programming fanatic friends come to my mind: I always feel that they hate every other paradigm and they regularly encourage me to convert and start using haskell or F# :-) Its very interesting that those who start programming in a functional programming language usually like it a lot - even those who work with something else say that it changes the way they think. Unfortunately I havent solved many problems in FP, only my homework in haskell - a simple pascal parser that extracts some info from source. It was a pain in the ass for me to write it, took about 2 weeks to write that simple prog. It was a painful experience (during my exams) and always retracts me from diving into FP theory... :-) Another thing I'm afraid of library support for those languages, however in case of F# it should be solved.
/on

Sergey Alexandrovich Kryukov 20-Aug-12 20:33pm

Of course it's useful; who would argue against that? It's just that it potentially creates a lot of problems. Basically, it's very useful and the solution can be problem-free is a whole hierarchy is developed as a part of an integral plan, but if you let your users to further inherit your classes, it could be a problem. And you are right about the abuse, too. Lack of multiple inheritance is the same kind of problem as the problems of multiple inheritance. Both having and not having it is the problem.

As to the "off" section: what you describe is a clear sign of a non-thinker (didn't want to offend any of your friends though), a person driven by such things as crowd psychology, and, most importantly, the imprinting. However, a 100% negative assessment of anything is not a bad sign. For example, a person who would say VB is good for nothing could be just a normal healthy person, because only the people from the first group can like it. As to the language, the defectiveness of nearly all of them is pretty discouraging, especially for those who finds it difficult to see things philosophically. C# is very nice, but I find some 2-3 failures which
are really global failures (depending on how you count them). Same things with F#...

Nevertheless, I can observe that things are getting better since the time when people used Fortran and the practice was dominated by "practical people" arrogantly criticized Algol which was potentially million times better... However, the dominating view of amazing computing progress is very naive. They just don't know the technologies which were quite on the modern level or even better, in the past, but were killed or forgotten. Why? Ultimately, I would blame those aggressive and emotional non-thinkers who I mentioned above; and only the second-order of responsibility is on those the narrow interests of corporations and other narrow groups. Why? Because those who fool people can only survive in the presence of fools... :-)
--SA

pasztorpisti 20-Aug-12 21:49pm

I agree with you about non-thinking ppl in general. There is no general purpose language that is good to solve every problem, only a domain specific language can be really good, "optimal" to solve a problem. My problem is that I dont know FP well enough to see what is its real world domain, thats why I usually dont step up against the oration of my friends. :-) However one of them showed me for example full renderer code and small game engine written in haskell, its very impressive how much shorter can it be in FP. The absence of local variables and side effects, the easy parallelization of FP code are all quite impressive traits. I'm just not impressed by the population of the user base of FP, despite the fact that it has the potential to become and widely used (and maybe hyped) stuff. The salaries offered for functional programmer jobs are also attractive! ;-)

nv3 20-Aug-12 14:15pm

Thanks, Sergey!

pasztorpisti 20-Aug-12 14:24pm

In case of single line inheritance we speak of dependency chain for initialization, while in case of multiple inharitance its a directed dependency graph. Generally speaking the most derived class can change the virtual table pointer (or any of the vtable pointres in case of multi-inheritance) of its base class/base classes in the constructor.

nv3 20-Aug-12 14:15pm

Thanks and very good points in that comment. I think we have stumbled over that problem once in a while. Very nicely explained. Why don't you put it in a solution by itself, which would give you some more formatting options.

pasztorpisti 20-Aug-12 14:17pm

Didnt plan for so long explanation but it happend to be that long. :-) I leave it here if its not a problem. And it isn't really the answer to the question of OP, just some extra info + advices.