The first chapter, on abstraction and information hiding, is probably the most important. Every programmer should know how to do it. It's one of C's main strengths that it allows abstract data types so easily. ADTs in fact allow better binary compatibility since you only expose pointers as your public API, not structures of different shapes and sizes.<p>I'm continually surprised by how often people insist on putting struct definitions right in their header files, defeating the whole idea of type abstraction.
This is one of my favorite reads. About 10 years ago I was developing a toy programming language that compiled to ANSI-C and this was a great resource to me at the time.
Reminded me of the C Object System by Laurent Deniau[0].<p>[0]: <a href="http://ldeniau.web.cern.ch/ldeniau/cos.html" rel="nofollow">http://ldeniau.web.cern.ch/ldeniau/cos.html</a>
I wrote an AI Expert article on a similar theme ("Simulating Intelligent Interacting Objects in C", AI Expert, January 1989) about using C for OO programming of a robot simulator -- where the first argument is a pointer to a data structure representing the object. I prefixed all the function names with the class name, like Robot_move(robot, x, y). I was inspired by IIRC Eric Schildt's previous article elsewhere on how OO is an attitude.<p>Looks like a very comprehensive book though compared to just some short articles (even if it does not cite those as previous work). In general, this idea of opaque handles was (and is) very common in C programming, like with file operations. So, the question is what conventions we use or what convenience superstructure we build around that basic idea of handles.
One thing that was really educational for me was reading how CPython implemented their object system. <a href="https://github.com/python/cpython/blob/master/Include/object.h" rel="nofollow">https://github.com/python/cpython/blob/master/Include/object...</a><p>Basically objects are structs that all share the same header which contains a pointer to the object type (ob_type) and the reference count (ob_refcnt) for memory management.<p>That way you can always cast back to a pointer of that header struct and access ob_type and ob_refcnt no matter what the actual implemented struct contains afterwards.<p>ob_type contains the name of the type and function pointers for common methods used by objects (getattr, setattr, hash, arithmetic, etc).
For me the notion of domain is helpful in understanding OO. The definition of a domain is that everything inside it stands in determinate relations, whereas while multiple domains can interact they don't stand in determinate relations. Inheritance in classes, in adding more features to a class, can also have knock-on effects that interfere with the assumptions of other classes that are closely coupled to it, making classes an example of domain. Whole computers in a network are also domains; nodes can go down in which case no determinate expectations can be placed on them.<p>The existence of multiple domains is essentially postmodern as it creates, for practical purposes, multiple sources of truth. Because the expectations of one domain on another are weak, this naturally leads to a domain becoming robust against errors and inconsistencies from other domains, which leads to a stronger system. This type of robustness also helps components still be valid when they are placed into a different theory/environment that has additional properties. In some sense FP and OO are aiming at the same thing, that is making definitions that remain valid when the "arrows" of their environment change their meaning.<p>For a different perspective on this see Gerald Jay Sussman, "We Really Don't Know How to Compute!"
Another article related to this: <a href="https://www.codeproject.com/Articles/22139/Simply-Object-Oriented-C" rel="nofollow">https://www.codeproject.com/Articles/22139/Simply-Object-Ori...</a><p>I wrote it a while back just to see what I would come up with if I had to solve that problem for myself using only macros.
I am a fan of libco2[1] which is a minimalist object-oriented layer on top of C.<p>[1] <a href="https://github.com/peterpaul/co2/tree/master/examples/my-object-carbon/src" rel="nofollow">https://github.com/peterpaul/co2/tree/master/examples/my-obj...</a>
<p><pre><code> > void * find (const void * _set, const void * _element)
</code></pre>
Such an eye sore, and I think it goes strongly against the tradition of coding in C when someone uses the asterisk in the pointer context in such a way that makes it look like an infix operator, i.e. as if it was multiplication.<p>As to achieving a <i>reasonably looking</i> OO in C, this is why C++ was born...