[munchler]

Note that this is using interfaces (i.e. vtables, records of function pointers), not full object-orientation. Other OO features, like classes and inheritance, have much more baggage, and are often not worth the associated pain.

[1718627440]

What do you think inheritance is, if not composition of vtables? What do you think classes are, if not a composition of a vtable and scoped variables?

[munchler]

Those "scoped variables" are the difference. Mutable state adds a great deal of complexity.

[1718627440]

And the style presented in the article uses vtables with "scoped variables". How do you conclude it's "not full object-orientation"?

[PhilipRoman]

Field inheritance is surprisingly natural in C, where a struct can be cast to it's first member.

[1718627440]

Note that you only need to cast for an upcast. To access the first member, you wouldn't need to cast.

It would be nice though, if syntax like the following would be supported:

    struct A 
    {
        int a;
    };

    struct B 
    {
        int b; 
        struct A a;
    };

    void foo (struct A * a)
    {
        struct B * b;

        &b->a = pa;
    }

    struct B b;

    foo (&b.a);

[teo_zero]

In what scenario would this be useful? If foo() takes a struct A, it should be more generic and have no knowledge about the more specialized struct B.

[1718627440]

In exact that same scenario, that you would cast to a subclass in another language, it's about language support for what for example the kernel does with container_of.

Of course casting to a subclass isn't guaranteed to succeed always, but for example when you have actually declared it as the subclass elsewhere it's fine without checking for isinstance.

[PhilipRoman]

Yeah you're right, I meant the other way around. Also another loosely related idea is the container_of macro in Linux kernel.

[1718627440]

Yeah, my idea is literally native type-safe support of container_of for assignment in the compiler.

[ryao]

vtables contain function pointers to functions that take “this” pointers. The author mentions struct file_operations as an example of a vtable. struct file_operations contains a pointer to a function that does not take “this” pointer. It is not even a vtable.

[1718627440]

I would still call it a vtable. Who assures you that every function of a class needs a pointer to the object instance? When you don't need it, you can just leave it of when you roll your own.

[ryao]

Static member functions are tied to the class while virtual member functions are tied to the object. If you throw the static member functions into a vtable, you will at best have a bug where the static member function from a different class can be called. Alternatively, you would have an undefined behavior where the other class in the hierarchy does not implement this function.

There is a saying “If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail”. That is precisely what is happening here with the insistence to call what appears to be all structures of function pointers vtables. A vtable is something that follows a fairly well defined pattern for implementing inheritance. Not all things containing function pointers are vtables.

[1718627440]

> Static member functions are tied to the class while virtual member functions are tied to the object.

That's nice, but the entire point is, that the caller doesn't know the type of the object, it only has a supertype. That's why you need dynamic dispatch here. Of course you can implement dynamic dispatch without function pointers, but it is done with function pointers here. If you don't want to name dynamic dispatch implemented with function pointers a vtable, OK, that's fine, but that's the definition I am familiar with.

[ryao]

The vtable pointer corresponds to the actual type in languages that use vtables to implement inheritance, so you do know the type.

Read my previous comment for the bug that would happen if what us being used in Linux were actually used for dynamic dispatch when implementing inheritance, and it should be clear this is something similar, but different.

[1718627440]

No the type of an object isn't known until runtime, so the compiler can't know it. Yes you know the type of the vtable, which means you know the supertype. This is true in all languages that don't use duck-typing. No you don't know the assigned values of entries in the vtable, which means you don't know the type of the object.

> Read my previous comment for the bug

No this is not a bug. The entire point of inheritance or dynamic dispatch IS that you call a function from "a different class" aka the subclass the object is an instance of. This is not a bug, this is the entire point of implementing it with vtables.