You don’t implement calls to static member functions by putting them into a vtab...

1718627440 · 2025-08-29T11:44:56 1756467896

> You don’t implement calls to static member functions by putting them into a vtable

Yes, you claimed it is like a static member function, I don't think it can be.

> The proper way to implement static functions is through static dispatch

Yes, but we are talking about dynamic dispatch here.

To quote your earlier comment:

> which is most unlike a vtable since static member functions are never in vtables

You conclude it isn't a vtable, I conclude, it's not a static member function, because it uses dynamic dispatch.

I don't think we actually disagree on how and when to use static and dynamic dispatch.

ryao · 2025-08-29T13:34:09 1756474449

If you leave out the this pointer, it is the equivalent of putting a function pointer to a global function (or a static member function) into the structure. This is not how OOP works.

Omitting the this pointer also breaks inheritance, since hypothetical child classes would not be able to override the definition while using the this pointer. Having to edit the parent class to be able to do that is not how OOP works.

This is not OOP nor is it intended to be.

1718627440 · 2025-08-29T19:58:14 1756497494

> If you leave out the this pointer, it is the equivalent of putting a function pointer to a global function (or a static member function) into the structure.

No it is not. Unless you can show me a virtual overridden static member function.

> since hypothetical child classes would not be able to override the definition while using the this pointer

Yes! That's the entire idea here. The non-hypothetical, but indeed existing, child classes are not able to access the object. This is to prescribe potential behaviour for child implementations.