EGCS: pointer to member functions.

Alexandre Oliva
Wed Jun 16 23:18:00 GMT 1999

On Jun 16, 1999, (Mike Stump) wrote:

>> From: Alexandre Oliva <>
>> Date: 16 Jun 1999 20:13:03 -0300

>> (or comparison would have to become much more complicated).

> Yes.  :-(  Comparisons can run slower, if dispatch is fast.

It seems to me that a pair<pointer_to_thunk,offset> is fast and
general enough, but generating specialized thunks could save us
space.  Do you think it is worth it?

I see a lot of complications in generating offset-thunks dynamically.
If a thunk is just tacked in front of another, a series of casts, such
as base-to-derived and derived-back-to-base would create a sequence of
thunks that just cancel each other.  So, instead of dumbly stacking
offset thunks, we'd have to look into any existing thunk, tell whether
it is an dispatcher thunk or an offset thunk, and combine with an
existing offset thunk.  Maybe the offset thunk could also be combined
with the dispatcher thunk.

In any case, we'd have to dynamically allocate space for these thunks;
unlink in the vtable-thunks case, they can't be stored in the stack
because the casted pointer-to-member may live longer than the current
stack frame.

A design that comes to my mind is to construct pointer-to-member
mapping tables that, given a dispatcher thunk of a base class (say,
its address, or an index based on the order of declaration of the
methods in the base class), return the dispatcher thunk for the
derived class, and another that performs the reverse mapping.  The
disadvantage of this scheme is that dispatcher thunks would have to be
instantiated for each member of the classes involved in the type-cast.
We could generate weak definitions for the base thunks, to save some
space.  But if the point of using offset thunks is to save space, I'm
not really sure it does, since we'd have to add all this garbage any
time a pointer-to-member typecast is found.  But then, it's all static
data, and, if you create a lot of pointers-to-methods, it may pay


Alexandre Oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}  aoliva@{,}
*** E-mail about software projects will be forwarded to mailing lists

More information about the Gcc mailing list