Virtual function and multiple inheritance

**George2** · 02-02-2008

Thanks Elysia,

1.

What did your assembly shows to prove function func_derived is in vtable?

Originally Posted by Elysia

I have no idea how it stores the functions the vtables (in case of Derived). They certainly don't show up in the debugger, but they certainly work, so they must be in a vtable. In fact, the assembly shows this.

Here is my more simplified case to show virtual function is missing in vtable. In class Goo, function myFunc is missing in vtable, but in class Zoo, it is ok to contain virtual function zoo_func.

2.

Code:

#include <iostream>

using namespace std;

class Foo {

	virtual int func1() = 0;
	virtual int func2() = 0;
	virtual int func3() {return 0;}
};

class Goo: Foo {
public:
	virtual int func1() {return 0;}
	virtual int func2() {return 0;}
	virtual int myFunc() {return 1;}
};

class Zoo {

public:

	virtual int zoo_func() {return 0;}
};

int main()
{
	Goo g;
	Zoo z;
	return 0;
}

regards,
George

**CornedBee** · 02-02-2008

I say it's a limitation of the debugger.

**George2** · 02-02-2008

Thanks CornedBee,

So you mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

Originally Posted by CornedBee

I say it's a limitation of the debugger.

regards,
George

**CornedBee** · 02-02-2008

Yes, exactly. You can make this conclusion from the simple fact that calling the function works.

**Elysia** · 02-02-2008

If you can read assembly, it is undeniable proof:

Code:

	pD->foo();
00415020  lea         ecx,[ebp-24h] 
00415023  call        CMemoryManagerBase<D>::operator-> (4132B7h) 
00415028  mov         dword ptr [ebp-140h],eax 
0041502E  mov         eax,dword ptr [ebp-140h] 
00415034  mov         edx,dword ptr [eax] 
00415036  mov         esi,esp 
00415038  mov         ecx,dword ptr [ebp-140h] 
0041503E  mov         eax,dword ptr [edx] 
00415040  call        eax  
00415042  cmp         esi,esp 
00415044  call        @ILT+1650(__RTC_CheckEsp) (413677h) 
	pC->foo();
00415049  lea         ecx,[ebp-40h] 
0041504C  call        CMemoryManagerBase<C>::operator-> (4138C0h) 
00415051  mov         dword ptr [ebp-140h],eax 
00415057  mov         eax,dword ptr [ebp-140h] 
0041505D  mov         edx,dword ptr [eax] 
0041505F  mov         esi,esp 
00415061  mov         ecx,dword ptr [ebp-140h] 
00415067  mov         eax,dword ptr [edx] 
00415069  call        eax  
0041506B  cmp         esi,esp 
0041506D  call        @ILT+1650(__RTC_CheckEsp) (413677h) 
	pB->foo();
00415072  lea         ecx,[ebp-5Ch] 
00415075  call        CMemoryManagerBase<B>::operator-> (4132EEh) 
0041507A  mov         dword ptr [ebp-140h],eax 
00415080  mov         eax,dword ptr [ebp-140h] 
00415086  mov         edx,dword ptr [eax] 
00415088  mov         esi,esp 
0041508A  mov         ecx,dword ptr [ebp-140h] 
00415090  mov         eax,dword ptr [edx] 
00415092  call        eax  
00415094  cmp         esi,esp 
00415096  call        @ILT+1650(__RTC_CheckEsp) (413677h) 
	pA->foo();
0041509B  lea         ecx,[ebp-78h] 
0041509E  call        CMemoryManagerBase<A>::operator-> (413852h) 
004150A3  mov         dword ptr [ebp-140h],eax 
004150A9  mov         eax,dword ptr [ebp-140h] 
004150AF  mov         edx,dword ptr [eax] 
004150B1  mov         esi,esp 
004150B3  mov         ecx,dword ptr [ebp-140h] 
004150B9  mov         eax,dword ptr [edx] 
004150BB  call        eax  
004150BD  cmp         esi,esp 
004150BF  call        @ILT+1650(__RTC_CheckEsp) (413677h)

Code:

	ppnew<D> pD;
	ppnew<C> pC;
	ppnew<B> pB;
	ppnew<A> pA;
	pD->foo();
	pC->foo();
	pB->foo();
	pA->foo();

**George2** · 02-02-2008

Thanks CornedBee,

"Yes, exactly" -- what is your context? You mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

Originally Posted by CornedBee

Yes, exactly. You can make this conclusion from the simple fact that calling the function works.

regards,
George

**George2** · 02-02-2008

Hi Elysia,

We are talking about virtual function in this topic. Which of your function is virtual? And how to find from assembly whether a virtual function is in vtable?

Originally Posted by Elysia

If you can read assembly, it is undeniable proof:
[code] pD->foo();
00415020 lea ecx,[ebp-24h]
00415023 call CMemoryManagerBase<D>:

perator-> (4132B7h)
00415028 mov dword ptr [ebp-140h],eax
0041502E mov eax,dword ptr [ebp-140h]
00415034 mov edx,dword ptr [eax]
00415036 mov esi,esp
00415038 mov ecx,dword ptr [ebp-140h]
0041503E mov eax,dword ptr [edx]
00415040 call eax
00415042 cmp esi,esp
00415044 call @ILT+1650(__RTC_CheckEsp) (413677h)

regards,
George

**Elysia** · 02-02-2008

Code:

class A
{
public:
	virtual void foo() { }
};

class B
{
public:
	virtual void foo() { }
};

class C: public A, public B
{
public:
	virtual void foo() { }
};

class D: public C
{
public:
	virtual void foo() { }
};

Originally Posted by George2

Thanks CornedBee,

"Yes, exactly" -- what is your context? You mean in vtable, myFunc is there, but debugger can not display it? If yes, how could we make conclusion that in vtable, myFunc exists?

regards,
George

CornedBee means that the vtable exists and the functions are part of the vtable but the debugger can't display it. Debugger limitation.
You can in fact know that it exists in a vtable because it works or by looking at the assembly.
It doesn't take the address of the function and call it. It actually takes the first 4 bytes and dereferences it to call the appropriate function - undeniable proof that the vtable exists.

**Codeplug** · 02-02-2008

http://msdn.microsoft.com/archive/de...angrayhood.asp

Old article, but still relevant for VC++.

gg

**ZuK** · 02-02-2008

If a class declares a virtual function and you have an instance of that class why would it have to have an entry for that function in the vtable ? There is not much to look up in a table with just one entry so it might just be optimized away.
Guess that is what you see in your examples. Objects of a class that declare virtual members don't have entries of their ( not yet overridden ) virtual functions in the v-table.
That is just a guess.
Kurt

**Elysia** · 02-02-2008

But your theory seems wrong. This behavior was seen in debug builds, so the compiler couldn't have optimized it away. Yet. In release, it might just do that.
In my own tests, I created 4 classes with the same function, all virtual, so that would force the compiler to make a vtable. Yet, only the functions in A and B are shown in the vtable.
But the assembly shows that the functions do exist in the vtable since it calls a virtual function and, indeed, it calls the right function.

**iMalc** · 02-02-2008

Unless you're writing a compiler you don't need to know how it works, and if you do write a compiler, it'll quickly become blatently obvious why other compilers do things a certain way.

You shouldn't really be using sizeof on a class that has virtual functions. I'm struggling to find any legitimate reason for needing to know the size of a class with virtual functions.

**CornedBee** · 02-02-2008

Separating allocation and construction? What do you think std::allocator does?

**George2** · 02-03-2008

Thanks Elysia,

Which exact statements in the assembly language do you mean? Could you quote please?

"It actually takes the first 4 bytes and dereferences it to call the appropriate function"

And it is appreciated if you could post you code, and it is good if we could discuss based on the common code base. :-)

Originally Posted by Elysia

CornedBee means that the vtable exists and the functions are part of the vtable but the debugger can't display it. Debugger limitation.
You can in fact know that it exists in a vtable because it works or by looking at the assembly.
It doesn't take the address of the function and call it. It actually takes the first 4 bytes and dereferences it to call the appropriate function - undeniable proof that the vtable exists.

regards,
George

**George2** · 02-03-2008

No Zuk, you are wrong. :-)

In my sample, class Zoo has only one method called zoo_func, it is virtual and it is in vtable.

Originally Posted by ZuK

If a class declares a virtual function and you have an instance of that class why would it have to have an entry for that function in the vtable ? There is not much to
look up in a table with just one entry so it might just be optimized away.
Guess that is what you see in your examples. Objects of a class that declare virtual members don't have entries of their ( not yet overridden ) virtual functions in the v-table.
That is just a guess.
Kurt

Hi CornedBee,

Originally Posted by CornedBee

Separating allocation and construction? What do you think std::allocator does?

I am not sure what do you mean. Does your above reply relates to my question?

regards,
George