- instead of setting the same function pointers on structs over and over again, point to a shared (singleton) struct named "vtable" which keeps track of all function pointers for this "type" of structs
- create a factory function that allocates memory for the struct, initializes fields ("vtable" included), let's call it a "constructor"
- make sure all function signatures in the shared struct start with a pointer to the original struct as the first parameter, a good name for this argument would be "this"
- encode parameter types in the function name to support overloading, e.g. "func1_int_int"
- call functions in the form of "obj->vtable->func1_int_int(obj, param1, param2)"
No, that is essentially what Linux does in this article (and by the looks of it also ffmpeg).
struct file does not have a bunch of pointers to functions, it has a pointer to a struct file_operations, and that is set to a (usually / always?) const global struct defined by a filesystem.
As you can see, the function types of the pointers in that file_operations struct take a struct file pointer as the first argument. This is not a hard and fast rule in Linux, arguments even to such ops structures are normally added as required not just-in-case (in part because ABI stability is not a high priority). Also the name is not mangled like that because it would be silly. But otherwise that's what these are, a "real" vtable.
Surely this kind of thing came before C++ or the name vtable? The Unix V4 source code contains a pointers to functions (one in file name lookup code, even) (though not in a struct but passed as an argument). "Object oriented" languages and techniques must have first congealed out of existing practices with earlier languages, you would think.
It's how you do it in many C++ implementations, but IIRC it's not actually mandated in any way unless you strive for GCC's IA-64 ABI compatibility (the effective standard on Linux for C++)
C++'s vtables are also, in my experience, especially bad compared to Objective-C or COM ones (MSVC btw generates vtables specifically aligned for use with COM, IIRC). Mind you it's been 15 years since I touched that part of crazy.
It is more the other way around, COM was designed to fit with how MSVC generates vtables.
It is a simplification of OLE, and by the time the idea came up to use that approach, there were tons of OLE code since Windows 3.1.
By the way it wasn't gone away, after how Longhorn went down, it became the main API delivery mechanism on Windows, sadly improving the tooling has never been a pritority other than half-finished attempts.
I've noticed many large C projects resort to these sorts of OOP-like patterns to manage the complexity of the design and size of the code base. But I'm not aware of any one standard way of doing this in C. It seems C++ standardized a lot of these concepts, or C++ developers adopted standard patterns somehow.
Objects regardless of what shape they take, are basically an evolution of modules that can be passed around as values, instead of having a single instance of them.
That is why they are here to stay, and even all mainstream FP and LP languages offer features that provide similar capabilities, even if they get other names for the same thing.
It is like saying an artifact is useless, only because it get named differently in English and Chinese.
Interesting, in Rust those optimizations are more implicit since there's no "final" keyword when you use dynamic dispatch via trait objects. + you also got LTO.
I wonder if there are many cases where C++ will devirtualize and Rust won't.
But then again Rust devs are more likely to use static dispatch via generics if performance is critical.
In Rust objects can dynamically go in and out of having virtual dispatch. The vtable is only in the pointer to the object, so you can add or remove it. Take a non-virtual object, lend it temporarily as a dynamically dispatched object, and then go back to using it directly as a concrete type, without reallocating anything.
That's pretty powerful:
• any type can be used in dynamic contexts, e.g. implement Debug print for an int or a Point, without paying cost of a vtable for each instance.
• you don't rely on, and don't fight, devirtualization. You can decide to selectively use dynamic dispatch in some places to reduce code size, without committing to it everywhere.
• you can write your own trait with your own virtual methods for a foreign type, and the type doesn't have to opt-in to this.
> But then again Rust devs are more likely to use static dispatch via generics if performance is critical.
Put another way, in C++ the dynamic dispatch is implicit, so you might write code which (read literally) has dynamic dispatch but the optimizer will devirtualize it. However in Rust dynamic dispatch is explicit, so, you just would not write the dynamic dispatch - it's not really relevant whether an optimizer would "fix" that if you went out of your way to get it wrong. It's an idiomatic difference I'd say.
> But then again Rust devs are more likely to use static dispatch via generics if performance is critical.
I'm not sure I follow - pretty much 99% of usage of C++ in the last, like, 20 years has been around making sure that you get static dispatch with polymorphism through templates. It's exceedingly uncommon to see the `virtual` keyword unless you have, say, some DLL-based run-time plug-in system going on.
- instead of setting the same function pointers on structs over and over again, point to a shared (singleton) struct named "vtable" which keeps track of all function pointers for this "type" of structs
- create a factory function that allocates memory for the struct, initializes fields ("vtable" included), let's call it a "constructor"
- make sure all function signatures in the shared struct start with a pointer to the original struct as the first parameter, a good name for this argument would be "this"
- encode parameter types in the function name to support overloading, e.g. "func1_int_int"
- call functions in the form of "obj->vtable->func1_int_int(obj, param1, param2)"