4 ms·

Do NOT use these techniques please! I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaste

Do NOT use these techniques please! 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!

pjmlp 11y ago
Fully agree. Ended up doing a similar approach when forced to use C instead of C++ for a data structures university project. Goal achieved, but not an experience to repeat ever again.
- z92 11y ago
  So how would you have done it the next time if you had to stick with C?
  - pjmlp 11y ago
    Just plain ADTs instead of trying to mock object semantics. Edit: Forgot to mention that so far I only used plain C instead of C++ when obliged to do so.
dimonomid 11y ago
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.
RobertDeNiro 11y ago
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.
- deleted 11y ago
  [deleted]
jasode 11y ago
> 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: https://lwn.net/Articles/444910/ https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ https://lwn.net/Articles/446317/ 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.
- Skunkleton 11y ago
  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.
vezzy-fnord 11y ago
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.
deckard1 11y ago
Oh, nonsense. It works great for GTK+. Having worked on both GTK+ and Qt, I would take GTK+ over having to use Moc any day.
nostrademons 11y ago
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.
- chipsy 11y ago
  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.
Ensorceled 11y ago
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.
zeckalpha 11y ago
And C is also not meant to be functional, but yet, there's a 400+ page book on Functional C: http://eprints.eemcs.utwente.nl/1077/02/book.pdf http://eprints.eemcs.utwente.nl/1077/02/book.pdf

pjmlp 11y ago

Fully agree. Ended up doing a similar approach when forced to use C instead of C++ for a data structures university project. Goal achieved, but not an experience to repeat ever again.

z92 11y ago
So how would you have done it the next time if you had to stick with C?
- pjmlp 11y ago
  Just plain ADTs instead of trying to mock object semantics. Edit: Forgot to mention that so far I only used plain C instead of C++ when obliged to do so.

dimonomid 11y ago

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.

RobertDeNiro 11y ago

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.

deleted 11y ago
[deleted]

jasode 11y ago

> 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: https://lwn.net/Articles/444910/ https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ https://lwn.net/Articles/446317/ 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.

Skunkleton 11y ago
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.

vezzy-fnord 11y ago

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.

deckard1 11y ago

Oh, nonsense. It works great for GTK+. Having worked on both GTK+ and Qt, I would take GTK+ over having to use Moc any day.

nostrademons 11y ago

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.

chipsy 11y ago
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.

Ensorceled 11y ago

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.

zeckalpha 11y ago

And C is also not meant to be functional, but yet, there's a 400+ page book on Functional C: http://eprints.eemcs.utwente.nl/1077/02/book.pdf http://eprints.eemcs.utwente.nl/1077/02/book.pdf