11–20 of 74 posts
Unmaintainable and extra complexity just to emulate a paradigm that C wasn't designed for.
By the way, similar approach is used across the Linux Kernel: check, for example, the book "Linux Kernel Development" by Robert Love, especially the discussion on the virtual filesystem.
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.…
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.…
The Linux kernel has some OO techniques in C. 2-part story:
https://lwn.net/Articles/444910/
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.
one advantage of using something like this is it forces you to really think about what makes something OO and gives you a deeper appreciation of it. i'm a java programmer now, but to this day i still prefer object oriented C to 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.…
Though, if your project is more of a toolkit, then a strictly procedural style is probably better.
This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).
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 j…
So the software engineers are the only ones on the project who get a say as to what chips get used?
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.…
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.…
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.