Object-oriented techniques in C

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!

EFnet's infamous Zhivago (from #c) has a great article about OOP in C - http://www6.uniovi.es/cscene/CS1/CS1-02.html

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.

Surely it does have some overhead. And, by the way, passing arguments to function has an overhead as well, comparing to globals. But, how often would you recommend use globals?

The more interesting question is: how much overhead? And the answer is: it depends on the MCU. For example, some 8-bit PICs don't have silicon support for indirect function call (i.e. by function pointer), so they work around this problem by saving function address to the stack and execution 'return' instruction. It works much slower and code size increases notably. I don't use these techniques on these chips.

But for 16- and 32-bit MCUs that I was working with, it works flawlessly. For most of our projects, the overhead is much less significant than the maintainability we get with this approach. As I said in another comment, engineering is all about tradeoffs.

I'm saddened by the author going to this trouble. Embedded cpu selection doesn't happen in isolation - or at least, it shouldn't. The available tools are a large part of why you would pick chip A over chip B. If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools.

If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

If this is a microcontroller you end up lumbered with, and didn't choose, then fair enough, but this effort should be labeled for the hack that it is. This is not best or even good practice.