Re: Vbase offsets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Vbase offsets
- To: dehnert@xxxxxxx, dehnert@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: Vbase offsets
- From: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
- Date: Mon, 03 Apr 2000 21:48:18 -0700
>>>>> "Jim" == Jim Dehnert <dehnert@xxxxxxxxxxxxxxxxxxxx> writes:
Jim> I don't know about you, but we are. This paragraph didn't
Jim> get fixed when we decided to always include vbase offsets for
Jim> all virtual bases. I've fixed it now (with the example) --
Jim> everyone please verify that it matches our decisions.
OK. But, given:
struct S {
virtual void f();
};
struct T : virtual public S {};
struct U : public T {};
Are there two vbase offsets for `S' in the vtable for `U'? Here `T'
is the primary base for `U', so the vtable for `U' already has an `S'
entry. I assume we don't want to add an extra one. Maybe that
example would be helpful, too? What if `T' is inherited virtually?
Then, `T' is still the primary base of `U', so I don't think we need
an extra offset here either? If I'm right, that's probably worth
mentioning too. So, I think the rule is:
If there is no primary base class, then there is a vbase offset for
every direct or indirect virtual base. Otherwise, a vbase offset is
present in the derived class for every virtual base that does not
already have a vbase offset in the primary base class vtable. In
either case, the vbase offsets are allocated in reverse inheritance
graph order.
--
Mark Mitchell mark@xxxxxxxxxxxxxxxx
CodeSourcery, LLC http://www.codesourcery.com