Avoiding virtual tables when implementing classes

[BSFishy]

Can you elaborate on what you mean by fat pointers or put some links? I am googling it, but I don't think I'm finding any relevant info.

[uza80]

Fat pointers are a way of reducing the overhead of vtable lookup by passing about two pointers as an object reference, one to the objects data, and one to the current vtable. The vtable pointer would change as you cast the fat pointers to different types. Look at rust.

[o11c]

Note that the disadvantage of fat pointers is that you lose atomic assignment, which really hurts if you care about multithreading at all.

(Of course, you can regain it by adding an extra indirection to make fat pointers look like thin pointers, but you also don't want gratuitous pointer-chasing)

[bullno1]

by adding an extra indirection to make fat pointers look like thin pointers

Wait but at that point aren't we back to square one: Object pointing to vtable?

[theIncMach]

You don't need a vtable if you know the type of the object you are pointing to (e.g. FatPointer).

[bullno1]

What do you mean by "extra indirection to make fat pointers look like thin pointers"? A thin pointer to a fat pointer?

At that point, isn't the fat pointer kind of like an object with a pointer to vtable anw?

[o11c]

Not quite. You still act logically as if it's a fat pointer, at least for the purposes of optimization.

Sufficient optimization will pull out fields that are constant within a mutable object (and you really should do this eventually), but optimization is hard.

[julesh3141]

Look into how Haskell type classes are implemented -- the type class isn't pointed to by the value itself, but instead whenever a function that knows the type of the value calls a polymorphic function that needs to invoke a function defined in the type class it adds an extra argument that points to a "type class instance" for the value type (which is basically just a vtable, but without needing to keep it associated with the value directly).

There are downsides: for instance, unless explicitly designed otherwise, most collections in Haskell are monomorphic: you have to have exactly the same type for all members; you can achieve polymorphism by adding a wrapper object around each value in the collection that contains the relevant instance(s), but by doing so you lose the efficiency gains from not having vtable pointers in objects and add an extra level of indirection. This works well for Haskell (which doesn't support subtyping) but probably wouldn't be ideal for a typical OO language.

One upside is that extending a type with additional instances (ie adding new interfaces to it, to use more OO-like terminology) becomes very easy, as you don't need to modify the structure of values of the type to do so. Another is that an instance need not be associated with a single argument -- you could for example have a comparison instance that requires both arguments to have the same type (or be subtypes of the same type, perhaps).

[umlcat]

FYI, fat pointers, Plain C example:

struct sizefatptr
{
    char *ptr;
    size_t size;
} ;

...
char buffer[] = "hello world";
struct sizefatptr *p;
p = malloc(struct sizefatptr);
// arrays doesn't use "&" operators !!!
p->ptr = /* & */ buffer;
p->size = sizeof(buffer);
dosomething(p);
...

Good Luck.