Vcall offsets

[Jim Dehnert]

Sorry for the delay in responding.

> From: Mark Mitchell <mark at codesourcery.com>
> Date: Tue, 16 May 2000 09:48:31 -0700
> 
> I apologize to everyone for being confusing via proxy last week.
> 
> Here was the example I was trying to get at:
> 
>   class A { virtual void f (); };
>   class B1 : public A {};
>   class B2 : public A {};
>   class D : public B1, public B2 {};
> 
> Now, suppose that `D' is used as a virtual base.  The question is
> whether or not there should be vcall offsets for both instances of
> `f', even though they have the same signature.  This paragraph:
> 
>   If the above listing of vcall offsets includes more than one for a
>   particular virtual function signature, only the first one (closest
>   to the vtable address point) is allocated. That is, an offset from
>   primary base P (and its non-virtual bases) eliminates any from A or
>   its other bases, an offset from A eliminates any from the
>   non-primary bases, and an offset from a non-primary base B of A
>   eliminates any from the bases of B.
> 
> implies that there should be only one such offset, which I believe to
> be reasonable.

Correct.

> But, what about:
> 
>   class A { virtual void f (); };
>   class B1 : public A { virtual void f (); };
>   class B2 : public A {};
>   class D : public B1, public B2 {};
> 
> Here, do we get two offsets (for B1::f and A::f) or just one?

Just one, for the same reason.  And since the base visit order is B1,
A, B2, you get it in the position implied by the B1 instance.  And you
shouldn't need more.  Either of them will correct the invocation class
pointer (B1 or A) to the virtual base pointer (D), and then use the
unique vcall offset in D to get to whatever the class with the
overriding definition is.

> Frankly, I think we should just drop the paragraph quoted above.  I
> challenge anyone to present a real-world program that suffers any
> significant space or time penalty because of wasting a few extra vcall
> offset entries in the vtable.  The implementation complexity, and the
> time we have to spend thinking about the issues, is not worth it.  I
> suggest we just replace that paragraph with:
> 
>   (Note: there may be more than one vcall offset entry for the same
>    virtual function if that virtual function appears more than once
>    in the various vtables considered.)

I guess I don't think this is a problem as it stands.  Am I missing
something?

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272