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).
Isn't there some way to emit C from C++? Wouldn't a capability like that and using C as a host language completely bypass the need for emulating OOP in C, by just letting you write C++? That seems like it would be far more manageable, and since it's compiled, not susceptible to some of the major downsides commonly associated with the technique (in JS).
this approach is similar to the one that GObject uses, though stripped down a bit for embedded. i haven't used it in years, but it worked great with GTK+. the only downside i remember is the overhead of the virtual function calls (in contrast, the jvm is able to factor out the virtual call in many cases at runtime)<p>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++
I've found that, in the embedded world at least, the overhead this adds (in terms of flash/rom and ram) can be fatal. That said, there are some more implementations of this here if anyone is curious: <a href="https://github.com/ryanbalsdon/libr" rel="nofollow">https://github.com/ryanbalsdon/libr</a>
EFnet's infamous Zhivago (from #c) has a great article about OOP in C - <a href="http://www6.uniovi.es/cscene/CS1/CS1-02.html" rel="nofollow">http://www6.uniovi.es/cscene/CS1/CS1-02.html</a>
How badly does this impact optimizations? First you add an extra function pointer for any member, even if it's not virtual. Then since you're always calling via a function pointer -- do compilers notice when fps are assigned and never modified and do inlining and so on?<p>Also the first technique doesn't feel like OO in any meaningful way. Defining a state object and passing it to functions is exactly what you'd do in say, a functional programming language, or even in regular old imperative code.
Also check out: Simply Object-Oriented C --> <a href="http://www.codeproject.com/Articles/22139/Simply-Object-Oriented-C" rel="nofollow">http://www.codeproject.com/Articles/22139/Simply-Object-Orie...</a>
"The danger in trying to force object-oriented concepts onto a C base is to get an inconsistent construction, impairing the software development process and the quality of the resulting products. A hybrid approach yields hybrid quality. This is why serious reservations may be voiced about the object-oriented extensions of C described in chapter 20. To benefit from object-oriented techniques, one must use a consistent framework, and overcome the limitations of languages such as Fortran or C which regardless of their other characteristics -- were designed for entirely different purposes." Bertrand Meyer, Object-oriented Software Construction, 1988.
This interesting article reminded me of this post by Rob Pike from some time ago:
<a href="https://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb" rel="nofollow">https://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb</a>.<p>While I've been a C++ programmer since my uni days, I think algorithms and data structures should come first, and I don't like the idea of "bending" programs to make them fit nicely within the OO paradigm.
Do <i>NOT</i> use these techniques please!<p>I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaster.<p>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.<p>What it ends up like is an impenetrable mess with all the mechanics of C++ exposed but being impossible to navigate.<p>again... please do <i>not</i> do this in any project... for the sake of any who will follow you in maintaining your code!
This is probably a stupid question, but here it goes:<p>Embedded platforms tend to have size limits. Would this increase the size of the source code? Seems a bit verbose to me.
Hmm...those who don't understand Objective-C are doomed to reinvent it, badly? (Yes, have used OO C techniques of different sorts and implemented ObjC compiler/runtime).