RE: What does the vtable look like?

RE: What does the vtable look like?

[Mike Stump]

> From: "Jody Hagins" <jody@atdesk.com>
> Date: Fri, 11 Jun 1999 11:27:55 -0400

> However, the first entry is always null, followed by what appears to
> be the function pointer for type info or dynamic_cast.  Then, the
> defined virtual functions, starting with the dtor (from the base
> class).

No, the dtor isn't in any particular spot.  It just comes in the
`natural' virtual function place.

> Unfortunately, there does not appear to be a terminator of the list.
> I would think that the null would come at the *end* of the table,
> not the beginning.  Or, at least some count, indicating the size of
> the table...

Nope.  It is a waste of space.  You cannot meaningfully for anything
with the table without knowing how many elements are in the table.
You will have to find that information out some other way.  One
thought, is to put more member info into the rtti data, and then you
could use it.

RE: What does the vtable look like?

[Jody Hagins]

> > Unfortunately, there does not appear to be a terminator of the list.
> > I would think that the null would come at the *end* of the table,
> > not the beginning.  Or, at least some count, indicating the size of
> > the table...
>
> Nope.  It is a waste of space.  You cannot meaningfully for anything
> with the table without knowing how many elements are in the table.
> You will have to find that information out some other way.  One
> thought, is to put more member info into the rtti data, and then you
> could use it.

Thanks!!!


One thing that has me stumped is that if I get the "index" of the virtual
function...

typedef int (Base::*Function)();

union U
{ 
  Function ff;
  void * vp;
};
    
main()
{
  U u;
  u.ff = (Function)(&Base::something);
  cout << "Base::something -------->  " << u.vp << endl;
}


This is soming back as 0x00040000, but it's place in the table is actually index 3, but that is including the size and rtti info.  For example...

vtbl[0] = (nil)		-- offset to object
vtbl[1] = 0x8049430	-- rtti
vtbl[2] = 0x80493ec	-- Base::~Base()
vtbl[3] = 0x8048ee8	-- Base::something()
vtbl[4] = 0x8049308	-- Base::bar_event_handler()
vtbl[5] = 0x80492d0	-- Base::foo_event_handler()


&Base::something inside class = 0x8048ee8
&Base::something -------->  0x40000

This seems to indicate that something can be found at index 4, but this is not the case.  I must still be missing something...

RE: What does the vtable look like?

[Jody Hagins]

> > Unfortunately, there does not appear to be a terminator of the list.
> > I would think that the null would come at the *end* of the table,
> > not the beginning.  Or, at least some count, indicating the size of
> > the table...
>
> Nope.  It is a waste of space.  You cannot meaningfully for anything
> with the table without knowing how many elements are in the table.
> You will have to find that information out some other way.  One
> thought, is to put more member info into the rtti data, and then you
> could use it.

Thanks!!!


One thing that has me stumped is that if I get the "index" of the virtual
function...

typedef int (Base::*Function)();

union U
{ 
  Function ff;
  void * vp;
};
    
main()
{
  U u;
  u.ff = (Function)(&Base::something);
  cout << "Base::something -------->  " << u.vp << endl;
}


This is soming back as 0x00040000, but it's place in the table is actually index 3, but that is including the size and rtti info.  For example...

vtbl[0] = (nil)		-- offset to object
vtbl[1] = 0x8049430	-- rtti
vtbl[2] = 0x80493ec	-- Base::~Base()
vtbl[3] = 0x8048ee8	-- Base::something()
vtbl[4] = 0x8049308	-- Base::bar_event_handler()
vtbl[5] = 0x80492d0	-- Base::foo_event_handler()


&Base::something inside class = 0x8048ee8
&Base::something -------->  0x40000

This seems to indicate that something can be found at index 4, but this is not the case.  I must still be missing something...

RE: What does the vtable look like?

[Mike Stump]

> From: "Jody Hagins" <jody@atdesk.com>
> Date: Fri, 11 Jun 1999 11:27:55 -0400

> However, the first entry is always null, followed by what appears to
> be the function pointer for type info or dynamic_cast.  Then, the
> defined virtual functions, starting with the dtor (from the base
> class).

No, the dtor isn't in any particular spot.  It just comes in the
`natural' virtual function place.

> Unfortunately, there does not appear to be a terminator of the list.
> I would think that the null would come at the *end* of the table,
> not the beginning.  Or, at least some count, indicating the size of
> the table...

Nope.  It is a waste of space.  You cannot meaningfully for anything
with the table without knowing how many elements are in the table.
You will have to find that information out some other way.  One
thought, is to put more member info into the rtti data, and then you
could use it.

RE: What does the vtable look like?

[Mike Stump]

> From: "Jody Hagins" <jody@atdesk.com>
> Date: Fri, 11 Jun 1999 14:02:18 -0400

> One thing that has me stumped is that if I get the "index" of the
> virtual function...  This is coming back as 0x00040000, but it's
> place in the table is actually index 3, but that is including the
> size and rtti info.  For example...

> This seems to indicate that something can be found at index 4, but
> this is not the case.  I must still be missing something...

Yes.  The +/-1.  It is constant.

RE: What does the vtable look like?

[Mike Stump]

> From: "Jody Hagins" <jody@atdesk.com>
> Date: Fri, 11 Jun 1999 14:02:18 -0400

> One thing that has me stumped is that if I get the "index" of the
> virtual function...  This is coming back as 0x00040000, but it's
> place in the table is actually index 3, but that is including the
> size and rtti info.  For example...

> This seems to indicate that something can be found at index 4, but
> this is not the case.  I must still be missing something...

Yes.  The +/-1.  It is constant.

Re: What does the vtable look like?

[Mike Stump]

Almost identical (on non-thunk systems), on thunk systems, it is a pointer to
an array of function pointers.  Please compile into a .s file (-S), and look
at the output.  The first entry or two is used for rtti stuff (offset to start
of complete obejct in bytes, and an rtti pointer).

Re: What does the vtable look like?

[Mike Stump]

Almost identical (on non-thunk systems), on thunk systems, it is a pointer to
an array of function pointers.  Please compile into a .s file (-S), and look
at the output.  The first entry or two is used for rtti stuff (offset to start
of complete obejct in bytes, and an rtti pointer).

What does the vtable look like?

[Jody Hagins]

With cfront, I can get the virtual function table like so...


struct Virtual_Function_Table_Entry
{
  short d;
  short i;
  int (*f)();
};

The virtual table pointer stored in each object points to an array of
Virtual_Function_Table_Entry structures.

Then I can run through all the virtual functions like so...

class VBase
{
public:
  virtual ~VBase();
};

VBase::
~VBase()
{
}

void print_virtual_functions(VBase * p)
{
  Virtual_Function_Table_Entry * vtbl =
      *((Virtual_Function_Table_Entry**)p);
  for (int i = 0; vtbl[i].f; ++i)
  {
    cout << "virtual function " << i << " is "
         << vtbl[i].f << endl;
  }
}




For egcs, what does the virtual table pointer point to?  Is it a table of
pointers, structures, a linked list of pointers?  What is it?


Thanks!

RE: What does the vtable look like?

[Jody Hagins]

> For egcs, what does the virtual table pointer point to?  Is it a table of
> pointers, structures, a linked list of pointers?  What is it?



OK.  It looks like it points into a table of function pointers (surprise
:-)...

However, the first entry is always null, followed by what appears to be the
function pointer for type info or dynamic_cast.  Then, the defined virtual
functions, starting with the dtor (from the base class).  Unfortunately,
there does not appear to be a terminator of the list.  I would think that
the null would come at the *end* of the table, not the beginning.  Or, at
least some count, indicating the size of the table...


Anyone?

Re: What does the vtable look like?

[Martin v. Loewis]

> However, the first entry is always null

Try multiple inheritance.

Regards,
Martin

Re: What does the vtable look like?

[Martin v. Loewis]

> However, the first entry is always null

Try multiple inheritance.

Regards,
Martin

RE: What does the vtable look like?

[Jody Hagins]

> For egcs, what does the virtual table pointer point to?  Is it a table of
> pointers, structures, a linked list of pointers?  What is it?



OK.  It looks like it points into a table of function pointers (surprise
:-)...

However, the first entry is always null, followed by what appears to be the
function pointer for type info or dynamic_cast.  Then, the defined virtual
functions, starting with the dtor (from the base class).  Unfortunately,
there does not appear to be a terminator of the list.  I would think that
the null would come at the *end* of the table, not the beginning.  Or, at
least some count, indicating the size of the table...


Anyone?

What does the vtable look like?

[Jody Hagins]

With cfront, I can get the virtual function table like so...


struct Virtual_Function_Table_Entry
{
  short d;
  short i;
  int (*f)();
};

The virtual table pointer stored in each object points to an array of
Virtual_Function_Table_Entry structures.

Then I can run through all the virtual functions like so...

class VBase
{
public:
  virtual ~VBase();
};

VBase::
~VBase()
{
}

void print_virtual_functions(VBase * p)
{
  Virtual_Function_Table_Entry * vtbl =
      *((Virtual_Function_Table_Entry**)p);
  for (int i = 0; vtbl[i].f; ++i)
  {
    cout << "virtual function " << i << " is "
         << vtbl[i].f << endl;
  }
}




For egcs, what does the virtual table pointer point to?  Is it a table of
pointers, structures, a linked list of pointers?  What is it?


Thanks!