__vfptr problem in VC++.NET

[debadeepti]

Hi All,

I am porting an application from watcom to vc compiler. In watcom and
other compiler (other then vc) memory allocation of __vfptr inside
class object are different. In vc __vfptr is allocated top of the class
object i.e base address of class objects are same as __vfptr address.
But in watcom compiler __vfptr is allocated end of the class object.
Due to this difference, I am getting problem in accessing the member
variable address correctly. Is there any way in vc compiler option to
bring __vfptr from top to bottom of the class object.

Let's take a class example

Class exp_v
{
virtual void foo(void) {};
private:
int a;
int b;
};


In Watcom:-

|-----------------|<-- 0x3660(BaseAddress)
|int a |
|-----------------|<-- 0x3664
|int b |
|-----------------|<-- 0x3668
|__vfptr |
|-----------------|


In VC++.NET:-

|-----------------|<-- 0x3660(BaseAddress)
|__vfptr |
|-----------------|<-- 0x3664
|int a |
|-----------------|<-- 0x3668
|int b |
|-----------------|


Thanks & Regards
Debadeepti Sahu.

 

[Phlip]

BTW this is about VC++7, not .NET, which is a different (slobberin') animal.

I am porting an application from watcom to vc compiler. In watcom and
other compiler (other then vc) memory allocation of __vfptr inside
class object are different. In vc __vfptr is allocated top of the class
object i.e base address of class objects are same as __vfptr address.
But in watcom compiler __vfptr is allocated end of the class object.
Due to this difference, I am getting problem in accessing the member
variable address correctly. Is there any way in vc compiler option to
bring __vfptr from top to bottom of the class object.

What does "accessing the member variable address" mean? You neglected to
post code to illustrate that.

Class exp_v
{
virtual void foo(void) {};
private:
int a;
int b;
};

If you use the "pointer to member" language feature - which is really a
"smart offset", you shouldn't have trouble. And if you use the 'offsetof()'
macro, you shouldn't either.

But if you somehow stored the byte offset of a member into a data file, and
then need to use that offset after the Replace Compiler Refactor, you will
need to simply encapsulate your discovery of the size and location of the
__vfptr, if any, and live with extra math in your access code, right?

 

[John Carson]

Hi All,

I am porting an application from watcom to vc compiler. In watcom and
other compiler (other then vc) memory allocation of __vfptr inside
class object are different. In vc __vfptr is allocated top of the
class object i.e base address of class objects are same as __vfptr
address. But in watcom compiler __vfptr is allocated end of the class
object. Due to this difference, I am getting problem in accessing the
member variable address correctly. Is there any way in vc compiler
option to bring __vfptr from top to bottom of the class object.

Let's take a class example

Class exp_v
{
virtual void foo(void) {};
private:
int a;
int b;
};


In Watcom:-



In VC++.NET:-

I believe that the answer to your question is no: you cannot change where
the __vfptr is located. However, the best place to ask is

public.microsoft.vc.language

This is an implementation detail that a programmer normally doesn't need to
know anything about. Writing code that depends on implementation details is
asking for exactly the sort of trouble you are now having. What are you
doing that requires this information?

 

[Rolf Magnus]

Hi All,

I am porting an application from watcom to vc compiler. In watcom and
other compiler (other then vc) memory allocation of __vfptr inside
class object are different. In vc __vfptr is allocated top of the class
object i.e base address of class objects are same as __vfptr address.
But in watcom compiler __vfptr is allocated end of the class object.
Due to this difference, I am getting problem in accessing the member
variable address correctly. Is there any way in vc compiler option to
bring __vfptr from top to bottom of the class object.

I don't think this is possible. But actually, I don't see why you should
ever care where the vtable pointer is. What exactly are you having problems
with?