Bah. It's a tool. Just like any tool, you should have it in your toolbox, and use it when appropriate.
When I hear about C programs that were a disaster because they used OO-like techniques, the operative word is usually "disaster" and not "C" or "OO". In other words, there were other things wrong with the project that had nothing to do with the selection of language or programming paradigm, like hiring inexperienced programmers or mandating a single programming paradigm for the whole codebase.
Good C code will have a lot fewer objects than say, Java, because most of the things you want to use C for, you can accomplish just fine with structs and functions. But you shouldn't shy away from a struct full of function pointers or an ADT with opaque pointer types and appropriately-namespaced member functions just because you're afraid a maintenance programmer won't get it. It's their responsibility to learn the language.
Seconding the idea that you don't use something like this prolifically. The point is to only go slightly past the limits of the tooling and still primarily be writing C in the style that C is best at.
For similar reasons, "cute" macro-heavy C code tends not to survive long-term, because it breaks too much tooling.
Disagreed. The techniques explained in the article worked quite well for me, and resulting projects are well-structured and very well maintainable for years.
As ever, we have to apply common sense: as I mentioned in the article, 1-level inheritance is quite good, or maximum 2, but if we have more, it gets too verbose. Luckily, for most cases, 1-level is quite enough to create common API and reusable modules.
Maybe you overuse it? Of course if you try to build huge hierarchies like this, you most likely will end up using typecasts in client code, and the entire thing will quickly become a mess. The article proposes solutions that don't have typecasts in client code.
As I said before, we should apply common sense. Engineering is all about tradeoffs. If I were you, I wouldn't argue against any approach as aggressively as you just did.
> and trust me, it ends up as a disaster. [...]
please do not do this in any project... for the sake of any who will follow you in maintaining your code!
The Linux kernel has some OO techniques in C. 2-part story:
I don't follow the Linux development mailing lists so I don't know if Linus Torvalds and other respected contributors regard those techniques as "disasters". Maybe they do.
I would argue that the linux kernel is largely object oriented, especially in the realm of device drivers. Every subsystem that I have worked with has you fill out the equivalent of a vtable, and passes state through structs rather than globally.
Most large-scale FOSS projects in C I've seen tend to be structured in OO-like ways. The C language actually lends itself well to a low-level, Nygaard-style OO when you reach a certain scale and complexity across modules.
Though, if your project is more of a toolkit, then a strictly procedural style is probably better.
Wierd, in the 90's we did a rather large, successful medical imaging product using techniques like these. If you had a CT or MRI scan in the 90s and early 00s, your images were likely rendered for the tech/radiologist using this type of code.
Yeah all that effort would be better spent on finding a platform that can actually support C++. Otherwise the base of code you end up with is hardly maintainable.
I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaster.
C is not meant to be OO, consequently all the tooling in editors and the like do not understand the links between classes and methods.
What it ends up like is an impenetrable mess with all the mechanics of C++ exposed but being impossible to navigate.
again... please do not do this in any project... for the sake of any who will follow you in maintaining your code!