> You don't need macros. You either call via the vtable, or you write a wrapper per interface per message.

I know, thus the /s for sarcasms.

> Such wrappers are fairly trivial to generate if you don't want to handwrite them.

It's fairly irrelevant to my point, which is that C structs aren't equivalent to Java classes in anyway.

Of course you can implement OO is C, I've done enough GObject in my life to know how horrible it is to use in practice.

They only way they aren't is that the class pointer is hidden from the user.

what does an "object" look like? how do i derive from it?

Any struct. Only requirement would be that the first element can be casted to a point to a class object containing the vtable. I'ved edited to fix the casting so it actually compiles, and to use a void * in the argument list, as is what you'd actually usually do.

generic base type struct

Easy; a subclass struct embeds the superclass struct as its first member.

Simple example here: https://embeddedgurus.com/state-space/2008/01/object-based-p...

Lots more here: https://stackoverflow.com/questions/351733/how-would-one-wri...

Having spent quite some time down that rabbit hole back in the days, I'd definitely recommend against pushing C in that direction. Few people love GObject, for good reasons.

Embedding combined with the container_of-macro [0] is a much more constructive approach from my experience.

[0] https://stackoverflow.com/questions/15832301/understanding-c...

Nothing in your example looks or reads as trivial. That is a gross perversion of a simple procedural language.

Trivial to a C developer then. This has been typical of C code for literally decades. The only thing that sucks there is writing wrappers, but it's easy to generate them.

From a user point of view you end up doing things like:

  string * str = string_new();
  int len = string_length(str);

So it looks just like most other typical C code using prefixes per interface and passing pointers to structs around.

In practice, like in C++, you'd tend to only actually use the vtable approach for those things which you actually need to be able to override based on type, which tends to be rare.

Another approach is to use messages instead, and a call a generic message handler. E.g. "ob->call(MSG_TYPE, ... arguments)" and just have a pointer to a message handler function as the first pointer in your objects. It's more flexible, but slower.

"int string_length(void * self) { return ((int ()(void ))((object *)self)->class->vtable[STRING_LENGTH_SLOT])(self);"

Oh.My.God.

At this point, you might as well be using Java.

If you're writing C, you'll be writing much worse than that on a regular basis. There's a reason I rarely use C any more.

But of course if you're going to reimplement OO from scratch in C you will see the entire machinery laid bare. You're only doing it in the first place either because you're committed to using C for whatever reason, or to understand OO implementation strategies.

Replying to myself to leave this here, since it's vaguely related. If anyone really want to have nightmares about OO'ish concepts in C, here is a few different ways to implement closures in C, going from relatively straightforward, to (unportable) runtime generation of assembler thunks:

https://hokstad.com/how-to-implement-closures

You are just being glib here.

If you want simpler models see my other comments in this thread.

Or C++

/gasp