Hacker News new | ask | show | jobs
by rzzzt 473 days 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)"

3 comments

> 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.

The proto-C++ transpiler used C with this and similar techniques behind the scenes: https://en.wikipedia.org/wiki/Cfront
Is this satire? That’s almost exactly the C++ way.
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.

IIRC the rule now is that every new API has to be provided through a COM interface
That rule has been like that since Vista came to be, when .NET approach from Longhorn was redone in COM/C++.
Some say C++ is satire
It’s not satire, it’s how you do full OO in plain C.
It's overloaded - it is satire, but also, it isn't.
Exactly. Thank you for your time, I will and won't be here all week!