3 ms·
You can take it a step further: - instead of setting the same function pointers on structs over and over again, point to a shared (singleton) struct named "vta
by rzzzt 2y ago
You can take it a step further:
- 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)"
- drivebyhooting 2y agoIs this satire? That’s almost exactly the C++ way.
- relistan 2y agoIt’s not satire, it’s how you do full OO in plain C.
- actionfromafar 2y agoIt's overloaded - it is satire, but also, it isn't.
- rzzzt 2y agoExactly. Thank you for your time, I will and won't be here all week!
- procaryote 2y agoSome say C++ is satire
- p_l 2y agoIt'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.
- pjmlp 2y agoIt 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.
- magicalhippo 2y agoThis is pretty much how you do COM[1] in C[2]. [1]: https://learn.microsoft.com/en-us/windows/win32/com/com-technical-overview https://learn.microsoft.com/en-us/windows/win32/com/com-tech... [2]: https://www.codeproject.com/Articles/13601/COM-in-plain-C https://www.codeproject.com/Articles/13601/COM-in-plain-C
- starspangled 2y ago> You can take it a step further: 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.
- rzzzt 2y agoThe proto-C++ transpiler used C with this and similar techniques behind the scenes: https://en.wikipedia.org/wiki/Cfront https://en.wikipedia.org/wiki/Cfront