[ryao]

It is not the same theory, since it is an ADT, not anything object oriented. Different theories can and do overlap. The emitted code is also not the same, since there is no implicit this pointer. You are the one who posted a definition you found and then claimed that it agreed with you, when it did not and now are reneging on your use of it. You do not understand this topic as well as you think you do and this is a silly hill to die on.

[1718627440]

> You are the one who posted a definition you found and then claimed that it agreed with you

X is Y used in Z. Does that mean X is not Y when it is not used in Z? A knife is a sharp object used to cut meat. How do I call the thing to cut fish?

Yes, I see how you can parse the definition your way, I didn't thought about that before introducing it.

> since it is an ADT, not anything object oriented

Yes, they have large overlap. To my understanding, the difference is, that OOP has inheritance and an ADT can be provided by the big god object. The latter I would refrain to call OOP, although it can be argued it still is.

I think our real discussion here is, whether a function entry that doesn't take an argument of the object type precludes it being a vtable. To me it is as long as this function is supposed to be a method of a single object and not for all objects in general, i.e. a global function.

[ryao]

The point of a vtable is to implement virtual member functions that support inheritance and polymorphism without changing the base class implementations no matter what the child classes do. If you omit the this pointer, you cannot do inheritance that uses the this pointer in an override without changing the implementation of the parent to add the this pointer back, which would be like a tail wagging a dog. Thus, it is not a vtable. It is something similar, but different.

[1718627440]

> The point of a vtable is to implement virtual member functions that support inheritance and polymorphism without changing the base class implementations no matter what the child classes do

I agree.

> If you omit the this pointer, you cannot do inheritance that uses the this pointer in an override

Yes, but:

> If you omit the this pointer, you cannot do inheritance

You can absolutely do inheritance when the child implementation doesn't need a this pointer. You need the this pointer to read/write values of the instance not to know which types it is.

Let me give you an example:

    class Vehicle {
        virtual unsigned int get_number_of_wheels () = 0;
    };

    class Car: Vehicle;
    class Bicycle: Vehicle;

    unsigned int Car::get_number_of_wheels () { return 4; }
    unsigned int Bicycle::get_number_of_wheels () { return 2; }

This is clearly OOP, there is inheritance, a base class, a vtable introduced by the compiler. C++ will still have a this pointer here for consistency, but absolutely isn't needed here.

This is exactly was is going on with check_flags(). The signature is inherited from a (virtual) base class. Part of that interface contract is that the allowed values are only depended upon the file object's type and not on it's values. You choose the implementation invoked at object construction, if it would need a this pointer, it means that the values returned can change during the lifetime of the object.

    The  following  commands manipulate the flags associated with a file descriptor. [...]
    F_SETFD (int)
              Set the file descriptor flags to the value specified by arg.

Why should the set of allowed flags change over the life time of a file descriptor? That is what the kernel prevents here in it's internal interface by refusing to provide a this pointer to a child implementation.