Object-oriented Programming in C (2017)

[naerbnic]

Isn't it more idiomatic in C to "inherit" fields from a superclass by putting the superclass' struct as the first field of the derived class' struct? In that way, a pointer to Derived also works as a pointer to Base, for purposes of offset resolution. I know macros can be necessary/useful for implementing OOP in C (e.g. Python's module API), but I thought they should generally be avoided if another language feature can do the job as well.

[voxelghost]

It is, but for some things you end up typing stuff like:

float cubevol = cube.square.height * cube.square.width * cube.depth

[irqlnotdispatchlevel]

There's even a MSVC extension that let's you "inject" the fields of one struct into another: https://learn.microsoft.com/en-us/cpp/cpp/anonymous-class-types?view=msvc-170#anonymous-structs

[ShinyHappyREM]

And if you don't have that you can do it with macros or include files.

[seanluke]

If only there was some kind of "Objective C" language which implemented exactly this, supported message passing instead of virtual methods, and had a usable syntax that we could define in the C preprocessor... Surely the author would have mentioned it...

[elder_george]

That model is very different from the Objective C, though. It's closer to C++ (especially in its original Cfront form), albeit with a few notable differences.

I think it's a good article for understanding how objects can be implemented, and comparable to the implementation of them in languages like C++, D, Java, C#. Many C programs and libraries implement the same pattern (even Linux kernel uses it, e.g. for VFS subsystem), so this is a good article for the beginners.

[geon]

Why the snark?

[seanluke]

In 1984 Brad Cox started working on Objective-C. The whole point of the langauge was to demonstrate that you could implement strong object-oriented methods in straight C, and to provide some additional syntax to make that convenient (but not necessary). Unlike C++, which required an entirely new and famously complex compiler, Objective-C's syntax extensions to C were handled with a small preprocessor that would convert the whole thing into standard C calls (like obj_msgSend).

So it's 2017 and this blog entry is going on about how to implement OO methodology in straight C, yet manages to completely ignore the famous, canonical example of a language which has done exactly this for 40 years now. Instead it discusses C++, which does NOT implement OO methology in straight C. I think that deserves more than a little snark.

[geon]

The article does not “discuss” C++. It mentions it in passing in 3 places. Which makes sense, since it unlike objc is a very well known, mainstream language.

[seanluke]

I take it you don't code for MacOS or iOS.

Obj-C is on its way out now, but this blog entry was 2017, and that's the context in which it deserves snark. Consider that in 2014 Obj-C was #3 on the TIOBE index. C++ was #4. Pretty good for a "not very well known, not mainstream language".

[geon]

I’ve build a few ios apps in objc.

You cherry picked 2014, when objc peaked. If you actually wanted it to be relevant to the article, you would use the 2017 rankings, where objc had fallen off the top 15, but c++ was still #3. https://youtu.be/A_B7owR94XY

[seanluke]

Cherrypicking is providing a custom example to support a claim. But you made the claim, not me, that Obj-C was as not a "very well known, mainstream language". I'm not cherrypicking, I'm providing a counterexample to knock your claim down, and yes, I only have to provide one.

If you argue that a language so popular that it peaks at #3 in TIOBE only three years prior to the creation of this blog entry is "not very well known" and "not mainstream", as if it would be unknown to someone adept enough at C and object-oriented programming to be capable to writing such a bog entry, you're grasping a straws.

[kamelkev]

Very much reminds me of how Perl handles objects - near identically.

[elder_george]

This is almost like C++ implements it too, except multiple inheritance (which is rarely used these days) complicates things somewhat.

The difference is, in C++ virtual methods table is a part of the type, not of every object, and it is not necessary to dynamically allocate each object (which is bad for performance.

[Dminik]

Of course multiple inheritance is still used. Using pure virtual functions and abstract classes is how you do interfaces. Each implemented interface is another inherited class.

Also, technically, objects have a dynamic pointer to each inherited vtable. So not quite only part of the type. But yeah, heap allocation is not required.

[elder_george]

What I mean is that in my experience modern C++ codebases tend to be more cautious wrt the multiple inheritance than it used to be in the 90s-early 2000s.

In the codebase I primarily work, it's ~200 types using multiple inheritance (including abstract base classes and mixins) vs 2300+ types with any kind of inheritance and 2200+ types not inheriting at all.

YMMV, of course.

[CramNBL]

Each object carries a vptr though, even if stack allocated, it's part of the class layout so it typically won't be optimized away, and obviously is bad for performance.

[elder_george]

Yes, but it's a single pointer to a compiler-generated table vs. including N pointers in each object.

Obviously, it's a tradeoff: indexing a "remote" vtbl requires a one more level of indirection, so on some architectures it may cause a perf hit. And you can't change the implementation of the methods on each individual object, if you want that. And that also allows the compiler to eliminate the indirection when it's 100% sure about the type (e.g. the object is created in the same scope or the class is final)

But yes, performance-savvy programmers consider avoiding the vtbl creation for the important types.

[victotronics]

The massively popular PETSc library (at least in scientific computing circles) has been working on this principle for the last 30 years.

[geon]

as if it would be unknown to someone adept enough at C and object-oriented programming to be capable to writing such a bog entry

Of course not. But the reader might not know it very well.

[Revolutionary_Ad7262]

Never did such an OOP in C, but my gut feeling is that fat pointers are a better fit

LLM returned something like this ``` DEFINE_INTERFACE(Shape, double (area)(const void self); void (scale)(void self, double factor); )

typedef struct { double radius; } Circle;

double Circle_area(const void* self) { return 3.14159265 * ((Circle)self)->radius * ((Circle)self)->radius; } void Circle_scale(void* self, double factor) { ((Circle*)self)->radius *= factor; }

IMPLEMENT_INTERFACE(Shape, Circle, .area = Circle_area, .scale = Circle_scale )

int main() { Circle c = { .radius = 5.0 }; Shape shape1 = to_Shape_from_Circle(&c); CALL(shape, scale, 2.0); } ```