Yet More on MI

Matthew Tuck matty@box.net.au
Sat, 20 Mar 1999 14:54:35 +1030


Hans-Dieter.Dreier@materna.de wrote:

> The proposed instance layout would be:
> 
> this -> - Reference to MI class if used as mixed-class, pointer to this otherwise (Note a)
>         - Reference to vtable (Note b)
>         - Reference to ttable (Note c)
>         - (Instance items if any)
> 
> Note a:
> If a reference to this is used in the program itself, a reference to the MI object is wanted rather than a reference to the mixin object.
> That's what this instance item is good for.
> 
> Note b:
> This will be the vtable as commonly used.
> Each virtual item that has been declared here or in one of the base classes has a slot assigned by the compiler in which its address is stored.
> Vtable layout of base classes is preserved; entries for virtual items in the current class are appended.
> The vtable may be shared among all instances of that class that are used in the same mixin declaration (or as a standalone class).
> This is because the compiler may need to change entries' values if the MI class (or one of the other mixins) overrides virtual items of this (mixin) class.
> Example: Let there be instances of class A as a standalone class as well as (implicit) instances that are used as mixins.
> Then there will be two versions of the vtable, one for each usage.
> 
> Note c:
> For each vtable entry this table will contain the this pointer that needs to be used with that entry
> (ie he reference to the instance that actually contains the item).
> If the item is taken from the MI class, it will be a pointer to the MI class's instance;
> if it was taken from a mixin (of the MI class) it will be one to that mixin's instance.
> Because it contains this's, I'll call it the "ttable".
> The value will be used as a this pointer for actual item access (for virtual calls; simple data accesses may not need it).

> This makes sure that a method will always be called with the proper
> this value (ie consistent with instance layout) which for mixins is
> different from the MI object's this value.

Normally I would expect this to mean the object no matter whether I'm
using the mixin or not.

> 
> The memory layout looks like this:
> 
> AnA:
>     AnA            // MI class instance: If you check "this == aC" inside A standalone you get false because this is AnA
>     vtable of A standalone
>     ttable of AnA  // might be NULL, see Note c
>     a
> 
> vtable of A standalone:
>     va1 of A
>     va2 of A
> 
> ttable of AnA:     // might be missing, see Note c
>     AnA
>     AnA
> 
> (This was easy.)
> 
> aC:
>     aC              // MI class instance
>     vtable of C
>     ttable of aC
>     c
>     ca
>     cb
> 
> vtable of C:
>     va1 of A
> 
> ttable of aC:
>     ca             // va1 always operates on an A if taken from A
> 
> ca:
>     aC             // MI class: If you check "this == aC" inside mixin A ca you get true
>     vtable of mixin A ca
>     ttable of ca
>     a
> 
> vtable of mixin A ca:
>     va1 of A
>     va2 of C       // overridden by C
> 
> ttable of ca:
>     ca
>     aC
> 
> cb:
>     aC
>     vtable of mixin B cb
>     ttable of cb
>     b
> 
> vtable of mixin B cb:
>     vb1 of B
>     vb2 of C       // overridden by C
>     va1 of A       // found in A
> 
> ttable of cb:
>     cb
>     aC
>     ca
> 



-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/